Durante dos décadas, el Product Requirements Document fue el artefacto que convertía la estrategia de producto en trabajo de ingeniería. Un documento de 10 a 30 páginas con secciones para statement del problema, objetivos, user stories, requisitos, edge cases y métricas de éxito. Era el contrato entre PM e ingeniería. Funcionaba porque el software era determinista, los requisitos eran conocibles por adelantado y el coste de cambiar de dirección a mitad de build era alto.
Los productos AI-native rompen casi toda suposición debajo del PRD. El comportamiento de una feature dirigida por LLM no es totalmente especificable. Los edge cases emergen de outputs probabilísticos. La experiencia en sí es el producto, no el sistema subyacente. Como argumentó Rags Vadali en un episodio reciente de Mind the Product, el PRD tiene que ser reemplazado por un artefacto distinto: el Product Experience Document (PXD).
Por qué el PRD clásico se rompe para productos AI
Tres desajustes estructurales:
1. Las especificaciones no pueden describir completamente comportamiento no determinista
Un PRD dice "cuando el usuario clicka X, el sistema hace Y". Un agente AI hace Y, o algo parecido a Y, o algo completamente distinto según el contexto. Especificar cada Y es imposible. Ingeniería no puede construir contra una spec que no puede existir.
2. La capa de experiencia es el producto
Para productos AI-native, el modelo subyacente es a menudo commodity. La diferenciación es la capa de experiencia: cómo se construyen los prompts, cómo se presentan los outputs, cómo el usuario colabora con el agente. Los PRDs documentaban el sistema. Los PXDs documentan la experiencia.
3. La velocidad de iteración supera la velocidad de documentación
Los productos AI iteran a un ritmo donde los docs exhaustivos están obsoletos antes de enviarse. Un documento que tarda dos semanas en escribirse cubre una versión de producto que se deprecó hace una semana. El artefacto tiene que ser más rápido que los cambios que describe.
El producto ahora es la capa de experiencia. Cuando construyes un agente, el producto real es lo que los usuarios experimentan encima del modelo fundacional.
Cómo se ve el Product Experience Document (PXD)
El PXD es más corto, más rápido y estructurado para la ambigüedad. Secciones comunes:
1. La hipótesis de experiencia
No requisitos. Una hipótesis sobre la experiencia que los usuarios deberían tener. "Los usuarios deberían poder redactar un email a cliente describiendo la situación en una frase y obtener un primer borrador completo que puedan editar." Lo bastante específico para probar, lo bastante abstracto para permitir iteración en el cómo.
2. El modelo de interacción
La forma de la colaboración usuario-AI. Dónde el usuario da input, dónde el AI responde, dónde el usuario corrige, dónde el AI aprende. Diagrama o prosa corta, no spec detallada.
3. Rangos aceptables, no specs exactas
En lugar de "el sistema deberá retornar X", el PXD dice "outputs aceptables incluyen A, B, C. Outputs inaceptables incluyen D, E, F. Modos de fallo a manejar elegantemente incluyen G, H". El cambio de exacto a aceptable es el salto mental más grande.
4. Los prompts y la estrategia de prompts
Para productos basados en agentes, los prompts reales son parte del producto. El PXD incluye ejemplos de prompts, la estrategia para seleccionarlos y los criterios para cuándo actualizarlos.
5. El framework de evaluación
¿Cómo sabrás si la experiencia es buena? No solo "el feature funciona". "En una muestra de 50 sesiones de usuario, el 80% completó la tarea sin rephrasear más de dos veces." La metodología de evaluación vive en el documento.
6. La sección desechable
Para productos AI, el 50-60% de lo que se construye se descartará. El PXD nombra qué está en etapa de hipótesis y qué está comprometido, para que ingeniería pueda priorizar en consecuencia.
El PXD se escribe para agentes, no solo para personas
El cambio estructural más interesante: los PXDs se usan cada vez más directamente como input para herramientas de coding con AI. Ingeniería toma secciones del PXD y las pega en Claude, Cursor o herramientas similares para generar o refactorizar código. Esto reconfigura cómo se escribe el documento:
- Las secciones necesitan sostenerse solas, no depender de contexto en otra parte del doc
- Los ejemplos son concretos y copy-pasteables
- Los criterios de aceptación son testeables por código, no solo por humanos
- El lenguaje es preciso donde los humanos tolerarían ambigüedad
El documento es ahora parte del proceso de build, no solo del proceso de planificación.
El patrón de Floto: productos paralelos y builds desechables
Varias empresas AI-native están convergiendo en un patrón: corren dos o tres productos en paralelo, tiran el 50-60% de lo que se construye. El PXD apoya esto al ser lo bastante ligero para que escribir uno para un experimento paralelo no sea un coste significativo. El PRD clásico era una inversión de varias semanas que anclaba a los equipos a lo que sea que especificaran. El PXD es un artefacto de un día que puede descartarse tan fácil como se escribió.
Qué sobrevive del PRD clásico
No todo en el formato viejo está mal. Las piezas que vale la pena mantener:
- El framing de usuario / problema. Incluso los productos AI sirven a usuarios específicos con problemas específicos.
- Las métricas de éxito. Aún necesarias, solo medidas distinto (basadas en outcome, con metodología de evaluación).
- El plan de lanzamiento. Aún necesario, incluyendo comunicación, estrategia de rollback y monitoreo.
- El log de decisiones. Qué consideraste y elegiste no hacer. Más importante en productos AI que nunca, porque el espacio de posibilidades es más grande.
El periodo híbrido (donde la mayoría de equipos están ahora)
La mayoría de organizaciones de producto no son completamente AI-native aún. Tienen algunas features deterministas que necesitan specs estilo PRD y algunas features dirigidas por AI que necesitan hipótesis estilo PXD. La respuesta realista es un formato híbrido que elige la estructura correcta por feature.
| Tipo de feature | Tipo de documento |
|---|---|
| CRUD determinista | PRD ligero con user stories y criterios de aceptación |
| Flujo con lógica de branching | PRD con diagramas de decisión |
| Experiencia dirigida por AI | PXD con rangos aceptables y evaluación |
| Agente que usa herramientas | PXD más especificaciones de herramientas |
| Cambios solo de UI | Brief visual más 1 página de rationale |
Para llevar
El PRD clásico fue un artefacto para una era donde el software era determinista y las especificaciones podían ser exhaustivas. Los productos AI-native requieren otra cosa: el Product Experience Document, que cambia especificaciones exactas por rangos aceptables, embebe prompts y metodología de evaluación, y se escribe para ser consumido tanto por humanos como por herramientas de coding con AI. La mayoría de equipos están en un periodo híbrido. La respuesta correcta es ajustar el documento al tipo de feature, no forzar cada feature en una sola plantilla que ya no encaja. El PRD está muriendo porque el software se está volviendo algo distinto. El PXD es lo que lo reemplaza.
