Maldita renta
Maldita renta
Puta renta me parecía muy fuerte para el título.
Estos días todos tenemos el privilegio de revisar si hemos pagado de más o de menos al estado y ajustar cuentas. En este momento, los españoles nos dividimos en dos grupos. Los que nos quejamos por haber adelantado dinero y los que nos quejamos por tener que pagar un extra.
Este año, me ha tocado pagar y quizás de ahí venga el título. Me he peinado todo el borrador intentando encontrar algo que me salvase, pero nada. Durante la búsqueda he ido maldiciendo cada aspereza que tiene la aplicación. Logouts inesperados, botón de guardar oculto, un menú hecho para asesores fiscales, … El listado es inmenso. Tanto que empecé a pensar, si yo gestionase este equipo ¿por dónde empezaría?
Lo primero que haría sería definir cuál es mi North Star del producto y cuáles son mis métricas de entrada para ayudarme a guiar mis decisiones. Por eso hoy vamos a ayudar a hacienda a encontrar su North Star del producto Renta WEB para el próximo año. Quién sabe, igual el próximo año nos toca a devolver.
El framework de North Star consiste en definir una métrica clave que refleje el éxito general del producto. Esta métrica se elige cuidadosamente para alinear los esfuerzos y decisiones de la organización en torno a un objetivo central y medible.
La North Star debe ser una métrica única y clara que muestre el valor fundamental que el producto busca ofrecer a sus usuarios. Por ejemplo, para una red social, su métrica podría ser las horas que pasan los usuarios en la aplicación, mientras que, para una plataforma de comercio electrónico, podría ser el valor medio de su carrito de compras.
Para el resto del artículo, asumo que conoces los conceptos básicos del framework. Si no, aquí tienes el North Star Playbook de Amplitude con el que puedes pasar de 0 a 100 en un par de tardes.
Definiendo la North Star de Renta WEB
Para definir bien una North Star, hay que entender a el tipo de juego de tu producto. ¿Juegas a captar atención, como Netflix o Spotify? ¿Quieres maximizar transacciones como Amazon o Airbnb? ¿Y mejorar la productividad de tus usuarios como Figma o Trello?
Entre la interfaz de 2008, el copy de las opciones y el contenido de la aplicación, podemos concluir bastante rápido, que el producto no quiere jugar al juego de la atención. Métricas cómo “total de horas de sesión de los usuarios al mes” no ayudarían a mejorar el objetivo del producto.
Sin embargo, me parece interesante analizar si es una herramienta de productividad o transaccional.
Por un lado, tenemos a Hacienda como cliente/usuario de Renta WEB. Bajo este prisma, el número de rentas que se realizan correctamente, podría ser una buena North Star. Por otro lado, si cogemos al ciudadano como usuario, va a realizar siempre una renta al año (con alguna paralela si se equivoca). En ese caso el tiempo medio para presentar una declaración correcta, podría tener más sentido.
Juego de transacciones
En mi opinión este enfoque tiene bastante sentido, ya que lo relaciono con la charla de Paco Crespo en la LPC Madrid de este año:
Los product managers trabajamos por y para el servicio, con el usuario en el centro.
No nos engañemos, el servicio es recaudar. Bueno, ser justos en la recaudación. Ni devolver dinero de más, ni ayudar al ciudadano a entender, ni …
Por lo tanto, la métrica tiene que estar alineada con ese objetivo. Entiendo que Renta WEB fue desarrollado para mejorar la eficiencia de los inspectores de hacienda. Por tanto, el éxito de este producto podría medirse el número de declaraciones que el producto puede hacer bien, para que la inspección sea lo más rápida posible.
Si le diésemos un enfoque conspiranoico, en el que hacienda gana más dinero si te equivocas, la métrica podría ser el número de declaraciones que generan una multa, o upselling como se dice en el mundo startupero. Prefiero pensar que hay personas en el ministerio que velan porque no haya incentivos maliciosos a la hora de desarrollar estas herramientas, por lo que vamos a analizar en detalle la siguiente métrica:
Número de declaraciones correctas que son presentadas por Renta WEB sin ayuda externa y revisadas por un inspector en menos de 5 minutos.
¿Por qué digo revisadas por un inspector y no simplemente presentadas? Porque queremos contar las declaraciones que afectan a la eficiencia del trabajo de la Administración. Si no se revisan, la administración no tiene que invertir tiempo en ellas. Llegando a un absurdo, si el programa no te dejase editar, pero hiciese la declaración a la perfección, mejoraría esta métrica y aportaría a su fin último; quitar carga de trabajo a los funcionarios que revisan las declaraciones.
Una vez elegida la North Star, toca definir las entradas que alimentarán esta métrica. A mí, me gusta utilizar la siguiente fórmula para definir métricas de entrada:
Amplitud: número de personas que inicia la declaración de la renta a través de Renta WEB
Profundidad: porcentaje de las personas que termina de presentar la declaración a través de Renta WEB sin ayuda externa (asesores, programas, funcionarios, …).
Frecuencia: esta la podemos obviar ya que se presenta una renta al año.
Eficiencia: porcentaje de declaraciones (de las anteriores) que se revisan en un tiempo inferior a 5 minutos.
Estas métricas de entrada son las que ayudarán al equipo de producto a plantearse los retos del año 2024:
¿Cómo hacemos que más personas inicien su declaración de la renta?
Mejorando la accesibilidad a la web.
Campaña de marketing incentivando el uso.
Mejorando el login (cuantas personas habrán caído por el camino por tener que usar cl@ve, certificado digital o el DNI electrónico).
¿Cómo conseguimos que más personas terminen la declaración?
Crear un formato que haga que la información sea más familiar para el usuario.
Creando un asistente que ofrezca ayuda en mitad del proceso.
¿Cómo mejoramos que más declaraciones estén “bien”?
Mejorando los procesos de integración de la información.
Mostrando avisos de errores antes de enviar el borrador.
Juego de productividad
¿Qué pasaría si la aplicación de Renta WEB fuera para el ciudadano y no para la Administración? ¿Cómo podríamos guiar al equipo de desarrollo para mejorar la vida de los contribuyentes?
Si lo planteamos cómo un competidor a la aplicación Tax Down, que ayuda a las personas a realizar su renta, podríamos imaginar una North Star de este tipo:
Total ahorrado sobre el resultado del borrador inicial de las declaraciones presentadas
Si se enfocase como una herramienta de productividad, su métrica podría ir ligada a cuánto de rápido se puede presentar la renta:
Tiempo medio total en presentar una declaración de la renta que no tenga errores en la fase de inspección.
Para esta North Star, el conjunto de métricas de entrada que afectaría está métrica sería
Amplitud: número declaraciones presentadas a través de Renta WEB
Profundidad: porcentaje de las declaraciones que son correctas al pasar por un inspector
Frecuencia: Tiempo medio de presentación de una declaración
Eficiencia: no incluiremos un coeficiente de eficiencia en este modelo
Cualquiera que sea el juego de Renta WEB y en definitiva de tu producto, lo importante es tener un modelo que te permita:
Tener una métrica medible que te ayude a entender la salud de tu producto.
Tener métricas de entrada que te permitan plantear problemas acotados a mejorar y una referencia sobre la que analizar si se ha mejorado.
Si en tu producto ya la tienes resuelto, ¿cuál es, tu North Star? Déjalo en comentarios.
Si necesitas ayuda con este concepto, la guía de Amplitude va genial para poder definir con tu equipo la North Star de tu producto.