Por qué escribir PRDs ya no es suficiente
Escribir PRDs ya no es suficiente para Product Managers. Descubre por qué explicar ideas genera fricción y cómo usar prototipos y AI para alinear mejor y tomar decisiones más claras.
(Parte 2 de 10: De explicar ideas a empezar a mostrarlas)
Hay algo que durante mucho tiempo definió a un buen Product Manager: escribir bien. PRDs claros, contexto bien documentado, historias bien pensadas. Y durante años, eso funcionó. Si sabías escribir, pensabas bien. Si pensabas bien, el equipo construía mejor. Ese era el juego.
Pero hay un problema. Ese modelo asumía algo que hoy ya no es cierto: que la mejor forma de alinear es explicando.
Y aquí es donde empieza el quiebre.
Explicar suena bien en teoría… hasta que lo ves en la práctica. Lees un PRD y todo parece lógico. En la junta, todos asienten. El equipo empieza a trabajar. Y días después empiezan las dudas. “Oye, esto no lo había entendido así”, “creo que esto no estaba contemplado”, “¿qué pasa en este caso?”. No porque el PRD esté mal escrito, sino porque hay algo que el documento no puede resolver: la interpretación.
Cada persona completa los vacíos a su manera. Y eso introduce fricción.
¿Qué cambia?
Durante años, lo aceptamos como parte del proceso. Más claridad implicaba más documentación. Más documentación implicaba mejor alineación. Pero eso tiene un límite. Llega un punto donde escribes más, detallas más, explicas mejor… y aun así la ejecución no mejora en la misma proporción. Porque el problema ya no es cuánto explicas. Es que estás usando el medio equivocado.
Hoy tienes algo que antes no existía: la posibilidad de mostrar la idea. No en slides, no en texto, sino en algo que se puede ver, tocar e interactuar. Un flujo, un prototipo, una simulación. Y cuando eso aparece, cambia la conversación. La ambigüedad baja, las preguntas se vuelven más concretas y las decisiones se aceleran. Ya no es “¿entendiste lo que quise decir?”, ahora es “¿ves esto? ¿funciona o no?”.
Entonces no, los PRDs no desaparecen. Siguen siendo útiles. Pero dejan de ser el centro. Pasan a ser soporte, contexto, documentación. La claridad real empieza antes, cuando construyes algo, aunque sea imperfecto.
Entonces, ¿qué más se requiere hacer?
Aquí es donde muchos se equivocan. Intentan usar AI para hacer lo mismo de siempre, pero más rápido: PRDs más completos, mejor redacción, más output. Pero siguen jugando el mismo juego. Y eso genera una ilusión peligrosa: “esto se ve bien… entonces debe estar bien”. No necesariamente. Escribir mejor no elimina la ambigüedad, solo la disfraza mejor.
El cambio real no es escribir mejor. Es cambiar el orden.
Antes: entender → escribir → ejecutar.
Ahora: construir → alinear → ejecutar.
Y en ese “construir” pasan cosas importantes. Descubres edge cases antes, detectas huecos en la lógica y tomas decisiones con algo tangible. No necesitas alta fidelidad, necesitas algo que haga visible la idea.
Pasa a la acción con la IA
Piensa en esto. En lugar de escribir “el usuario podrá completar el flujo de registro en 3 pasos…”, construyes un flujo básico. En minutos alguien te dice: “esto no tiene sentido en el paso 2”. Ese insight no sale del documento. Sale de ver algo.
El problema no es que estés escribiendo PRDs. Es que estás dependiendo de ellos más de lo que deberías. El rol no se trata de explicar mejor, se trata de hacer las ideas más claras. Y hoy, la forma más rápida de hacer eso no es escribiendo. Es mostrando.
En el siguiente artículo vamos a ir un paso más allá: prototipos como habilidad. No como algo “nice to have”, sino como algo que empieza a definir a los PMs que realmente avanzan.
Si alguna vez pensaste “pero esto ya lo habíamos definido…”, probablemente lo habían escrito. No necesariamente lo habían entendido.
¿Cómo lo hago?
Te recomiendo herramientas como Claude Code, Codex (ChatGPT) y/o Cursor. En este post no entraré en un tutorial de como hacerlo, pero ya existe contenido en internet para que puedas seguir paso a paso como volver tu PRD un prototipo y de eso hablaremos en el siguiente post.
Un PM promedio intenta entender todo antes de actuar.
Un PM que evoluciona empieza a construir para entender.
(Cambia sutilmente… pero lo cambia todo).
Si quieres saber en detalle cómo hago para ejecutar el Piensas → construyes → entiendes mejor → decides.. mantente pendiente de mis próximos artículos.
Saludos!
Este es el segundo 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 :)