Construyendo un side-project para experimentar mejor cómo evoluciona nuestra manera de hacer producto en la era de la IA

Llevo 13 años haciendo productos digitales. He liderado equipos, definido roadmaps que movieron MRR, lanzado features en startups B2B de Fintech, Insurtech, HR Tech. Pero nunca había construido nada con mis propias manos.

No (sólo) por falta de ideas. Sino por una creencia limitante que muchos perfiles de Product Management compartimos: “Sé diseñar productos, pero no podría construirlos”.

Llevo con deportividad esto de tener un alma de developer frustrada. Me da envidia (sana, pero mucha envidia) la gente con conocimiento técnico porque es capaz de hacer la magia y convertir una idea en algo con vida.

Sí, se lo que estás pensando…. Otro artículo de una que se va a poner a hablarme de vibe coding y que va a lanzar una app que nadie usará o que, incluso peor, no funcionará.

Y es posible que lleves razón. Muy posible.

He venido a contarte que estoy dedicando algunos huecos a un pequeño side-project. Una idea que me rondaba en la cabeza y que es la excusa perfecta para experimentar desde cero cómo todas las herramientas de IA están cambiando la forma de hacer producto en las empresas.

Mi objetivo no es tanto hacer un producto que funcione y que tenga tracción. El objetivo real que persigo es tener un campo de pruebas E2E para ver cómo podemos evolucionar las maneras de trabajar en producto digital gracias al empoderamiento de la IA.

Y haciéndolo en un pequeño proyecto que estoy creando desde cero y sin conocimiento técnico ni de diseño me permitirá ver qué hacks encuentro para apoyarme en la IA en todo tipo de tareas: refinar ideas de negocio, hacer research de competidores, montar prototipos, hacer de Claude Code mi equipo técnico….


?

La idea: Savia

Llevo años siendo una persona a la que le piden intros constantemente. “Ana, ¿me puedes conectar con alguien que entienda de analítica de producto?” “¿Conoces a alguien en fintech con quien pueda hablar?” Y claro, lo hago encantada. Porque sé lo que es necesitar esa conversación.

Tengo la suerte de tener una red de contactos amplia. Cuando necesito aprender algo nuevo —cómo escalar un equipo más rápido, cómo enfrentarme a un reto de producto, cómo contratar mejor— lanzo algún un mensaje de LinkedIn o WhatsApp y en 48 horas estoy tomando un café con alguien que ya pasó por ahí.

Ese acceso no debería ser privilegio de unos pocos. Tu red de contactos no debería estar limitada sólo al círculo de gente que has conocido estudiando o en tu primer trabajo. No deberías ser capaz de ampliar tu red de contactos sólo si tienes la suerte de conocer a gente que pueda presentarte a otros. Y sin embargo, esa es la realidad de muchos profesionales que arrancan.

Así que la idea es simple: hay profesionales senior con décadas de experiencia que quieren compartir su conocimiento, y hay jóvenes profesionales desesperados por hablar con alguien que “ya llegó” para validar sus decisiones de carrera.

El problema no es nuevo. Lo que es nuevo es cómo quería resolverlo: un sitio donde mentorizados puedan entrar en contacto con mentores para sesiones 1:1.

  • Lado oferta: los mentores. Profesionales consolidados con trayectoria real en sus sectores. Gente que sabe lo que es liderar equipos, cerrar deals, pivotar estrategias, gestionar crisis. Y que quiere que ese conocimiento no se quede en su LinkedIn.
  • Lado demanda: los mentorizados. Profesionales en sus primeros años que buscan guía táctica. Cómo enfrentar un reto que es nuevo para ti. Cómo gestionar un proyecto que se va de madre. Cómo saber si tu manager es tóxico o es que tú eres junior y no lo ves claro.

¿Y el gap? Existen plataformas de mentoría. Algunas son buenas si trabajas en tech o buscas emprender. Otras son muy institucionales, enfocadas en nichos de grandes corporates. Algunas te proponen programas cerrados con un plan de mentoría que parece un máster. Pero no he encontrado lo que a mí me gustaría encontrar: un sitio donde mentores y mentorizados puedan encontrarse y quedar para un 1:1 digital en el que intercambiar dudas y experiencias. Sin ruido, sin 500 personas en un canal de Slack, sin postureo. Una conversación privada con alguien que no tiene agenda contigo y te da honestidad radical.

Ahí es donde entra Savia. Un rincón digital que creo que podría servir para poner en contacto talento senior que puede mentorizar desde su experiencia con talentos junior que están arrancando en sus carreras y necesitan guía profesional.

El nombre no es casual: evoca “savia nueva” (la juventud, la energía, el potencial de lo que está creciendo) y “sabiduría” (la experiencia, el bagaje, los años de aprendizaje). Un intercambio donde ambos lados ganan.

Mi objetivo: 20 mentores activos y 10 sesiones de mentoría completadas en 2/3 meses. Pero había un problema. Yo no sé programar.

Tengo un poco de miedo a que esto vea la luz antes de ajustar un par de cosas que me están dando problemillas en Vercel, Resend y Supabase. Así que dadme un par de días para lanzar y por ahora dejo sólo algunos screenshots. Si te interesa, pronto podrás juguetear y fundirme a feedback.


El miedo técnico es real

Durante años he trabajado con developers. He especificado PRDs, he revisado arquitecturas, he dado feedback a product designers, he definido métricas con product data analysts, he debuggeado problemas de implementación con el equipo de ingeniería.

Entiendo perfectamente conceptos como APIs, bases de datos relacionales y he visto suficiente código para leer un diff en GitHub y entender qué está pasando. Pero nunca había escrito una sola línea de código funcional.

Y eso genera un miedo muy específico: “¿Y si mi conocimiento de producto no es suficiente? ¿Y si necesito entender de verdad cómo funciona React para poder construir esto?”

La respuesta que quiero ver si es válida es ésta: no necesitas saber programar. Necesitas saber diseñar sistemas. Y eso, como PM o CPO, ya lo (deberías) sabes hacer.

Lo que necesitas es un equipo técnico que te entienda perfectamente. Que sepa traducir tus ideas de producto a arquitectura técnica. Que no te juzgue por preguntar cosas obvias. Y decidí que ese equipo iba a ser Claude.


El experimento: construir E2E solo con IA

No es “aprender a programar”. Es experimentar cómo la IA cambia el rol del PM cuando eres tu propio equipo técnico.

He hecho todo el ciclo con Claude Code: desde diseñar la arquitectura, definir todos los flujos, hasta tener algo funcionando en producción.

No es perfecto. Seguro que hay bugs que no he visto. Pero funciona lo suficiente como para querer probarlo con usuarios reales. He descubierto cosas interesantes.

  • Lo que funciona aceptablemente bien: Iterar UX rápido. Cambiar pantallas, reorganizar flujos, ajustar validaciones. Implementar features completas cuando sabes explicar claramente qué quieres. Debugging básico (”este botón no funciona” ? Claude lo encuentra en segundos).
  • Lo que sigue siendo difícil: Decisiones de arquitectura de alto nivel. ¿Qué stack elegir? ¿Qué trade-offs técnicos aceptar? Problemas raros que solo pasan en producción. Bugs que aparecen solo en ciertos navegadores o con ciertos datos. Saber qué preguntar cuando no sabes qué no sabes.

Pero lo más importante que descubrí es esto: puedo construir. Realmente parece que puedo hacerlo. No tan rápido como un equipo de ingeniería experimentado. Pero infinitamente más rápido que sin IA. Y lo suficientemente bien como para tener un MVP en producción.

Iré contando en detalle cómo he hecho cada parte. Los aciertos, los atajos que tomé, y todas las formas en las que probablemente me equivoque y la cague.


Todo lo que puede (y va a) salir mal

Porque seamos honestos. Este experimento tendrá más agujeros que un queso gruyere. Y está bien. Porque mi objetivo no es que Savia funcione como startup escalable. Es aprender qué significa hacer producto cuando la IA es tu equipo.

Aquí está todo lo que se que puede ir mal. Ya tengo identificados muchos riesgos de cosas que pueden no funcionar y torcerse, y seguro que me encuentro muchos más inesperados:

  • No enfocarme en un nicho. Quiero que Savia no esté acotado a un único sector profesional. Hay soluciones parecidas que han arrancado enfocadas en nichos como emprendedores o profesionales tech. Pero yo quiero intentar ser generalista. Que en Savia puedas encontrar mentores de marketing, fintech, operaciones, HR, producto… Y con eso me estoy generando un auténtico supply nightmare. Me estoy metiendo en la clásica trampa de: si eres demasiado genérico, te costará tener mentores (supply) y sin eso, no tendrás mentorizados (demanda). ¿Cómo validas product-market fit cuando tu audiencia es “cualquier profesional que necesite un mentor”? Spoiler: probablemente no puedas. Pero quería ver qué pasa si ignoras esa regla básica de startups.
  • Sin roles dobles en el MVP. Por ahora, no puedes ser mentor y mentorizado al mismo tiempo. Esto limita casos de uso reales, porque mucha gente aprende y enseña simultáneamente. Pero implementar roles duales en un MVP de una persona es complejidad que no necesito ahora. Así que lo dejé fuera, sabiendo que es una limitación crítica.
  • Producto de una sola transacción. Encuentras tu mentor, haces tu sesión, te va genial, nunca vuelves. Para montar un negocio recurrente, es pésimo. No hay retention, no hay LTV predecible, no hay growth loops. Pero para una ambición de crear conexiones altruistas, igual funciona perfectamente. Solo que no es un negocio.
  • Las conexiones pasan fuera de la plataforma. Una vez que mentor y mentorizado se encuentran, se van a Google Meet. Tienen su sesión. Y yo no me entero de nada. ¿Pasó la sesión? ¿Fue útil? ¿Volverán a hablar dentro de la plataforma o se irán fuera? No lo sé. ¿Cómo mides éxito si no controlas la transacción? Respuesta: confías en que la gente te cuente. O implementas NPS post-sesión. O aceptas que vas a volar a ciegas durante meses.
  • Todo lo técnico que puedo romper. Meter una cagada en producción y tirar la base de datos. Romper todo con un commit mal hecho. No saber debuggear un error raro. Pelearme con queries que no entiendo. Descubrir que mi arquitectura no escala cuando llegue al usuario 100. Todo esto va a pasar. Es cuestión de tiempo.

Y todo esto está bien. Porque mi objetivo no es que Savia funcione como negocio. Es aprender qué cambia en las maneras de trabajar cuando piensas en hacer producto integrando la IA como una herramienta poderosa en todo el equipo: diseño, producto, data y desarrollo.


Por qué voy a documentar todo esto

¿Qué decisiones se aceleran? ¿Cuáles se complican? ¿Dónde la IA te sorprende? ¿Dónde te decepciona? ¿Cómo evoluciona tu manera de hacer producto cuando no tienes que convencer a un equipo de ingeniería de que tu idea vale la pena, porque puedes prototiparla tú mismo en 2 horas?

Voy a ir contando el paso a paso aquí. Los progresos, las cagadas, los aprendizajes. Qué funciona, qué se rompe, y cómo voy ajustando el producto basándome en feedback real de usuarios reales.

Por si a alguien le sirve. O al menos le divierte ver cómo me estrello.


Así que ya está. Tengo un side-project que se llama Savia. Probablemente fracase en múltiples frentes. No tengo un nicho claro, no sé si la gente volverá, y lo más probable es que rompa producción al menos tres veces antes de marzo.

Lo peor que puede pasar es que aprenda. Lo mejor que funcione y aporte valor a alguna persona. Que consiga esos 20 mentores y esas 10 sesiones. Y que mi problema sea descifrar cómo sacar algo de pasta para pagar Vercel y Supabase.

Si te apetece seguir el experimento (o tienes consejos de cómo no cagarla tanto), estaré publicando por aquí.

Ser PM no es (¿sólo?) gestionar backlog

¿Te has parado a pensar en cuál es la creencia, el principio o la convicción en la que más has evolucionado como profesional?

Yo es algo que hago de manera concienzuda cada vez que abro una etapa laboral: pienso en cómo era mi forma de trabajar cuando llegué y en qué he aprendido y cambiado (a mejor) cuando me voy. Cada trabajo lo vivo como una historia que quieres contar, de objetivos que tenías, de retos que superaste (? o no) y de aprendizajes que te llevas (de cosas a repetir y de cosas a evitar ?).

Si pienso en qué es lo que más ha cambiado mi visión de qué significa trabajar en un rol de producto, creo que sin duda es mi entendimiento de que el foco principal de un Product Manager no es gestionar el backlog, hacer refinamiento de iniciativas ni planificar los ciclos de desarrollos o liderar las dailies.

Recuerdo bien cuando en Aplazame, al empezar a crecer hasta ser 5 equipos de producto, contratábamos a Product Manager pero los llamábamos ? Product Owners. Incluso me recuerdo hace más de 5/6 años dudando sobre si debía sacarme alguna certificación o contratar un Scrum Master. ¡Sí que ha llovido desde entonces!

? Hoy resumo el foco de un PM en algo sencillo: vender productos que solucionan problemas por los que un número suficiente de clientes está dispuesto a pagar un precio rentable.

Solucionar problemas

Si trabajas en producto, tienes que estar más enamorado de los problemas de los clientes que de las soluciones que busques para ellos.

Enfócate en descubrir qué problema existe ahí fuera que merece la pena resolver, para quién quieres resolverlo, por qué ahora y por qué el mejor para resolverlo eres tú (tu equipo, tu división, tu compañía).

A un número suficiente de clientes

Parte de asegurarte que el problema que has elegido merece ser resuelto es validar que existe un mercado potencial suficientemente grande.

  • ¿Has calculado cuál es el mercado disponible total (TAM – Total Available Market) que existe para ese problema?
  • ¿Y cuál es el mercado al que crees que tú podrías servir (SAM -Serviceable Available Market) teniendo en cuenta barreras de distribución, de precio, culturales, de idioma, etc?
  • ¿Y qué porcentaje del mercado tendrías que conquistar (SOM – Serviceable Obtainable Market) para tener unos números relevantes y sostenibles?

Si encuentras un problema pero es tan nicho o tan pequeño que es irrelevante, no podrás montar un negocio alrededor de él.

Dispuestos a pagar

Espero que algún día dejemos de debatir sobre lo de empresas sales-led o product-led¿Cómo puede ser una empresa no sales-led? Salvo que tu objetivo no sea generar negocio, no te queda otra que estar hablando de ventas.

Un recordatorio: no todos los problemas merecen ser solucionados si quieres hacer negocio con ellos.

  • Tus potenciales clientes deben ser conscientes de que tienen ese problema.
  • El problema debe ser grande o lo suficientemente recurrente como para que crean que les merece la pena invertir en un producto que les ayuda a solucionarlo.
  • Deben tener presupuesto y estar dispuestos a invertirlo en solucionar ese problema.

Cada 2 jueves con el café?. Descubre, cuestiona y nútrete de experiencias de Producto contadas #desdelbarro

Un precio que para ti sea rentable

Ser capaz de encontrar, junto con los equipos de ventas, de operaciones y de finanzas, el esquema de precios que te hace competitivo a la vez que te salen buenos Unit Economics.

No es sólo que el número de clientes sea lo suficientemente grande, que estén dispuestos a pagar por el problema y que estén dispuestos a pagarte a ti…. es también que lo que te paguen te permita desarrollar un negocio que sea escalable y rentable.

? Si como PM tienes que estar enfocado en todo esto ¿cómo de importante es para ti la gestión del backlog y cuánto foco tienes que poner en el delivery? Nuestro trabajo va más del “do the right thing” que del “do the things right”.

Es fácil como PM caer en la urgencia de lo más inmediato y enfocarte en cosas muy tácticas: escribir una bet, refinar una iniciativa, redactar una épica, convocar una reunión de refinamiento o ponerte a hacer algo de QA o reporte de bugs. Todas esas tareas son necesarias, pero no te necesitan a ti como PM con todo tu foco.

Algunos mantras que me repito día tras día para re-enfocarme en lo que de verdad puede mover la aguja.

1 Pasa más tiempo “fuera del equipo” que dentro.

En tu día a día, deberías estar interactuando más con clientes, prospects, ventas o CX que con los Product Designers, los Engineering Managers o los Product Engineers. Ahí es donde vas a aprender qué problemas necesita seguir resolviendo tu producto, cómo compara con competidores y qué es lo que aporta más valor.

2 Tu momento clave con tu equipo es definir qué queréis resolver y cuánto tiempo queréis dedicar a ello.

Con el equipo de diseño y desarrollo, asegúrate de tener dinámicas de trabajo que te permitan hacerles partícipes del problema que decidáis atacar en cada momento, que entiendan por qué lo vais a atacar ahora, para quién lo vais a resolver, qué impacto consideras que puede tener en el negocio y qué métricas clave os ayudará a mejorar.

Una vez que prioricéis juntos el problema y los porqués, deja que ellos se encarguen de la solución. ¡Ojo! Que esto no significa que como PM te despegues de la solución. Parte de tu trabajo es vigilar que la solución que el equipo proponga resuelve el problema y lo haga de forma global y escalable… pero no aportas nada metiéndote hasta el detalle más fino en la ejecución.

3 No hagas babysitting ni project management

Es una obviedad, pero trabajas con gente lista y muy capaz. Decidid qué vais a priorizar, por qué y cuánto tiempo queréis dedicar a resolverlo.

Con eso, la definición del scope, el delivery y el QA es de ellos. Los EMs y los Product Engineers deben empujar por sacar cosas a producción; no necesitan que estés preguntando cómo van continuamente.

4 Una funcionalidad no se termina cuando sale a producción.

He escuchado a Simón Muñoz repetir mucho su “entregar no es suficiente” y no puedo estar más de acuerdo. Una funcionalidad que se lanza pero no se vende o no se usa no será nunca un éxito. No tendrá impacto. No moverá la aguja.

Mientras el equipo trabaja en el desarrollo, enfócate en preparar que sucedan varias cosas

  • Estrategia de release. ¿La vas a activar para todos los clientes a la vez? ¿Vas a hacer un soft release para validar bajo una feature flag primero y la abrirás a todos después? ¿Es una funcionalidad que activarás sólo a clientes con un plan de precios concreto? ¿Tienes que dejar fuera a clientes con planes de precios legacy?
  • Estrategia de Go-To-market. ¿Cómo se va a anunciar esa funcionalidad a clientes y prospects? Habla con el equipo de product marketing y de demand generation para ver cómo vais a posicionar ese nuevo producto y funcionalidad y convénceles de si tiene que formar parte del GTM de las próximas semanas o el próximo trimestre.
  • Product Enablement. ¿Cómo te vas a asegurar de que toda la compañía conozca esta nueva funcionalidad? ¿Requiere de materiales de venta? ¿Tienes que añadir un nuevo artículo al Help Center? ¿Requiere de una sesión de training para el equipo de Customer Success? ¿Tienes que formar a los Account Managers para que puedan guiar a los clientes?
  • Feature discoverability. ¿Cómo vas a guiar a tus clientes para que descubran esa funcionalidad dentro del producto? A veces una newsletter o un webinar no son suficientes. ¿Qué puedes hacer para ayudarles a auto-descubrir esa funcionalidad? ¿para impulsar que comiencen a usarla? Si implica algún set-up ¿cómo les convences de invertir ese tiempo en configuración y aprendizaje a cambio del valor que les vas a entregar?
  • Product Usage. ¿Cómo vas a medir el uso de la funcionalidad? ¿Cuál va a ser la regla que defina tu métrica de uso? ¿Necesitas medir sólo la activación de la funcionalidad o también la retención? ¿Es una funcionalidad que esperas que utilicen todos tus usuarios o quizás necesitas hacer análisis por cohortes si sólo esperas que la usen unos pocos?
  • Pricing. Recuerda: estás solucionando problemas para hacer dinero con ello. Cada funcionalidad que lances es una oportunidad de ampliar el valor que capturas por el valor que entregas. ¿Vas a utilizar ese lanzamiento para hacer upselling a tus clientes de un plan business a uno entreprise? ¿Quizás la vas a usar para subir el precio de todos los planes? Planifícalo.

5 Mide el éxito (o el fracaso) y se crítico

Pregúntate qué métricas de negocio quieres impactar y mide el éxito que has tenido.

  • ¿Cuánto nuevo MRR (Monthly Recurring Revenue – una métrica que mide el total de ingresos recurrentes que logras en un mes) o ARR (Annual Recurring Revenue – lo mismo que el MRR * 12 meses) has cerrado gracias a esa funcionalidad?
  • ¿Te ha ayudado a incrementar tu Win Rate sobre el número de propuestas enviadas? Tu Win Rate es una métrica que te ayuda a saber cuántas oportunidades ganas o cuántas ventas cierras en relación con el total de oportunidades que luchas o de propuestas de contrato que envías.
  • ¿Te ha servido para reducir las closed lost opportunities y ser más fuerte frente a tus competidores? Si una funcionalidad te bloquea oportunidades de ventas, la estarás identificando como un motivo de closed lost (una oportunidad de ventas perdida).
  • ¿Has lanzado algo cuyo impacto ha estado en la reducción de bugs, incidencias o número de llamadas a tu call center?

A pesar de repetirme todos estos mantras, hay una regla de oro que utilizo para saber si tengo el foco en lo que debería. Al arrancar el lunes, hago una lista de los objetivos que tengo y, sobre todo, las cosas que me preocupan esa semana.

Si las cosas que te preocupan apuntan a algunas de todas estas cosas que hemos hablado, estás en el buen camino. Si las tareas que te estás planificando tienen que ver con hablar, escuchar, pensar y analizar, la cosa pinta bien. Si al contrario estás planificando cosas que tienen que ver más con hacer seguimiento, algo parece estar fallando.