El PRD que se vuelve producto, no que se vuelve cajón
Un PRD suelto se vuelve interpretación. Un PRD con criterio de aceptación testeable se vuelve producto, porque un agente de IA puede ejecutarlo y tú puedes confirmar el resultado. La diferencia vive en el criterio, y el criterio sigue siendo tuyo.
Escribes un PRD de tres páginas describiendo la feature nueva, se la entregas al equipo y pasas a la siguiente cosa. Dos semanas después el dev entrega algo que técnicamente cumple lo escrito, y no resuelve el problema que tenías en mente. El PRD no estaba mal en la redacción. Estaba mal en el criterio: nunca decía, de una forma que se pueda testear, qué significa "listo".
El informe recurrente que rehaces desde cero cada semana no necesita rehacerse desde cero. Esta lección muestra la escalera que transforma esa tarea repetible en un sistema que casi se dispara solo.
Para una due diligence, la IA calculó el pasivo laboral consolidado de una empresa objetivo y escribió un párrafo seguro sobre el riesgo. Casi entró al dictamen así, sin revisión.
Le pides un brief de campaña a la IA y devuelve un documento lindo, lleno de objetivo vago como "aumentar el engagement". Nadie sabe, al final de la campaña, si funcionó o no, porque nada ahí era medible.
Escribes la descripción de un programa de onboarding con objetivos genéricos como "integrar bien al nuevo colaborador". Tres meses después nadie sabe medir si funcionó, porque "integrar bien" nunca se volvió un criterio que se pueda chequear.
Escribes un PRD de tres páginas describiendo la feature nueva, se lo entregas al equipo y pasas a la siguiente cosa. Dos semanas después el dev, o el agente de IA que conectaste al repositorio, entrega algo que técnicamente cumple lo escrito, y no resuelve el problema que tenías en mente. El PRD no estaba mal en la redacción. Estaba mal en el criterio: nunca decía, de una forma que se pueda testear de verdad, qué significa "listo". Un PRD lindo sin criterio de aceptación verificable no es spec, es redacción. Y la redacción no se vuelve producto.
Escribes el playbook de un nuevo enfoque de ventas con instrucciones vagas como "personalizar más el discurso". El equipo lo interpreta cada uno a su manera, y no se puede saber si el playbook funcionó, porque no había ningún criterio para medir.
Escribes el procedimiento nuevo del centro de distribución con una meta genérica de "reducir el tiempo de separación". Sin número y sin criterio de prueba, cada turno lo interpreta distinto, y nadie sabe si el procedimiento realmente resolvió el cuello de botella.
Escribes la política nueva de tratamiento de datos con lenguaje genérico sobre "buenas prácticas de seguridad". En la auditoría, nadie puede probar que la política se cumplió, porque nunca existió un criterio verificable.
Escribes el issue técnico diciendo "mejorar el desempeño de la búsqueda". El dev entrega una optimización real, solo que no es la que resolvía el problema que sentía el usuario, porque el issue nunca definió qué significaba "mejorar", con número.
Escribes el brief de rediseño con la meta de "hacer el flujo más intuitivo". Sin criterio de prueba, el equipo de diseño lo interpreta a su manera y solo descubres, en la prueba de usabilidad final, que no era eso lo que trababa al usuario.
Escribes la recomendación estratégica para el directorio con una frase de efecto y ningún criterio de éxito medible. Seis meses después nadie sabe decir si la apuesta funcionó, porque nunca quedó claro qué significaba "funcionó".
Déjame contarte algo sobre el PRD. Todo el mundo ya escribió un PRD que parecía completo: contexto, objetivo, alcance, una lista de "requisitos". Y aun así se volvió retrabajo, porque dos semanas después nadie estaba de acuerdo en si lo entregado estaba bien o no. Piensa conmigo: el problema casi nunca es la redacción. Es que el documento nunca dijo, de una forma que se pueda testear, qué quiere decir "listo".
La idea central de esta lección. Un PRD se vuelve producto cuando carga criterio de aceptación testeable: una frase que cualquier persona, o cualquier agente de IA, puede verificar como verdadera o falsa después de implementado. La IA bosqueja la estructura del PRD y sugiere criterios candidatos rápido. Lo que sigue siendo tuyo, y es lo que decide si el PRD funciona, es garantizar que el criterio capture la intención real, no solo una versión fácil de testear que no resuelve el problema de verdad.
01Por qué el PRD suelto se vuelve cajón o retrabajo
Un PRD sin criterio verificable tiene una característica traicionera: PARECE completo. Tiene contexto, tiene objetivo, tiene una lista de "qué hacer". Lo que falta es la regla que dice cuándo dejar de tocarlo y llamarlo listo. Sin esa regla, cada persona que lee el documento, un dev, un diseñador, un agente de IA, llena el vacío con su propia interpretación.
El resultado clásico: la feature "técnicamente" cumple el PRD y no resuelve el problema. Nadie mintió, nadie fue perezoso. El documento simplemente nunca definió qué significaba "correcto" de una forma que se pudiera chequear.
02La anatomía del PRD ejecutable: problema, criterio, fuera de alcance
Un PRD que se vuelve producto tiene tres partes que hacen el trabajo pesado:
- El problema, con la evidencia que lo sostiene. No "el usuario quiere más velocidad", sino "veintitrés tickets y tres cuentas enterprise citan lentitud en el checkout", sacado directo de la coreografía de feedback de la lección anterior.
- El criterio de aceptación, testeable. Una frase en el formato "dado esto, cuando esto pasa, entonces esto debe ser verdad". No "el checkout debe volverse más rápido", sino "el tiempo entre hacer clic en finalizar y ver la confirmación debe caer por debajo de dos segundos en el noventa por ciento de las compras".
- Lo que queda fuera de alcance, explícito. Lo que decidiste NO hacer ahora, escrito con la misma claridad que lo que sí vas a hacer. Eso corta la mayor fuente de retrabajo: gente agregando cosas que nadie pidió.
03La IA bosqueja rápido, el criterio correcto sigue siendo tuyo
Aquí la IA ayuda mucho, y vale la pena usarla sin culpa. Le entregas el insight de la coreografía de feedback (la evidencia del problema), y le pides el borrador del PRD entero: contexto, objetivo, una primera lista de criterios de aceptación candidatos. Lo arma en minutos, en el formato correcto, con buena redacción.
Lo que no hace sola es garantizar que el criterio capture la intención de verdad. Es fácil que la IA sugiera un criterio fácil de testear y fácil de programar que no sea el que resuelve el problema del usuario. Ejemplo clásico: el criterio "el botón de exportar debe aparecer en la pantalla" es testeable y no resuelve nada si el problema real era "el usuario no sabe que existe la exportación". Tú lees cada criterio candidato y preguntas: si esto es verdad, ¿el problema del paso uno está resuelto de verdad? Si la respuesta es no, el criterio está mal, aunque sea perfectamente testeable.
Sabe más: criterio testeable no es sinónimo de criterio correcto
Existe una trampa sutil aquí. "Testeable" es una cualidad de forma: se puede verificar si es verdadero o falso. "Correcto" es una cualidad de contenido: el criterio realmente captura lo que resuelve el problema del usuario. La IA es excelente garantizando la forma, porque forma es estructura, y estructura la redacta bien. Garantizar el contenido, que ese criterio específico es lo correcto para medir, exige que hayas leído el insight de origen y sepas, de verdad, qué estaba intentando hacer el usuario. Un PRD lleno de criterios testeables y equivocados es peor que un PRD vago, porque transmite una falsa sensación de rigor.
04Del criterio al agente: leer, hacer, mostrar para que confirmes
Un criterio de aceptación bien escrito es lo que permite que un agente de IA ejecute la implementación con seguridad, de la forma que viste en la lección 1.1: lee el PRD y el criterio, hace el cambio en tu código o en tu sistema, y te muestra para que confirmes si el criterio ahora es verdadero. Sin un criterio claro, el agente no tiene cómo saber cuándo parar, y tú no tienes cómo aprobar con confianza, solo con la sensación de "parece que quedó bien".
Un criterio bien escrito se vuelve, casi gratis, el guion de prueba que confirma la entrega. Es el mismo principio de cualquier coreografía de este curso: cuanto más claro el criterio en la entrada, más fácil y más segura queda la confirmación en la salida.
05Lo que nunca se automatiza: la intención detrás del criterio
La regla final de esta lección, y es corta. La IA puede escribir el PRD entero, sugerir todos los criterios, hasta simular si la implementación parece cumplir cada uno. Lo que no puede hacer sola es decidir si ese conjunto de criterios, tomado como un todo, resuelve el problema que el usuario tiene de verdad. Esa lectura de intención es tuya, viene de la evidencia que reuniste, y es el motivo por el que sigues siendo necesario cuando la redacción se abarató.
Hazlo ahora
Toma una feature o corrección real que necesitas especificar, tu tarea real u otra. Escribe el PRD en tres partes:
- Problema con evidencia. Una frase con el dato real detrás (número de tickets, cita de usuario, métrica que cayó).
- Criterio de aceptación testeable. Escríbelo en el formato "dado esto, cuando esto pasa, entonces esto debe ser verdad". Si no logras escribirlo en formato testeable, el criterio todavía está vago.
- Fuera de alcance. Lista dos o tres cosas que alguien podría suponer que están incluidas, y que estás dejando fuera en esta ronda, por escrito.
Ahora relee el criterio de aceptación y pregunta: si esto es verdad, ¿el problema del paso uno está realmente resuelto? Si la respuesta es no, reescribe el criterio antes de mandarlo al equipo o al agente.
Practica
1. ¿Por qué un PRD puede parecer completo y aun así volverse retrabajo?
2. La IA sugirió, para el problema 'el usuario no sabe que existe la exportación', el criterio 'el botón de exportar debe aparecer en la pantalla'. Ese criterio es testeable. ¿Es correcto?
Para la pizarra
Sobre lo que le falta al PRDel problema casi nunca es la redacción. Es no haber dicho nunca, de forma testeable, qué significa listo.
Sobre el huecosin criterio verificable, cada persona y cada agente lo llena con su propia interpretación.
Sobre el límitela IA redacta rápido. Verificar si el criterio captura la intención real sigue siendo humano.
Gracias por el feedback. Esto ayuda a afinar la próxima lección.