Queda una semana para que abra al público KPIAds… o al menos eso es lo que tengo planteado. Ya veremos si Shopify me deja tenerlo para la fecha o no, pero bueno, esto te lo cuento al final, que no es lo importante de hoy.
La cosa es que queda una semana para el día de lanzamiento y, como buen MVP, hay que decidir qué funcionalidades lanzamos y cuáles dejamos para más adelante.
Porque sí, yo soy de los de la filosofía ship fast, fail fast, que es una mentalidad de startup que aboga por lanzar tu producto rápido para ver lo que realmente importa: si hay sitio para tu producto en el mercado, qué valor aporta, cuáles son los principales obstáculos… Todo ello para aprender lo más rápido posible e iterar.
Y aunque esto suena muy bien cuando lo lees en un libro o lo escuchas en un podcast, cuando el producto es tuyo y llevas semanas trabajando en él, la cosa cambia bastante.
Porque siempre hay algo más que podrías añadir.
Una funcionalidad que haría el producto más completo, una integración que podría atraer a más usuarios, un gráfico que quedaría genial en el dashboard o ese pequeño detalle que llevas días pensando que deberías mejorar.
Y aquí es donde aparece uno de los mayores enemigos de cualquier persona que está construyendo un producto: confundir lo que sería interesante tener con lo que realmente necesitas para lanzar.
El problema no es decidir qué construir, sino qué NO construir
Por si todavía no conoces KPIAds, es un SaaS que estoy desarrollando para que los propietarios de tiendas online puedan conectar sus plataformas de ecommerce y sus cuentas publicitarias (Google Ads, Meta Ads, TikTok Ads…) y consultar en un único lugar las métricas que necesitan para entender cómo está funcionando su negocio.
La idea es bastante sencilla: que no tengas que entrar en cuatro plataformas distintas, cruzar datos manualmente y pelearte con hojas de cálculo para saber cómo van tus campañas y tus ventas.
Pero una idea sencilla no significa necesariamente un producto sencillo.
Podría añadir informes automáticos por correo, alertas cuando una campaña deje de ser rentable, predicciones con IA, comparativas avanzadas, integraciones con más plataformas, recomendaciones para optimizar presupuestos…Y probablemente muchas de esas funcionalidades acabarían aportando valor.
Pero hay una pregunta que intento hacerme cada vez que se me ocurre algo nuevo:
¿Necesito esto para comprobar que alguien está dispuesto a utilizar KPIAds y pagar por él?
Si la respuesta es no, seguramente puede esperar.
Esto no significa que la funcionalidad sea mala, significa que todavía no es el momento.
Las 4 preguntas que utilizo para priorizar funcionalidades
No tengo una fórmula mágica para decidir qué entra en la beta. De hecho, seguramente me equivocaré con algunas decisiones.
Pero estoy intentando aplicar cuatro filtros que creo que pueden servirte si también estás desarrollando un producto
1. ¿Resuelve el problema principal del usuario?
Esta es la primera pregunta y, para mí, la más importante.
Si mañana alguien conecta su tienda a KPIAds, ¿puede conseguir aquello por lo que ha venido?
No necesita encontrar 25 funcionalidades distintas. Necesita resolver el problema que le ha llevado a probar la herramienta.
En mi caso, eso significa poder conectar las fuentes de datos necesarias, consultar las métricas importantes y entender mejor el rendimiento de su negocio.
Si eso funciona bien, ya tengo una primera propuesta de valor que puedo validar.
Si no funciona, da igual lo bonito que sea el dashboard o cuántas funcionalidades adicionales tenga.
Consejo: escribe en una sola frase qué problema resuelve tu producto. Después revisa cada funcionalidad y pregúntate si es imprescindible para cumplir esa promesa.
2. ¿Estoy construyendo esto porque alguien lo necesita o porque a mí me apetece?
Esta me parece especialmente peligrosa cuando eres desarrollador y construyes tus propios productos.
Porque nos encanta programar.
Aparece una tecnología nueva, se nos ocurre una integración interesante o pensamos en una funcionalidad que técnicamente sería un reto divertido… y de repente estamos dedicándole dos días a algo que nadie nos ha pedido.
Y ojo, que experimentar está genial. Pero hay que diferenciar entre experimentar para aprender y construir algo que realmente necesita el negocio.
Con KPIAds tengo una lista de ideas que me gustaría implementar, pero estoy intentando no confundir mis ganas de desarrollarlas con una necesidad real de los usuarios.
Consejo: antes de dedicar varios días a una funcionalidad, intenta encontrar alguna evidencia de que resuelve un problema. Habla con potenciales usuarios, observa cómo trabajan o comprueba si ya están buscando soluciones alternativas.
3. ¿Qué pasa si no incluyo esta funcionalidad?
Esta pregunta me ayuda bastante a poner las cosas en perspectiva.
Imagina que quieres lanzar un SaaS y estás valorando añadir un sistema avanzado de notificaciones.
¿Qué ocurre si no lo tienes desde el primer día?
¿El usuario no puede utilizar el producto? ¿La propuesta de valor deja de tener sentido? ¿O simplemente sería una mejora interesante para más adelante?
Si la respuesta es la tercera, probablemente no necesitas incluirlo todavía.
Eso sí, hay una excepción importante: todo lo relacionado con seguridad, privacidad, integridad de los datos y funcionamiento básico del producto no debería sacrificarse por lanzar antes.
Un MVP puede tener pocas funcionalidades, pero las que tiene deben funcionar correctamente.
Consejo: clasifica las funcionalidades en tres grupos: imprescindibles para resolver el problema, importantes para mejorar la experiencia y mejoras que pueden esperar. Después intenta lanzar únicamente con el primer grupo.
4. ¿Qué voy a aprender al lanzar esta funcionalidad?
Esta es una de las preguntas que más estoy intentando interiorizar.
Porque el objetivo de una beta no es demostrar todo lo que eres capaz de construir. Es aprender.
Aprender si el problema existe, si tu solución resulta útil, si la gente entiende cómo utilizarla y, sobre todo, si hay personas dispuestas a pagar por ella.
Por eso intento valorar las funcionalidades no solo por el valor que podrían aportar, sino también por la información que me permitirían obtener.
Por ejemplo, antes de dedicar semanas a construir informes avanzados, prefiero comprobar si los usuarios realmente consultan las métricas que ya tienen disponibles.
Quizá descubra que necesitan más información. O quizá descubra que lo que necesitan es exactamente lo contrario: menos datos y conclusiones más claras.
Y esa diferencia puede ahorrarme muchísimo tiempo de desarrollo.
Consejo: para cada funcionalidad importante, escribe qué hipótesis quieres validar. Si no sabes qué vas a aprender construyéndola, quizá no sea tan prioritaria como pensabas.
Una regla que estoy intentando seguir: si tengo dudas, lo dejo fuera
Hay algo que he aprendido desarrollando productos y trabajando con software durante estos años: añadir funcionalidades es relativamente fácil. Mantenerlas es otra historia.
Cada funcionalidad nueva implica más código, más casos que probar, más posibilidades de errores, más soporte y más decisiones que tomar en el futuro.
Y cuando estás construyendo un SaaS tú solo, todo eso tiene un coste importante.
Por eso estoy intentando aplicar una regla bastante sencilla: si una funcionalidad no es imprescindible y no tengo evidencias claras de que deba estar en la primera versión, se queda fuera.
No la descarto para siempre. La apunto, la guardo y vuelvo a ella cuando tenga más información.
Prefiero lanzar un producto pequeño que resuelva bien un problema concreto antes que uno enorme que intente resolver diez problemas a medias.
Porque el objetivo de un MVP no es construir la versión pequeña de tu producto soñado. Es construir la versión más pequeña que te permita comprobar si merece la pena seguir desarrollándolo.
Y ahora sí… el pequeño drama con Shopify
Te decía al principio que queda una semana para lanzar KPIAds, al menos sobre el papel.
Y es que hay una variable que no controlo del todo: la aprobación de la aplicación en Shopify.
Para que los usuarios puedan instalar KPIAds desde su ecosistema, la aplicación tiene que pasar por un proceso de revisión. Y entre revisiones, cambios y nuevas comprobaciones, la cosa se está alargando más de lo que me gustaría.
Lo curioso es que puedes planificar el desarrollo, priorizar funcionalidades, organizar el lanzamiento y tener una fecha marcada en el calendario… pero siempre puede aparecer una dependencia externa que te cambie los planes.
Es otra de esas cosas que forman parte de construir un producto real y que no siempre se cuentan.
De momento sigo trabajando para llegar a la fecha prevista. Si Shopify da el visto bueno a tiempo, genial. Y si no, tocará adaptarse.
Lo que no quiero es utilizar esa incertidumbre como excusa para seguir añadiendo funcionalidades indefinidamente.
Porque entonces nunca lanzaría nada.
Para terminar
Si estás desarrollando tu propio SaaS, una aplicación o cualquier otro producto digital, me gustaría que te quedaras con una idea:
No necesitas tener todas las respuestas antes de lanzar. Necesitas lanzar algo que te ayude a encontrarlas.
Muchas veces dedicamos meses a construir lo que creemos que los usuarios quieren, cuando podríamos descubrirlo mucho antes poniendo una versión sencilla en sus manos.
Y sí, da un poco de vértigo enseñar un producto que sabes que todavía tiene cosas por mejorar.
Pero probablemente da mucho más vértigo pasar seis meses construyendo algo y descubrir después que nadie lo necesita.
En un par de semanas espero poder contarte cómo ha ido el lanzamiento de KPIAds. Y, si las cosas no salen como tengo previsto, también te lo contaré.
Al fin y al cabo, la idea de compartir este proceso es precisamente esa: enseñar lo que funciona, lo que no y lo que voy aprendiendo por el camino.
Y ahora te pregunto: si alguna vez has lanzado un producto, ¿qué te ha costado más, decidir qué construir o aceptar qué tenías que dejar fuera?
Nos leemos la semana que viene.
Julián
