Construyendo Savia, estoy comprobando que la IA amplifica lo que tú ya sabes. Si llegas sin criterio, amplifica el caos. Si llegas con contexto y proceso, amplifica la velocidad.
En el último post sobre cómo estoy montando Savia os conté todo lo que hice antes de escribir una línea de código: documentos fundacionales, sistema de skills, gobernanza del proyecto. Todo ese contexto estratégico que, para mí, es lo que separa el “vibe coding” real del “pídele cosas a la IA y cruza los dedos para que te devuelva algo sensato”.
Después de ese trabajo de contexto inicial, llegó el momento de arrancar y ver si todo ese trabajo previo servía realmente para algo. Y lo primero que descubrí es que construir algo con IA cuyo resultado quieres controlar bien no se parece demasiado a escribir un prompt y esperar a la magia.
No fue abrir un editor y decirle “hazme una app de mentoría”. Fue algo mucho más parecido a entrar en una sala con un equipo nuevo que acabas de formar, sentarte con ellos, y decir: “vale, ¿por dónde empezamos?”.
“Equipo, ya tenemos toda la info en la mesa. ¿Por dónde arrancamos?”
En lugar de dar instrucciones, hice algo que cualquier PM reconocerá: pedí una propuesta.No le dije a Claude qué hacer. Le pedí que me dijera qué creía que deberíamos hacer con todo el contexto que le había dado previamente y teniendo unos objetivos claros definidos. El prompt literal fue este:
« Claude, he terminado de subir toda la documentación del proyecto Savia. Activa todas tus Skills y asume tu rol de Staff PM. No me pidas instrucciones. Quiero que seas tú quien me proponga la hoja de ruta inmediata para las próximas 24 horas. ¿Qué es lo primero que deberíamos definir para que este MVP sea una realidad cuanto antes? Presenta tu propuesta y justifícala. »
Esto es lo que muchos llaman un prompt de arranque pasivo. Es el equivalente a entrar en la sala de reuniones y decir: “equipo, ya tenéis todo el contexto. Decidamos por dónde empezar, por qué y cómo”.
Si la propuesta que te devuelve es buena, sabes que el contexto que preparaste está bien construido. Y si es mala, sabes exactamente qué falta. Es un test del sistema, no un acto de fe.
La propuesta fue buena. Proponía empezar por dedicar algo más de tiempo a enriquecer el contexto que teníamos: definir el problema, la audiencia, la propuesta de valor, anticipar posibles problemas y riesgos, y definir las métricas de éxito antes de tocar nada técnico. Exactamente lo que yo habría hecho.
El Product Brief y el análisis de competencia
A partir de ahí, el proceso fue product discovery normal, pero a una velocidad de x5 o x10. Definimos el problema que resolvemos, para quién, y cómo. Establecimos la estrategia de lanzamiento, los objetivos y las métricas que nos dirán si vamos bien. Consolidamos todo en un Product Brief.
Después le pedí que investigara competidores. Claude analizó 13 plataformas de mentoría — desde ADPList (800K usuarios, respaldada por Sequoia) hasta asociaciones españolas como SECOT — y produjo un análisis que yo habría tardado días en hacer.
Es cierto que se fue dejando algunas fuera. Pero le pedí que estuviera atento a un tuit donde pedí a la comunidad si tenía más referencias y las fue incorporando a su análisis.
Sobre su análisis, yo le fui dando feedback de cuáles consideraba competidores más directos y cuáles no, y los motivos. Eso le ayudó a saber en qué fijarse y entender cuál era mi argumentación.
La conclusión más importante: no existe competidor directo que combine mentoría profesional 1:1, multi-sector, en español, para profesionales en carrera corporativa. ADPList es la amenaza principal pero es tech-focused, en inglés, con problemas de calidad y una UX cuestionable. Ventana de oportunidad: 6-12 meses.
Con esos insights, invoqué la skill de PMM (Product Marketing Manager) para iterar los copies y reforzar lo que nos hacía diferentes. Cada palabra de nuestra landing ahí está porque un competidor no la tiene apropiada.
Disclaimer: con el resultado del PMM no estoy especialmente contenta. Es una tarea pendiente ver cómo darle mejores skills para iterar la home más adelante.
La priorización: comparar iniciativas para decidir qué entraba en el MVP y qué no
Aquí vino una de las sesiones más útiles de toda esta fase: el ICE scoring para decidir qué entraba en el MVP y qué no. Pedí a Claude montar una sesión que lanzara en paralelo tres agentes: Product Manager, Product Designer y Software Engineer. Replicar un product trío en modo agéntico, vaya.
La sesión la liderá el Staff PM, pero involucró también al Designer y al Software Engineer — porque el Impact lo evalúa producto, pero el Ease lo evalúa quien va a construirlo.
Evaluamos cada feature candidata en tres dimensiones: Impact (¿cuánto mueve la métrica norte?), Confidence (¿cómo de seguros estamos de que podemos hacerlo?) y Ease (¿cómo de fácil es implementarlo?).
Las features core del MVP (signup, perfiles, búsqueda, solicitudes, coordinación, dashboards, emails, NPS) salieron todas por encima del threshold de 6. La más alta fue Signup con un 9.67 — bloqueante absoluto, sin mentores no hay producto. La más baja fue Coordinación con un 7.67, donde el Ease subió 2 puntos cuando decidimos hacer un sistema híbrido (coordinación en plataforma + manual como fallback) en vez del sistema completo.
Pero lo interesante fue lo que se quedó fuera: vacation mode para mentores, valoraciones públicas, matching automático por algoritmo, sistema de referrals, rol dual (ser mentor y mentee a la vez). Todas ideas tentadoras. Todas con un ICE que no justificaba meterlas en un MVP.
Disclaimer: viendo el feedback inicial y teniendo en cuenta mi criterio, creo que el ICE no evalúa bien la feature del rol dual. Es una de las cosas que creo que vamos a tener que incorporar antes.
Donde la cosa se pone interesante: el debate a 3 bandas
Cuando tocó diseñar los wireframes, los fuimos creando flujo a flujo. Y cuando estuvieron los 8 listos, hice algo que también fue un momento guay para el proyecto.
Volví a activar tres skills distintas — Staff PM, UX Designer y Critical Auditor — y les pedí que revisaran cada wireframe desde su perspectiva. No una revisión genérica. Una auditoría estructurada donde cada rol aplica sus propios criterios.
El resultado fue una sesión que produjo un informe de validación con 44 issues detectados. Pero lo interesante no es el número. Es cómo cada perspectiva veía cosas distintas en el mismo diseño. Por ejemplo, en el wireframe de onboarding para mentores:
- El Staff PM detectó que la bio de 100-500 caracteres era una barrera alta con riesgo de 40-60% de abandono. Propuso añadir ejemplos y templates.
- El UX Designer vio que la preview del perfil no se actualizaba en tiempo real — mostraba placeholders estáticos en lugar de lo que el mentor iba escribiendo. También encontró que faltaba drag & drop para la foto y que el contador de caracteres no funcionaba.
- El Critical Auditor encontró el issue más grave: no había autosave. Un mentor podía pasar 15 minutos rellenando su perfil, cerrar el navegador por error, y perderlo todo. Lo clasificó como P0 bloqueante y estimó un 30-40% de abandono por frustración.
Ese P0 no lo habría encontrado yo sola. O lo habría encontrado después, cuando algún mentor real hubiese perdido sus datos y me hubiese escrito frustrado.
Hubo otro momento más pequeño que también me enseñó algo interesante. Estaba revisando los wireframes antes de empezar a implementar y vi dos cosas que me chirriaban: un badge de “Perfil verificado” sin proceso de verificación real, y un botón de “Favorito” desactivado con un “Disponible próximamente”.
Le pedí a Claude que lo analizara con la skill de Staff PM. No le dije “quita esto”. Le pregunté si deberíamos quitarlo. Y aplicó exactamente los frameworks que yo le había enseñado semanas antes: articuló el JTBD de cada elemento, calculó el ICE Score (4.67 — por debajo del threshold), detectó que el badge era un deceptive pattern con riesgo legal, y recomendó eliminar ambos. Cinco minutos, dos decisiones de producto, y varias líneas de código menos tiradas.
La IA amplifica lo que tú ya sabes
Si tuviera que quedarme con una sola cosa de estos primeros días, es esta: la IA amplifica lo que tú ya sabes. Si llegas sin criterio, amplifica el caos. Si llegas con contexto y proceso, amplifica la velocidad.
Trabajar con Claude Code como PM no se parece a programar. Se parece más a dirigir un equipo muy capaz que necesita que tú tengas las ideas claras. Que ejecuta a una velocidad brutal, pero que depende de que tú entiendas lo que está pasando — no solo aceptes resultados.
No puedes delegar el criterio. Si no entiendes por qué Claude propone algo, tienes un problema. Si no cuestionas lo que genera, tienes un problema mayor. La IA no piensa por ti. Te obliga a pensar mejor, porque te devuelve las cosas tan rápido que no puedes esconderte detrás de “ya lo revisaré luego”.
En los próximos posts contaré qué pasó cuando empezamos a codear de verdad — infraestructura, decisiones de stack, los primeros despliegues. Pero si algo quiero que os llevéis de este, es que la diferencia entre “vibe coding” como lo vende el hype y cómo funciona realmente es enorme. No es magia. Es proceso. Pero es proceso a una velocidad que cambia las reglas del juego.
Y vosotros… ¿habéis probado a trabajar así con IA? ¿Pedís propuestas o dais instrucciones?
Si has llegado hasta aquí y te apetece mentorizar o ser mentorizado en Savia, regístrate. Si no te convence el proyecto después de leer esto, dame feedback y cuéntame por qué.
Artículos anteriores de la serie:
