Te pasaste casi un día entero con el PRD. Planteamiento del problema, objetivos, no-objetivos, historias de usuario, casos límite, el diagramita. Lo compartiste. Dos personas ojearon el resumen. Ingeniería preguntó, en la daily, algo que el documento respondía en la línea cuarenta. Nadie leyó más allá del primer pantallazo, y la feature se construyó igualmente a partir de un hilo de Slack y una conversación de pasillo.
La reacción estándar es culpa y el propósito de escribir mejores. Más cortos. Más directos. Mejor plantilla. Eso es tratar un fallo estructural como si fuera personal. La gente no deja de leer tu PRD porque sea largo o porque enterraste la idea. No lo lee por lo que un PRD es: un documento que quedó terminado en el momento en que lo escribiste, en un sitio donde el trabajo real no vive.
Un PRD nace muerto por diseño
Un PRD es una foto fija. Describe cómo debería ser el producto en el instante en que dejaste de teclear. Esa es toda su naturaleza, y es la raíz del problema, porque un producto no es una foto fija. Es algo que cambia cada día según se toman decisiones, se escribe código y la realidad empuja de vuelta.
Así que el hueco se abre de inmediato. Al día siguiente de publicarlo, un caso límite resulta estar mal, aparece una restricción, una decisión se revisa en una reunión de la que el documento no sabe nada. El PRD no se actualiza, porque actualizar un documento es trabajo manual que compite con todo lo demás y siempre pierde. En una semana el PRD y el producto discrepan. En un mes todo el mundo sabe que el PRD está desactualizado, así que nadie se fía, así que nadie lo lee, así que nadie lo mantiene al día. El abandono es racional. Leer un documento que sabes desactualizado es peor que no leerlo, porque te dice cosas seguras, concretas y equivocadas.
El documento hace tres trabajos y ninguno bien
Parte de por qué el PRD está tan poco querido es que se le pide, calladamente, ser tres cosas distintas, y es malo en las tres a la vez.
- Un registro de decisiones. Qué decidimos y por qué. Pero las decisiones tomadas después de escribir el PRD nunca vuelven a entrar, así que captura las decisiones de un día y se pierde el resto en silencio.
- Un artefacto de comunicación. Alinear a todo el mundo. Pero alinear es una conversación, y un documento estático y largo es un mal sustituto de una. La gente se alinea en la discusión, y luego el documento fosiliza el estado en que la discusión quedó.
- Una spec de construcción. Qué construir de verdad. Pero es prosa, ambigua por naturaleza, y ahora también la lee un agente, que rellena cada hueco con una suposición segura.
Meter los tres en un solo artefacto garantiza mediocridad en cada uno. El registro de decisiones está desactualizado, la comunicación es de un solo sentido y la spec de construcción es ambigua, que es la razón por la que un prototipo funcionando es una spec más nítida que la prosa. Y como es un documento grande, arreglar cualquiera de los tres trabajos implica reescribirlo entero, cosa que nadie hace.
Qué cambia cuando también lo leen los agentes
Durante años la ambigüedad del PRD era sobrevivible porque lo leía un ingeniero humano que rellenaba los huecos con criterio y una pregunta de seguimiento. El documento podía ser descuidado porque el lector era listo y venía a preguntarte.
Un agente no viene a preguntarte. Lee el PRD, choca con la misma ambigüedad y la resuelve en silencio con la interpretación más probable, que muchas veces no es la tuya. Luego construye. Rápido. La vaguedad que un humano habría marcado se vuelve una feature publicada que técnicamente encaja con las palabras y se salta la intención. El PRD que nadie lee se ha vuelto un problema peor: un PRD que el agente lee demasiado literal y demasiado rápido, sin nadie en el bucle que cace el hueco antes de que sea código. Cuando construir se abarató y decidir se encareció, el artefacto flojo dejó de ser una molestia menor y pasó a ser lo que publica el producto equivocado.
Sustituye el documento por una decisión viva
El arreglo no es un documento mejor. Es dejar de tratar el requisito como documento y tratarlo como una decisión viva conectada al trabajo.
En concreto, eso significa unos cuantos cambios:
- Pequeño y direccionable, no grande y monolítico. Una decisión sobre un comportamiento, que puedes referenciar, revisar y superar por sí sola, en vez de un documento de cincuenta secciones donde cualquier cambio implica republicarlo todo.
- Conectado al código y a la evidencia, no al lado de ellos. El requisito apunta a la implementación que lo satisface y a la comprobación que lo prueba. Cuando cambia el código, ves el requisito que toca. Cuando cambia el requisito, ves qué tiene que moverse.
- Vivo, no fotografiado. Su estado actual refleja las decisiones actuales, porque actualizarlo es parte del flujo del trabajo y no una tarea de documentación aparte que compite por tiempo y pierde.
Cuando el requisito es una cosa viva y pequeña cableada al código y a la evidencia, leerlo deja de ser un favor. La gente lo consulta porque es donde vive la verdad actual, no la verdad de hace tres semanas. Así es como se ve una spec viva al lado de una estática, una vez aceptas que el documento era el problema. La razón por la que nadie leía el PRD nunca fue vagancia. Era que el PRD no merecía la lectura, porque no estaba conectado a nada y ya no era cierto.
Así se forma una feature factory
Hay una línea recta entre los PRDs sin leer y una feature factory. Cuando el requisito es un documento muerto, las decisiones reales viven en Slack, en la memoria, en la cabeza de quien estuviera en la sala. Nada conecta una feature publicada con la decisión que la motivó, así que nadie puede preguntarse si hizo aquello para lo que era. El equipo simplemente publica, porque publicar es la única señal legible que queda. El PRD sin leer no es un síntoma de la feature factory. Es uno de los mecanismos que la construye, porque corta el vínculo entre intención y output que si no te dejaría distinguir productividad de movimiento.
Dónde encaja PaellaDoc
Por eso en PaellaDoc un requisito no es un documento que escribes y abandonas. Es un artefacto vivo conectado al código que lo implementa, a las decisiones que lo moldearon y a la evidencia de que funciona. Cuando el código se mueve, el requisito que toca es visible. Cuando una decisión cambia, el requisito lo refleja. No hay un documento aparte que mantener sincronizado a mano, porque el requisito vive en el mismo grafo que el trabajo, que es el único arreglo en el que estar al día sale más barato que quedarse desactualizado.
Deja de intentar escribir PRDs que la gente lea. El PRD mejor escrito del mundo sigue quedando desactualizado al día siguiente de publicarlo, porque el problema nunca fue la redacción. Mata el documento muerto. Quédate con una decisión viva, cerca del trabajo, cierta ahora mismo. Esa sí la leen, porque por una vez merece su tiempo.
Preguntas frecuentes
¿Por qué nadie lee el PRD?
No es vagancia, ni que sea largo. Nadie lo lee porque un PRD queda terminado en el momento en que lo escribes y vive donde el trabajo no está. En una semana discrepa del producto; en un mes todo el mundo sabe que está desactualizado, así que deja de fiarse. Leer un documento que sabes obsoleto es peor que no leerlo.
¿Los product managers siguen escribiendo PRDs en la era de la IA?
El documento, cada vez menos. El trabajo que hacía, más que nunca. Lo que cambia es el artefacto: un PRD estático ahora es peligroso porque un agente lee su ambigüedad, la resuelve en silencio con la suposición equivocada y publica rápido. El requisito tiene que existir, pero como una decisión viva y pequeña cableada al código y a la evidencia, no como una foto fija que nadie mantiene.
¿Qué sustituye al PRD?
Una decisión viva conectada al trabajo, no un documento mejor. Hazla pequeña y direccionable, para revisar un comportamiento sin republicar cincuenta secciones. Cablearla al código que la satisface y a la comprobación que la prueba, para que un cambio en cualquier lado sea visible. Mantenla viva como parte del flujo del trabajo, para que su estado actual sea la verdad actual.
¿Por qué un PRD ambiguo es más peligroso con agentes de IA?
Un ingeniero humano leía un PRD vago, rellenaba el hueco con criterio y volvía con una pregunta. Un agente no. Resuelve la misma ambigüedad en silencio con la interpretación más probable, muchas veces no la tuya, y la construye rápido. La vaguedad que una persona habría marcado se vuelve una feature publicada que encaja con las palabras y se salta la intención, sin nadie en el bucle que la cace.