TL;DR
- Lancé RabbitHole en LinkedIn con una promoción de 35 €. Llegó a 12.091 impresiones, algunas personas lo probaron y nadie compró ni una zanahoria (los créditos de la app).
- El problema no fue la parte técnica, sino las decisiones de producto: un usuario objetivo difuso, un MVP de dos años, cero métricas de conversión y una validación que solo venía de amigos.
- La próxima vez: un usuario, un problema, una hipótesis y medirlo todo desde el primer día.
El día del lanzamiento tenía una cuenta de Stripe, tres planes de precios, un tráiler y un conejo con cascos.
Unas semanas después tenía doce mil impresiones y cero euros.
Si aún no lo has leído, en Cómo construí RabbitHole cuento cómo nació el producto. Este post va de lo que pasó cuando se topó con el mundo real, y de los errores que solo veo ahora que ha terminado. Lo escribo porque un post-mortem solo vale lo que vale su honestidad, y porque prefiero no cometer ninguno de estos errores dos veces.
El lanzamiento
Anuncié RabbitHole en un post de LinkedIn: el problema (aprender en una ventana de chat infinita es un caos), la solución (guías estructuradas con analogías, flashcards, tests y pódcasts), el enlace y el tráiler de un minuto. Después pagué 35 € para promocionarlo entre un público de habla inglesa en España.
Este fue el resultado:
Doce mil personas vieron el post. Algunas abrieron la app. ¿Cuántas? No lo sé, y eso acabó siendo uno de los cuatro errores. Nadie compró zanahorias.
Lo que salió bien
Empiezo por lo bueno, porque lo hay, y no es poco.
Construí un SaaS completo yo solo. Cuentas, base de datos, tres modos de IA, pagos, pódcasts, una landing, una demo pública y una batería de tests. Hace dos años tenía un dashboard en React con botones tipo sonar. Por el camino aprendí más sobre integración de IA, UI/UX y pagos de lo que me habría enseñado cualquier curso, porque cada lección venía con un bug que tenía que arreglar yo.
Y ahora el proyecto está en mi CV, que no esta mal.
Lo que salió mal
Como producto, no funcionó. Lo cual, todo sea dicho, es lo que les pasa a casi todos los primeros productos. Lo interesante no es si fracasó, sino por qué, y, tras varias semanas dándole vueltas, siempre acabo en las mismas cuatro razones.
1. "Gente curiosa" no es un usuario objetivo
RabbitHole era para gente curiosa. Suena a público objetivo, pero es un estado de ánimo. Todo el mundo siente curiosidad por algo, así que nadie en concreto se levanta por la mañana pensando "necesito RabbitHole".
El producto estaba a medio camino entre ChatGPT, que es para todo el mundo, y NotebookLM, que es para estudiantes que trabajan con su propio material. Y a una persona normal le costaba imaginar el momento exacto en el que abriría RabbitHole en vez de preguntarle directamente a ChatGPT. Si yo no soy capaz de describir ese momento en una frase, alguien que está haciendo scroll en LinkedIn no lo va a adivinar por mí.
Lo irónico es que StudyMesh, la versión anterior, tenía un público mucho más claro: un estudiante a una semana de un examen. Eso es una persona, con una fecha límite y un problema. Quise hacer la idea más grande abriéndola a todo el mundo, y lo único que conseguí fue que nadie la necesitara.
2. Un MVP que tardó dos años
Un MVP debería responder a una pregunta de la forma más barata posible: ¿alguien necesita esto? El mío pasó dos años respondiendo a otra: ¿qué más puedo construir?
Nunca puse por escrito una hipótesis. Cada versión salía de la anterior, a base de experimentar y de la idea que me tuviera enganchado ese mes: widgets con IA, luego rutas de estudio, luego mascotas, luego pódcasts. Durante largas temporadas no tenía nada concreto que validar, así que construía la siguiente funcionalidad. Y así es como el desarrollo deja de ser iteración validada y se convierte en experimentación sin rumbo.
Todo lo que importa de RabbitHole (una guía explicada a partir de lo que ya sabes) se podría haber probado en un par de meses. Las zanahorias podían esperar.
3. Sin métricas no hay respuestas
Esta es la que más me fastidia, porque era muy fácil de evitar.
No medí el embudo de conversión: visita a la landing → registro → primera guía creada. Sin eso, 12.091 impresiones son solo un número. ¿La gente vio el post y no hizo clic? ¿Hizo clic, vio la landing y se fue? ¿Se registró y nunca creó una guía? ¿Creó una y no volvió? Cada caso tiene una solución completamente distinta, y no tengo ni idea de dónde estuvo el problema.
Doce mil impresiones, y lo único que he aprendido de ellas es que debería haberlas medido.
4. Validación a golpe de WhatsApp
Mi feedback venía de un grupo de WhatsApp: mis tres hermanos, todos desarrolladores, y seis o siete amigos. Son listos, sinceros y generosos con su tiempo. Pero no eran el usuario objetivo, y la gente que te quiere no es la más indicada para decirte que tu producto no hace falta.
Echando la vista atrás, el feedback más valioso que recibí fue el primero, sobre AquaMesh (la versión previa de todo esto): buena idea, pero poco práctica. Mi respuesta fue cambiarle el nombre al producto y añadirle IA. Lo que debería haber hecho es sentarme con estudiantes de verdad, preguntarles cómo estudian realmente y construir lo mínimo que les ayudara con ello.
Qué haría diferente
- Elegir un usuario concreto. No "gente curiosa", sino alguien con nombre y apellidos, un momento concreto y un problema.
- Construir el MVP en semanas, no en años, y que valide un único problema central.
- Escribir la hipótesis antes que el código. Si no hay una hipótesis clara, la siguiente funcionalidad probablemente sea una apuesta a ciegas.
- Medir la conversión desde el primer día: visitas a la landing, registros y la primera acción real.
- Validar con gente que encaje con el usuario objetivo, no solo con amigos y familia.
- Preocuparme tanto por el "porqué" como por el "cómo". ¿Por qué alguien usaría esto en lugar de lo que ya usa?
Ese último punto es en el que estoy trabajando ahora. El desarrollo de software me enseñó cómo construir cosas; nunca me obligó a preguntarme por qué alguien las querría. Por eso me leí Escaping the Build Trap, de Melissa Perri. La "build trap" es lo que pasa cuando un equipo mide el éxito por las funcionalidades que lanza en lugar de por el valor que aporta, y leerlo después de RabbitHole ha sido un poco incómodo, en el buen sentido. Yo era un equipo de una sola persona metido de lleno en esa trampa.
RabbitHole no encontró a sus usuarios, pero a mí sí me ayudó a encontrar una forma mejor de trabajar: soy mejor desarrollador por haberlo construido, y tengo más visión de producto después de ver cómo no vendía.
La app sigue online y el conejo sigue respondiendo preguntas. Si te pica la curiosidad, prueba una guía: no hace falta registrarte.
Y la próxima vez, lo primero no será el producto. Será la pregunta.