OpiniónProduct Maker, del problema al productooctubre de 20266 min de lectura

La IA me permitió construir TaplyLab, pero lo difícil no era construir

Con IA se construye un prototipo en horas. Lo que no se consigue en horas es saber si alguien lo quiere. Esto me enseñó TaplyLab, mi proyecto del programa AI Product Maker (hoy AI Product Builder) de The Hero Camp.

¿Piensas hacer el curso? Ve a las preguntas →

TaplyLab es una plataforma de microlearning gamificado que construí en 6 semanas como proyecto del programa AI Product Maker de The Hero Camp (hoy AI Product Builder). Cuento qué hice, qué aprendí y qué le diría a quien se esté planteando hacerlo. También lo incómodo.

Transparencia: fui alumna del programa de The Hero Camp, pero no tengo ningún acuerdo comercial con ellos.

1. Validar la experiencia antes que la tecnología

Antes de definir el modelo de negocio, la arquitectura o la base de datos, creé varias versiones de una misma dinámica («Primeros auxilios: ¿mito o realidad?») con distintas herramientas de IA y las puse a prueba con personas reales, niños y adultos. Quería ver en directo cómo se consumía, qué enganchaba y qué no. Conclusión: la IA era el medio, no el producto. La gente quiere aprender y mejorar al menor coste y de la forma más llevadera, y ahí entra el juego: a nadie le pesa aprender primeros auxilios cuando es una partida.

La misma dinámica construida con tres herramientas de IA para probar la experiencia con personas reales

Si lo haces tú: prueba la misma idea con varias herramientas y enfoques y ponla delante de personas reales antes de decidir la arquitectura.

2. Un MVP para una sola pregunta

¿Es la experiencia lo bastante valiosa como para que haya gente dispuesta a consumirla antes de que nadie quiera crearla?

El MVP: sin registro ni herramienta de creación; el resto, después

Por eso el primer lanzamiento no tenía registro ni herramienta de creación: cinco formaciones genéricas definidas «a pelo» como JSON, y una landing para jugarlas, valorarlas y compartirlas. Para algunos esto sería empezar la casa por el tejado, pero ¿para qué desarrollar una plataforma completa si lo que sale de ella a lo mejor no aporta valor a nadie? En cambio, funcionó: los usuarios empezaron a competir por el ranking de cada formación, e incluso las compartían y repetían varias veces. Aislé el modelo de datos desde el principio, porque la experiencia formativa era donde más iba a iterar: ese era el núcleo del producto.

Si lo haces tú: define muy bien la pregunta que tu MVP tiene que responder y recorta todo lo que no la responda.

3. Lo que no vi venir

Puse tanto foco en el entregable que descuidé el proceso de creación. Mi modelo era un PLG clásico: los creadores atraen consumidores y estos acaban siendo creadores. Pero sin los primeros no hay segundos, y a ellos les daba una experiencia pobre, sin motivación ni gamificación. ¿Cómo va a transmitir valor y confianza para crear contenido espectacular una herramienta «sosaina»? No puede. El valor para el usuario clave quedaba lejos de su primer contacto con el producto. Seguro que lo has visto en muchos SaaS, ¿verdad?

Si lo haces tú: mira tu producto con los ojos de quien lo usa, no solo de quien consume el resultado de su uso: ¿cuándo toca por primera vez el valor? Te recomiendo leer sobre el aha moment y el ciclo de entrega de valor para este punto.

4. Lo que no repetiría con la IA

Dejé que la IA asumiera gran parte del diseño de interfaz y no dediqué tiempo suficiente a una identidad visual propia. Seis semanas no dan para todo, y se nota: TaplyLab respira esa UI «correcta» y poco pulida de Lovable, Gemini, Base44, Cursor, Replit o Claude Code, y con el ojo un poco adiestrado se detecta enseguida. Para validar no era crítico, pero me dejó claro que la IA acelera y no sustituye el oficio del diseño. Con el código pasa igual: seguramente tenga deficiencias y deuda técnica, aunque mi background técnico me ayudó a sentar buenas bases.

Si lo haces tú: reserva tiempo para el diseño y revisa el código, no querrás verte refactorizando algo que ni siquiera ha visto aún la luz.

5. Medir desde el primer día

Una parte del tiempo la dediqué a instrumentar el producto y a montar un panel de análisis, para evaluar con números lo que cualitativamente intentábamos validar. Sin eso, todo lo anterior serían opiniones.

Y los datos de la versión beta fueron incómodos: 30 formaciones creadas, 135 jugadores únicos, 80 dinámicas completadas, 40,6 % de finalización y 4,3 sobre 5 de valoración. 6 de cada 10 personas que empiezan una formación no la terminan, y la retención de los creadores es casi nula meses después. No tengo todas las respuestas, pero sí datos con los que investigar.

Si lo haces tú: dedica tu primera semana a decidir qué vas a medir y cómo, y no lo dejes para el final. En este punto de validación es más crítico que una UI corporativa pulida o un código escalable.

Si estás pensando en hacer el curso

¿Para quién creo que tiene más sentido? Para perfiles con mindset de producto ya adquirido que quieren ir un paso más allá: prototipar o desarrollar producto funcional para validar y testear. Es una herramienta más de trabajo. También lo veo muy útil para quienes quieren liderar y levantar sus propios proyectos.

¿Y para quién no? Si te sientes más cómodo en una parte concreta del diseño de producto (solo research, solo diseño o solo go to market), se te puede hacer pesado, porque pasas de forma transversal por todas las fases y te metes de lleno en ellas. Además, aunque delegues el desarrollo en la IA, necesitas un conocimiento técnico mínimo: te tocará hacer integraciones, montar bases de datos, pensar en APIs, hooks, seguridad y servicios. Dicho de otro modo, meter las manos en el barro y tocar un poco de todo.

¿Qué hay que hacer cada semana y cuánto tiempo real me llevó? En mi edición (septiembre–noviembre de 2025), cada semana terminaba con un entregable del proyecto, así que la sensación de avance es muy tangible y motivadora. La segunda semana fue la que más me gustó: definimos el producto, el modelo de negocio, el MVP y la arquitectura. Después vinieron las fases de diseño, integraciones, go to market, traspaso (handover) y el pitch de presentación. Yo dedicaba entre 3 y 5 horas extra a la semana, además de las clases.

¿Hace falta saber programar? Me lo preguntan mucho perfiles que quieren dar el salto a PM sin venir del desarrollo, y mi respuesta es clara: no hace falta, pero si sabes, será una ventaja competitiva que te diferenciará como PM al visualizar oportunidades y proponer soluciones técnicas. Por mucha IA que haya de por medio, seguimos construyendo soluciones digitales basadas en lenguajes de programación y arquitectura técnica. El conocimiento es tu aliado.

¿Qué me llevé que no esperaba? La seguridad y la confianza de poder levantar un proyecto de principio a fin sin bloqueos ni dependencias. Y la soltura con herramientas de vibe coding aplicadas a la experimentación como herramienta de trabajo en el día a día de mi rol de PM: plantear soluciones, prototiparlas y llevarlas a la conversación con el equipo y los stakeholders hizo esas conversaciones más valiosas y productivas.

¿Merece la pena? Sí, si te gusta construir cosas. Invertirás tiempo, pero más allá del aprendizaje teórico (que hoy está al alcance de todos y caduca rápido), te llevas la puesta en práctica de lo que ya sabías y de lo nuevo. Ahí está la magia: no va de lo que te cuentan, sino de lo que construyes tú con ello.

El programa cambia con cada edición: para ver el actual, consulta la página oficial de The Hero Camp.

La IA ha abaratado construir, pero no ha abaratado entender ni definir una estrategia de producto. Levantar un prototipo de 0 a 1 puede ser cuestión de horas; lo que hay detrás ha cambiado poco. Es la misma idea que me llevé de La Product Conf, aplicada a un producto propio.