Hasta 2024, los PMs que querían validar una idea tenían dos opciones. Escribir un doc de requisitos y esperar a que ingeniería construyera un prototipo (semanas). O construir mockups estáticos en Figma que se ven bien pero no pueden probar comportamiento (días, pero con señal limitada). Las dos eran mejores que nada. Las dos eran lo bastante lentas para que la mayoría de ideas murieran en la fase de documento antes de llegar a un usuario real.
Ese gap se está cerrando rápido. Las herramientas de prototipado con IA ahora dejan a los PMs construir prototipos interactivos (respaldados por bases de datos reales, no solo pantallas clickables) en 15 a 30 minutos. Julie Price expuso qué cambia esto en su pieza de Aha!. Este artículo destila el workflow que sí funciona, las situaciones donde prototipar es el movimiento correcto y la trampa del "vibe coding" vs "PM coding".
Por qué esto cambia el loop de validación
Puedes explicar un feature en un requisito. O puedes prototipearlo y ponerlo en manos de alguien en 15 minutos.
El cambio no es solo velocidad. Es el tipo de feedback que puedes obtener. Los mockups estáticos generan opiniones ("me gusta el color"). Los prototipos interactivos generan comportamiento (el usuario intentó clickar algo que no existe, el usuario se confundió en el paso 3, el usuario terminó la tarea en 4 segundos). El comportamiento es señal. Las opiniones son ruido.
El prototipo también cambia la conversación de ingeniería. En lugar de un doc de requisitos de 10 páginas, el PM trae un prototipo funcionando. Ingeniería puede ver cómo debe ser la experiencia, no solo leerla. El gap de interpretación que antes costaba semanas de ida y vuelta se cierra inmediatamente.
Cuándo prototipar es el siguiente paso correcto
Prototipar no siempre es el movimiento correcto. Úsalo cuando:
- El equipo va y viene sobre una decisión de UX. Dos aproximaciones válidas, sin consenso. Un prototipo de 30 minutos de cada uno lo resuelve en feedback de usuario más rápido que otra reunión.
- El comportamiento del feature es difícil de especificar en palabras. Algunas experiencias (timing, animación, patrones de interacción) necesitan sentirse, no leerse.
- Necesitas probar demanda o fit antes de comprometer capacidad de ingeniería. Un prototipo funcionando mostrado a 10 clientes revela más que 10 entrevistas a clientes sobre el mismo feature.
- El stakeholder necesita verlo para aprobarlo. Los ejecutivos a menudo no pueden evaluar docs de requisitos. Un walkthrough de prototipo de 5 minutos produce decisiones que un doc de 30 páginas no.
Prototipar es el movimiento equivocado cuando:
- El feature es técnicamente simple y el UX está bien entendido (una spec estática es más rápida)
- El equipo necesita alineación sobre estrategia, no sobre implementación (prototipar es prematuro)
- El trabajo de infraestructura es el reto real (un prototipo esconde la complejidad real)
El workflow de prototipado PM en 5 pasos
Paso 1: Enmarca el prototipo alrededor de una decisión
Antes de abrir cualquier herramienta, anota la única decisión que quieres que el prototipo informe. "¿El onboarding debería ser un tour guiado o un checklist?" "¿El nuevo flujo de exportar reduce el patrón de tickets de soporte?" Una decisión por prototipo.
Los prototipos que intentan probar todo terminan probando nada. Cuanto más estrecha la pregunta, más afilada la señal.
Paso 2: Construye el prototipo
Herramientas como Aha! Builder, Bolt, V0, Cursor y similares dejan a un PM describir el feature en lenguaje natural y producir un prototipo funcionando en minutos. El output no es bonito por estándares de diseño. Sí se comporta como el producto, que es lo que importa para validación.
Dos distinciones importantes en este paso:
- Respaldado por datos, no solo pantallas. Un buen prototipo se conecta a una pequeña base de datos para que los usuarios puedan realmente crear, actualizar y borrar cosas. Los flujos de pantallas estáticas se sienten distintos de la interacción real.
- Comportamiento sobre pulido. El diseño visual se refinará después. Los patrones de interacción son lo que estás probando.
Paso 3: Prueba con la gente correcta
5-7 usuarios del segmento objetivo, no del equipo interno. El equipo interno tiene demasiado contexto. Los usuarios objetivo encuentran el prototipo como lo encontrarán los usuarios reales: en frío, sin preámbulo.
El guion para cada test: "Quiero que intentes [lograr la tarea]. Dime qué estás pensando mientras vas. No te ayudaré salvo que te quedes completamente atascado". Mira dónde dudan. Mira qué intentan. Mira qué asumen.
Paso 4: Refina basado en observación, no opinión
Después de cada test, escribe tres observaciones y cero opiniones. "El usuario intentó clickar el ícono de arriba antes del botón de abajo" es observación. "Al usuario no le gustó el diseño" es opinión. Refina el prototipo basado en observaciones.
Dos rondas de test y refinamiento (10-15 usuarios total) normalmente producen un prototipo listo o para moverse a build de ingeniería o para matarse porque la señal mostró que el feature no era correcto.
Paso 5: Entrega con confianza
El handoff a ingeniería con un prototipo funcionando es fundamentalmente distinto de uno con una spec. Ingeniería puede:
- Ver exactamente qué construir
- Hacer preguntas específicas sobre edge cases que el prototipo reveló
- Estimar más precisamente porque el diseño es concreto
- Identificar preocupaciones técnicas antes (esto no escalaría, esto necesita un cambio de API, esto choca con la arquitectura existente)
El PM sigue escribiendo el doc, pero ahora es un doc fino más el prototipo, no un doc grueso intentando compensar la ausencia de código funcionando.
La trampa del vibe coding vs PM coding
Una distinción importante emergiendo en 2026: "vibe coding" (construir algo que se ve cool pero no se comporta consistentemente) vs "PM coding" (construir algo que prueba una hipótesis específica limpiamente).
| Vibe coding | PM coding |
|---|---|
| Construido para impresionar visualmente | Construido para responder una pregunta |
| La demo corre una vez, se rompe en el segundo intento | Lo bastante robusto para 10 tests de usuario |
| Se muestra internamente | Se prueba con usuarios objetivo |
| Se convierte en la nueva spec | Informa la spec, después se descarta |
La trampa es hacer vibe coding mientras lo llamas prototipado. Las señales: el prototipo solo funciona en un camino, el equipo está admirando el prototipo en sí en lugar de los datos que produjo, el prototipo se manda a ingeniería tal cual en lugar de como input.
Qué cambia esto sobre las habilidades del PM en 2026
El PM que sabe prototipar ahora tiene acceso a un ciclo de validación que los PMs sin esa habilidad no pueden correr tan rápido. Esto se está volviendo una competencia base para roles de producto. No porque los PMs se estén volviendo ingenieros. Porque el coste de probar una idea ha caído a un punto donde no probar es más difícil de justificar.
Específicamente, los PMs que aprenden a prototipar:
- Envían mejores features porque el ciclo de validación es más rápido
- Tienen más credibilidad con ingeniería porque llegan con ejemplos funcionando
- Ganan más argumentos de roadmap porque traen evidencia
- Se mueven más rápido de idea a compromiso de roadmap a feature enviado
Para llevar
El prototipado con IA colapsa el ciclo de validación de semanas a horas y cambia el tipo de señal que los PMs pueden recolectar. El workflow correcto es: una decisión por prototipo, build respaldado por datos, probar con usuarios objetivo no equipo interno, refinar basado en observación no opinión, entregar con confianza. Evita la trampa del vibe coding manteniendo el foco en hipótesis probadas, no visuales impresionados. Los PMs que añaden esto a su toolkit no se vuelven ingenieros; se vuelven PMs cuyas ideas llegan a usuarios más rápido y más a menudo, que es de lo que el rol siempre ha tratado.
