Por qué casi nadie prototipaba antes (y por qué eso ya dejó de ser excusa)
Muchos Product Managers no prototipaban porque antes era lento y complejo. Hoy, con AI, construir ideas rápidamente dejó de ser una habilidad opcional y empezó a convertirse en ventaja competitiva.
(Parte 4 de 10: El cambio que está haciendo que más PMs empiecen a construir)
Hay algo curioso cuando hablas de prototipos con muchos Product Managers.
La mayoría responde algo como:
“Sí, estaría increíble prototipar más… pero no tengo tiempo”
“No sé diseño”
“Eso le toca al designer”
“Yo no soy técnico”
Y honestamente… durante mucho tiempo tenían razón.
Porque prototipar antes sí era complicado.
No era algo que abrías y resolvías en una tarde. Requería herramientas especializadas, bastante tiempo y, muchas veces, suficiente conocimiento técnico para convertir una idea en algo mínimamente interactivo.
Entonces los equipos se adaptaron.
Los PMs escribían.
Los diseñadores diseñaban.
Los developers construían.
Y el sistema funcionó así durante años.
El problema es que el entorno cambió… pero muchos siguen operando igual.
Hoy puedes construir un flujo funcional, una simulación o incluso una experiencia interactiva usando lenguaje natural y herramientas con AI. Cosas que antes requerían días o semanas, ahora pueden existir en minutos.
Y eso rompe algo importante:
👉 la barrera para construir.
Porque antes el problema era:
“No puedo prototipar aunque quiera”
Ahora muchas veces el problema es:
“No he cambiado mi forma de trabajar”
Y esas son conversaciones muy distintas.
Aquí es donde empieza a aparecer una oportunidad enorme para PMs.
No porque ahora deban convertirse en expertos de diseño o desarrollo, sino porque pueden empezar a pensar con más claridad usando construcción rápida como parte del proceso.
Y sí, eso cambia muchísimo cómo trabajas.
Piensa en esto.
Antes, validar una idea podía tomar:
juntas
documentos
alineaciones
handoffs
feedback tardío
Ahora puedes poner algo enfrente del equipo muchísimo antes.
Y cuando eso pasa, aparecen preguntas más útiles:
“esto se siente raro”
“este paso sobra”
“aquí el usuario se perdería”
Ese tipo de feedback casi nunca aparece leyendo un documento.
Y honestamente, creo que aquí muchos PMs todavía están subestimando lo que viene.
Porque siguen viendo prototipos como:
algo visual
algo “nice to have”
algo de diseño
Cuando en realidad empiezan a convertirse en una herramienta de claridad.
No para reemplazar pensamiento.
Sino para acelerarlo.
Y aquí quiero aclarar algo importante.
Construir rápido no significa construir bien automáticamente.
De hecho, aquí aparece otro problema nuevo:
👉 hacer cosas rápidas… pero vacías.
Flujos que se ven bien.
Pantallas bonitas.
Experiencias “impresionantes”.
Pero sin profundidad real.
(Aquí es donde empieza el famoso AI slop del que quiero hablar más adelante).
Porque AI puede ayudarte a construir más rápido.
Pero no puede pensar por ti.
Todavía.
Entonces el valor del PM empieza a moverse.
Ya no solo hacia:
coordinar
documentar
priorizar
Sino hacia algo más importante:
👉 saber qué vale la pena construir
👉 detectar problemas antes
👉 convertir ambigüedad en claridad
Y los prototipos ayudan muchísimo en eso.
No porque sean “bonitos”.
Sino porque vuelven visibles ideas que antes vivían solo en la cabeza o en documentos.
Creo que estamos entrando a una etapa donde los PMs que aprendan a construir rápido van a aprender más rápido también.
Y en producto…
aprender más rápido casi siempre termina siendo ventaja.
En el siguiente artículo quiero hablar de algo importante:
👉 por qué muchos PMs están usando AI mal… y cómo terminaron creando puro “AI slop”.
Porque sí, construir rápido ayuda.
Pero construir sin criterio… puede empeorar las cosas muchísimo.
Si llegaste hasta aquí y pensaste:
“ok… quizá ya no tengo tantas excusas para no prototipar”
Exacto.
Ese es el punto.
Este es el cuarto de una serie de 10 artículos donde desarmo este cambio:
👉 Cómo pasar de depender de contexto incompleto
👉 A construir claridad usando estructura + AI
Suscríbete ahora y no te pierdas los siguientes artículos :)