Te cuento el caso porque es lo más parecido que vi, en la práctica, a un discovery con IA donde el PM casi no toca un IDE y, aun así, el equipo aumenta la velocidad y la calidad de aprendizaje.
Hablemos de un producto B2B SaaS de mid-market, con presencia en LATAM y Estados Unidos.
Su negocio vive y muere por una métrica: revenue expansión en cuentas existentes.
Tenían buena adquisición, pero poca activación de ciertas features claves y, por lo tanto, poco upsell.
El objetivo para el trimestre era concreto: mover la tasa de activación de una nueva funcionalidad de 18% a 30% en 90 días. Y acá viene la parte importante: lo tenían que hacer con casi cero capacidad adicional de desarrollo porque el equipo de ingeniería ya estaba comprometido con un roadmap pesado de deuda técnica.
En otras palabras:
- Muchísima presión de revenue.
- Poquísima capacidad de dev.
- Y un equipo de producto acostumbrado a discovery que tardaba semanas en traducirse en algo testeable.
Antes de Vibe Coding, el proceso se veía así.
El PM armaba un PRD eterno en un doc: contexto, hipótesis, user stories, ejemplos de copy, referencias, edge cases, criterios de éxito, requerimientos de tracking. Ese doc viajaba a diseño, que lo convertía en wireframes y luego en un prototipo navegable en Figma. Esto llevaba de 3 a 7 días, con suerte.
Después venía un handoff con ingeniería para ver si lo que se quería testear era “barato” de implementar en un experimento o si se necesitaba tocar media aplicación. Entre dudas, dependencias, PRs de otros equipos y prioridades de ventas, el “primer experimento simple” solía tardar 2 o 3 sprints en ver la luz.
Mientras tanto, el backlog de experimentos de discovery se convertía en un cementerio de ideas. Eran hipótesis bien pensadas, pero nunca llegaban a producción. No por falta de ganas, sino por fricción en la coordinación.
Y acá es donde entra Vibe Coding en la historia.
Vibe Coding Essentials
Cómo cambió con Vibe Coding
El mismo equipo decidió cambiar no solo la herramienta, sino la coreografía completa de cómo hacía discovery. En vez de pensar en discovery como “diseñar” y luego “pasar” a dev, lo redefinieron como: “convertir hipótesis en soluciones testeables lo más rápido posible con IA como copiloto”.
Cambio Nro. 1: De PRD a Conversación
El primer cambio fue super simple: el PM dejó de escribir PRDs. En lugar de un doc kilométrico, arrancaba con una pregunta limpia dentro de Vibe Coding:
“Quiero incrementar la activación de esta feature en este segmento de usuarios. Esta es la hipótesis, estos son los comportamientos actuales, estas son las restricciones de tech y negocio. Ayudame a diseñar 3 flujos de onboarding alternativos, con copy completo, condiciones de entrada y lógica de seguimiento”.
En minutos, el PM tenía variaciones de flujos:
Pantallas propuestas, texto completo, microcopys, mensajes de error, triggers de comportamiento basados en eventos, incluso sugerencias de instrumentación de datos. No eran diseños finales, pero eran lo suficientemente buenos para pensar la solución sin tocar aún un IDE.
Cambio Nro. 2: De Conversación a Prototipo Navegable
Segundo cambio: el PM empezó a crear prototipos navegables con la misma conversación. Sin cambiar de contexto ni esperar a diseño, pedía a la tool:
“Convertí este flujo en un prototipo navegable que pueda mostrar al equipo y a 5 clientes en entrevistas. Quiero poder simular diferentes paths según si el usuario hace X o Y”.
El resultado: un prototipo con navegación, estados y comportamiento mínimo suficiente para conversar con usuarios y stakeholders.
¿Perfecto visualmente? No.
¿Suficiente para validar si la dirección tenía sentido, entender objeciones y ajustar copy? Absolutamente.
Cambio Nro. 3: Ahora con los Datos
El tercer cambio fue todavía más profundo: el PM empezó a automatizar la parte de datos desde el mismo espacio.
En lugar de mandar requerimientos sueltos a data, pedía algo como:
“Generá el esquema de tracking necesario para medir esta hipótesis: eventos, propiedades, nombres consistentes con nuestro analytics actual y ejemplos de queries para evaluar: tasa de activación, caída por paso del flujo y time to value”.
De esa interacción salían no solo los nombres de eventos y propiedades, sino queries SQL o snippets listos para copiarlos en la herramienta de analytics de la empresa. La conversación pasaba de “deberíamos trackear esto” a “acá está exactamente cómo lo vamos a trackear y cómo vamos a leerlo”.
En la Práctica
Quiero bajar esto a un momento concreto: semana 1 del trimestre.
La hipótesis clave era: “Si personalizamos el onboarding de esta feature según el rol del usuario en la empresa y el momento de uso, vamos a aumentar la activación en al menos 20%”.
Lunes, 9:00 AM. El PM comienza Vibe Coding con datos cualitativos y cuantitativos de la situación actual. A las 10:00 AM ya tenía tres variantes de flujo propuestas (simple, avanzada y gamificada), cada una con su copy, reglas de entrada y salida, y una sugerencia de cómo instrumentar los datos para compararlas.
Al mediodía, el PM había usado Vibe Coding para convertir la mejor variante en un prototipo navegable. A las 15:00, lo estaba mostrando a 4 clientes en entrevistas de usuario agendadas previamente. No era un “concept board”, era un flujo end-to-end que el usuario podía “usar” simulando su contexto real.
Martes, 10:00 AM, después de las entrevistas, el PM volvió a Vibe Codear con lo aprendido y pidió:
“Refina el flujo y el copy según estas objeciones específicas que escuchamos. Manteniendo el mismo scope, hazlo más claro para un usuario que entra por primera vez y tiene poco tiempo”.
En una hora, tenía una v2 del flujo y el prototipo actualizado. Mientras tanto, trabajaba con un dev disponible en el equipo para elegir la forma más barata de implementar un experimento real: una capa de configuración sobre el onboarding existente, sin tocar demasiadas piezas del core.
Mi parte favorita de este caso es el tiempo al primer experimento en vivo.
Antes de Vibe Coding, hablar de “primer experimento en 48 horas” sonaba a wishful thinking.
En este caso, el primer experimento estaba corriendo en producción el miércoles por la tarde.
No era la versión final ni el flujo “perfectamente diseñado”. Era una implementación mínima pero medible y alineada a una hipótesis clara, nacida de un proceso de discovery atravesado por IA de punta a punta. Discovery y delivery dejaron de ser dos mundos separados, y se convirtieron en una conversación continua.
El Resultado
Los resultados concretos del trimestre hablan solos. El tiempo promedio desde hipótesis a primer experimento bajó de 3–4 semanas a 3–5 días. Pasaron de testear 2–3 hipótesis por mes a 8–10, sin sumar devs ni crecer el equipo de producto.
En la métrica de negocio, la activación de la feature subió primero de 18% a 26% en las primeras seis semanas. En la semana 10, después de iterar sobre dos rondas más de experimentos guiados por resultados de datos y feedback cualitativo, llegaron a 31%. No fue magia, fue velocidad de aprendizaje compuesta.
Algo interesante: no todas las hipótesis funcionaron.
Aproximadamente la mitad de los experimentos tuvieron impacto neutro o incluso negativo.
Pero el costo de equivocarse era tan bajo y tan rápido que la organización empezó a tolerar mucho mejor el “fracaso” porque se traducía en insights accionables, no en meses perdidos.
Vibe Coding Essentials
Cómo cambia el GTM
Acá es donde engancho con algo que vienen diciendo OpenAI y Google sobre cómo la IA va a cambiar go-to-market.
En varias charlas señalan lo mismo: el poder de la IA no es solo crear contenido más rápido, sino convertir estrategias en experimentos ejecutables casi en tiempo real. Lo que vimos en este caso es justamente eso, pero aplicado al discovery de producto.
Mientras muchos siguen pensando la IA como una herramienta para escribir copies de marketing o responder tickets, este equipo la usó como un copiloto para diseñar, prototipar y configurar features testeables. No usaron IA para tener más ideas, la usaron para convertir ideas en realidad medible más rápido que la competencia. Ese es el verdadero cambio de juego para el go-to-market.
Pero nada de esto funciona si el mindset del PM no cambia. El gran error sería pensar: “Con Vibe Coding no necesito diseñadores ni devs”. Lo correcto es: “Con Vibe Coding reduzco la fricción para llegar a un punto donde el trabajo de diseño y desarrollo agrega valor real, no reproduce specs”.
Lo que más funcionó en este caso fue que el PM adoptó tres hábitos nuevos.
- Primero, diseñar la conversación con la IA como si fuera un colega senior, no como un autocomplete glorificado. Pedía contexto, objetivos, constraints y criterios de éxito claros.
- Segundo, aceptar que el primer output de la IA es un borrador, pero un borrador infinitamente más avanzado que un PRD en blanco.
- Tercero, incorporar la iteración como parte del mismo hilo de trabajo. En lugar de “cerrar” el archivo y abrir otro, volvía a la conversación con Vibe Coding con resultados, métricas y feedback y pedía ajustes. El discovery dejó de ser lineal y se volvió mucho más conversacional y adaptativo.
¿Qué no funcionó al principio?
Intentaron, por ejemplo, pedir a la IA flujos extremadamente complejos sin fijar límites ni costos de implementación. El resultado eran propuestas brillantes pero imposibles de ejecutar sin meses de trabajo. Aprendieron rápido que la calidad de las constraints es tan importante como la calidad de la idea.
También se dieron cuenta de que, si el PM no domina los fundamentos de producto, la IA puede amplificar malos supuestos. Si no sabes formular buenas hipótesis, la IA no te va a salvar. Solo vas a generar más variantes de algo mal planteado. Por eso, el valor real aparece cuando combinas criterio de producto fuerte con IA bien orquestada.
Unos cambios de chip
Si eres PM y quieres que Vibe Coding tenga impacto real en tu discovery, te dejo algunos cambios de chip concretos que vi en este caso.
- Deja de pensar en “especificar pantallas” y empezá a pensar en “diseñar sistemas de decisión y aprendizaje”. Y usa la IA para que lo repetitivo y lo mecánico no te frene.
- Pasa de “tengo que escribir un brief perfecto” a “tengo que lanzar una primera versión del experimento lo antes posible para aprender rápido”. La calidad de tu discovery ya no se mide por la prolijidad de tus documentos, sino por la velocidad y profundidad de tus ciclos de feedback. IA como Vibe Coding es el puente entre la idea y el experimento.
- Y, sobre todo, deja de ver al equipo de ingeniería como el único camino para validar algo en el mundo real. En este caso, el dev team dejó de ser un cuello de botella y se convirtió en alguien que interviene cuando ya hay claridad, foco y un diseño de experimento robusto. Eso es respeto por el tiempo de ingeniería y respeto por el tiempo del negocio.
Cierre
Cierro con esto: el cuello de botella de tu discovery no es la falta de ideas. Es cómo las conviertes en sistemas testeables, medibles y accionables antes de que el contexto del mercado cambie. La IA no viene a pensar por vos, viene a acelerar el ritmo al que tu pensamiento se transforma en realidad.