Plantilla de Documento de Requisitos de Producto (+ un Ejemplo Práctico Completo Para Copiar)

Plantilla de Documento de Requisitos de Producto (+ un Ejemplo Práctico Completo Para Copiar)

Última actualización: 28 de julio de 2026.

La mayoría de las páginas sobre plantillas de documento de requisitos de producto te entregan un formulario vacío. La de Atlassian son cuatro secciones de instrucciones alrededor de una tabla de métricas de éxito en blanco. La de Product School lleva "(con ejemplo)" en el título y no contiene ningún ejemplo. El bloque de markdown de 12 secciones de abajo es la plantilla completa, de acceso libre, lista para copiar y pegar. La Sección 4 completa cada una de esas 12 secciones con un ejemplo práctico completo: un portal de facturas para un cliente que lee PDFs con un LLM y envía las dudosas a revisión humana. Copia la vacía. Lee la rellenada. Escribe la tuya.

Puntos Clave

• Un PRD responde qué construir y por qué; el documento de diseño técnico responde cómo.
• Las 12 secciones se adaptan a cualquier tamaño de proyecto. Un documento de una página es la misma plantilla con menos filas.
• Los no-objetivos deben quedar por escrito. Un agente de codificación con IA no puede inferir el alcance a partir de lo que se omite.
• Los criterios de aceptación deben ser verificables por máquina: "p95 bajo 400ms", nunca "rápido".

¿Qué Forma de PRD Deberías Usar?

Elige la forma según quién va a leer el documento, no según lo grande que parezca el producto. Una sola función destinada a tus propios ingenieros necesita un documento de una página. Una construcción entregada a un equipo externo necesita el PRD completo de 12 secciones, porque los criterios de aceptación funcionan también como puertas de aprobación. Una especificación destinada a un agente de codificación con IA necesita esas mismas doce secciones divididas en fases.

La plantilla de documento de requisitos de producto de una página que todos piden no es un artefacto distinto. El documento de una página de Lenny Rachitsky, ampliamente copiado y publicado con ejemplos reales en su newsletter, es el mismo esqueleto sin el trámite superfluo. Un documento de una página no es un documento diferente. Son las mismas doce secciones con las filas vacías eliminadas.

Los equipos ágiles también se hacen esta pregunta a menudo, normalmente planteada como si un PRD aguanta una vez que existe un backlog. Aguanta, como documento de una página: el PRD contiene el porqué y los límites, los tickets contienen el trabajo.

La Plantilla de PRD (Markdown Para Copiar y Pegar)

Aquí está todo en markdown, gratis, sin necesidad de correo. Pégalo en Notion, Confluence, Google Docs, Linear, Word, o súbelo a GitHub como PRD.md y déjalo versionarse junto al código. La gente pide esta plantilla en nueve formatos distintos; markdown es el único que sobrevive al pegado en todos ellos, y es el único que un agente de codificación con IA lee sin problemas.

# PRD: [Nombre del producto o función]

## 1. Encabezado
- Responsable (producto):
- Responsable de ingeniería:
- Responsable de diseño:
- Estado: Borrador | En revisión | Aprobado | Publicado
- Última actualización:
- Historial de cambios: fecha / autor / qué cambió

## 2. Declaración del problema
Un párrafo. A quién afecta, con qué frecuencia, cuánto cuesta hoy. Sin lenguaje de solución.

## 3. Objetivos y métricas de éxito
| Objetivo | Métrica | Línea base | Meta | Medido por | Fecha |
|---|---|---|---|---|---|

## 4. No-objetivos
Formulado en positivo: "Esta fase no incluye X."

## 5. Usuarios y perfiles
Quién lo usa, qué sabe ya, qué dispositivo, con qué frecuencia.

## 6. Historias de usuario y criterios de aceptación
Como [perfil], quiero [acción], para [resultado].
- Dado [contexto], cuando [evento], entonces [resultado observable].

## 7. Requisitos funcionales
Numerados. Un requisito por línea. Verificable. Ninguna frase que contenga "y".

## 8. Requisitos no funcionales
Rendimiento / seguridad y multiinquilino / residencia y retención de datos / accesibilidad / disponibilidad.

## 9. Dependencias e integraciones
Sistemas externos, APIs, credenciales, quién controla el acceso, plazo de entrega.

## 10. Hitos y fases
| Fase | Alcance | Criterios de salida | Fecha objetivo |
|---|---|---|---|

## 11. Preguntas abiertas y riesgos
| Pregunta o riesgo | Responsable | Necesario para | Impacto si no se resuelve |
|---|---|---|---|

## 12. Apéndice y enlaces
Diseños, investigación, notas sobre competidores, tickets previos, contratos.

Las doce secciones, en orden: encabezado, declaración del problema, objetivos y métricas de éxito, no-objetivos, usuarios y perfiles, historias de usuario con criterios de aceptación, requisitos funcionales, requisitos no funcionales, dependencias e integraciones, hitos y fases, preguntas abiertas y riesgos, apéndice.

¿Qué Debe Incluir un PRD? Las 12 Secciones, y la Versión Débil de Cada Una

Un documento de requisitos de producto debe incluir una declaración del problema, objetivos medibles, no-objetivos explícitos, perfiles de usuario, historias de usuario con criterios de aceptación, requisitos funcionales y no funcionales, dependencias, hitos, preguntas abiertas con responsables y un historial de cambios. Todo lo demás es apéndice. La prueba para cada línea es la misma que ISO/IEC/IEEE 29148:2018 aplica a los requisitos en general: verificable, inequívoca, singular.

La mayoría de los PRD fallan esa prueba en los mismos tres puntos.

Dos secciones merecen más atención de la que suelen recibir.

Los requisitos no funcionales son donde el alcance se duplica en silencio. Rendimiento, multiinquilino, residencia de datos, retención, accesibilidad, disponibilidad: cada uno de ellos es una decisión de ingeniería con un coste, y ninguno aparece en una historia de usuario. Pon la línea de seguridad aquí en lugar de dejarla como una vaguedad, y escríbela como querrías que se verificara, usando algo como nuestra checklist de seguridad antes del lanzamiento como lista de referencia. Si la construcción tiene un componente de IA, los requisitos de preparación para producción también van aquí, no en una fase posterior de "endurecimiento" que nunca llega a programarse: nuestra checklist de PoC a producción es la versión que usamos.

Las preguntas abiertas necesitan tres columnas, no una. Pregunta, responsable, fecha límite. Una pregunta sin responsable es una decisión que nadie está tomando, y aparecerá como solicitud de cambio en la semana seis. Vale la pena decirlo: un PRD es lo que escribes después de decidir construir en lugar de comprar. Si la declaración del problema todavía parece una lista de la compra de funciones, la decisión de comprar frente a construir en realidad todavía no se ha tomado.

El Ejemplo Práctico: Un PRD de Portal de Facturas, Completado

Aquí tienes un ejemplo práctico completo, con las 12 secciones rellenadas. La construcción: un portal de facturas para un cliente, un operador logístico de tamaño medio. Los clientes suben facturas en PDF, un LLM extrae las partidas, el sistema marca las discrepancias contra el registro del pedido, y cualquier cosa de la que no esté seguro va a una cola de revisión humana. Stack: Next.js, Supabase/Postgres, un paso de extracción con LLM. Cópialo, imprímelo, expórtalo a PDF, lo que necesites.

# PRD: Portal de Facturas del Cliente, Fase 1

## 1. Encabezado
- Responsable (producto): Director de operaciones, lado del cliente
- Responsable de ingeniería: Delivery lead, Techsy
- Responsable de diseño: Diseñador de producto, Techsy
- Estado: Aprobado para construcción
- Última actualización: 2026-07-28
- Historial de cambios:
  - 2026-07-14 / producto / primer borrador
  - 2026-07-21 / ingeniería / se añadió la regla de umbral de confianza a 6.2
  - 2026-07-28 / producto / se trasladó la escritura de vuelta al ERP a no-objetivos

## 2. Declaración del problema
El personal de operaciones recibe las facturas de los clientes como PDFs por correo
electrónico y las vuelve a introducir a mano en el sistema de pedidos. El volumen
supera las 300 facturas por semana, el tiempo medio de gestión es de unos 6 minutos
por factura, y aproximadamente el 4% arrastra un error de captura detectado solo
en la conciliación de fin de mes. Cada corrección cuesta una segunda pasada y una llamada.

## 3. Objetivos y métricas de éxito
| Objetivo | Métrica | Línea base | Meta | Medido por | Fecha |
|---|---|---|---|---|---|
| Reducir la gestión manual | Tiempo medio de gestión | 6 min | menos de 90 seg | Panel de operaciones, mediana semanal | 2026-11-01 |
| Reducir errores de captura | Facturas corregidas en la conciliación | 4% | menos de 1% | Informe de fin de mes de finanzas | 2026-12-01 |
| Contener la carga de revisión | Porcentaje enviado a revisión humana | n/a | menos de 25% | Métricas de la cola del portal | 2026-11-01 |

## 4. No-objetivos
Esta fase no admite facturas multidivisa, escritura de vuelta al ERP, notas de
crédito de autoservicio para el cliente, ni una app móvil. La extracción solo
cubre PDF. Las fotografías de facturas en papel y los escaneos por debajo de
200 DPI se rechazan al subirlos, con un mensaje que explica por qué.

## 5. Usuarios y perfiles
- Administrativo de operaciones (principal, 6 personas): trabaja la cola de
  excepciones todo el día, conocimiento profundo del dominio, solo escritorio.
- Contacto de cuentas a pagar del cliente (externo, ~140 cuentas): sube
  facturas, poca tolerancia a la fricción en la configuración de la cuenta.
- Responsable de finanzas (secundario): extrae el informe de fin de mes,
  necesita un registro de auditoría por factura.

## 6. Historias de usuario y criterios de aceptación
6.1 Como contacto de cuentas a pagar del cliente, quiero subir una factura en
PDF, para no tener que enviarla por correo y esperar.
- Given un PDF de menos de 20 MB a 200 DPI o más, when lo subo, then el
  portal devuelve un número de referencia en menos de 5 segundos y muestra "Procesando".

6.2 Como administrativo de operaciones, quiero que las extracciones de baja
confianza se retengan, para que nada incorrecto se apruebe automáticamente.
- Given una factura procesada, when la confianza de extracción de cualquier
  partida está por debajo de 0.85, then la factura se envía a la cola de
  revisión y nunca se aprueba automáticamente.

6.3 Como administrativo de operaciones, quiero ver la discrepancia en un solo
lugar, para poder resolverla sin abrir el sistema de pedidos.
- Given una factura vinculada a un pedido, when la cantidad o el precio
  unitario de alguna línea difiere del registro del pedido, then el portal
  muestra ambos valores uno junto al otro y marca la diferencia.

6.4 Como responsable de finanzas, quiero filtrar facturas, para poder
cerrar el mes.
- Given la lista de facturas, when filtro por proveedor, rango de fechas y
  estado, then los resultados se devuelven en menos de 400ms en p95 y el
  estado vacío ofrece "Borrar filtros".

## 7. Requisitos funcionales
1. La subida solo acepta PDF, 20 MB como máximo, un archivo por envío.
2. La extracción devuelve proveedor, número de factura, fecha, divisa y
   partidas con cantidad, precio unitario y total.
3. Cada partida lleva una puntuación de confianza entre 0 y 1.
4. La coincidencia compara la factura extraída con el pedido abierto por
   número de PO.
5. Las excepciones entran en una cola ordenada de más antigua a más
   reciente, asignable a un administrativo.
6. Cada cambio de estado escribe una entrada de auditoría con actor, marca
   de tiempo, valor anterior.
7. Las facturas aprobadas se exportan como lote CSV para el sistema de
   finanzas.

## 8. Requisitos no funcionales
- Rendimiento: lista de facturas p95 bajo 400ms. La extracción se completa
  en menos de 90 segundos desde la subida en p95.
- Seguridad y multiinquilino: aislamiento por inquilino aplicado a nivel de
  fila en la base de datos. Un cliente nunca puede leer la factura de otro
  cliente. Verificado con una prueba automatizada en cada versión.
- Residencia y retención de datos: documentos almacenados en la UE. Los
  originales se conservan 7 años, los datos de extracción 90 días.
- Accesibilidad: cola totalmente operable con teclado, contraste WCAG 2.2 AA.
- Disponibilidad: 99.5% mensual, soporte en horario laboral.

## 9. Dependencias e integraciones
- Registros de pedidos: réplica de Postgres de solo lectura. El acceso lo
  gestiona TI del cliente, credenciales necesarias antes del 2026-08-15.
- Proveedor de extracción con LLM: contrato y acuerdo de tratamiento de
  datos firmados antes de empezar la construcción.
- Notificaciones por correo: proveedor transaccional existente, dominio de
  envío verificado por el cliente.

## 10. Hitos y fases
| Fase | Alcance | Criterios de salida | Fecha objetivo |
|---|---|---|---|
| P1 | Subida, extracción, enrutado por confianza | 50 facturas reales de extremo a extremo, menos de 25% en cola | 2026-09-19 |
| P2 | Coincidencia de pedidos y vista de discrepancias | Discrepancia marcada correctamente en 20 casos de prueba | 2026-10-10 |
| P3 | Registro de auditoría, exportación CSV, informes | Finanzas cierra un mes en el portal | 2026-11-01 |

## 11. Preguntas abiertas y riesgos
| Pregunta o riesgo | Responsable | Necesario para | Impacto si no se resuelve |
|---|---|---|---|
| ¿Qué número de PO es el válido cuando una factura muestra dos? | Director de operaciones del cliente | 2026-08-08 | Lógica de coincidencia bloqueada |
| ¿Los 12 clientes más grandes envían PDFs escaneados o nativos? | Delivery lead | 2026-08-08 | El umbral de confianza podría estar mal |
| ¿Está confirmada la retención de 7 años con el asesor legal del cliente? | Responsable de finanzas del cliente | 2026-08-22 | Cambia el diseño y el coste del almacenamiento |
| Coste de extracción por factura a 300/semana | Delivery lead | 2026-09-05 | Economía unitaria desconocida |

## 12. Apéndice y enlaces
Conjunto de facturas de muestra anonimizadas (40 archivos), esquema de la tabla
de pedidos, estudio actual del tiempo de gestión, flujos de Figma para subida y
cola, SOW firmado.

Hay cuatro decisiones ahí dentro que merece la pena destacar, porque la versión perezosa de cada una cuesta dinero de verdad.

Sección 3, la línea base. "6 minutos" no es decoración. Sin una línea base no puedes saber si funcionó, y seis meses después alguien discute sobre ello en una reunión sin datos. La versión perezosa, "mejorar la eficiencia", hace que el proyecto sea imposible de refutar.

Sección 4, el no-objetivo. La escritura de vuelta al ERP se trasladó a no-objetivos el 2026-07-28, después de haberse dado por hecha durante una llamada de revisión. Escribirlo como no-objetivo costó una línea y evitó una discusión de alcance.

Sección 6.2, el umbral de confianza. Esta es la regla que más se nos olvida en nuestros primeros borradores. Si se omite, el sistema aprueba automáticamente facturas que un humano debería haber visto, que es exactamente el fallo que borra el ahorro de tiempo prometido en la sección 3.

Sección 11, los responsables. Cada pregunta abierta tiene un nombre y una fecha. Esa columna es la diferencia entre un documento y una lista de tareas que nadie asume.

El PRD te dice el qué. No te dice cuánto tiempo ni cuánto cuesta, que es un ejercicio aparte: consulta cómo definir el alcance de la construcción para esa mitad. Y un no-objetivo que no escribiste es una función que alguien construirá.

¿Cómo Escribes un PRD del Que un Agente de Codificación con IA Pueda Construir de Verdad?

Un PRD escrito para un agente de codificación con IA cambia la brevedad por la explicitud. El agente no tiene contexto informal, ni historia compartida, ni instinto para saber qué obviamente no querías decir. Cuatro reglas cubren la mayor parte de la diferencia, y vienen de observar qué especificaciones funcionan y cuáles fallan en nuestras propias construcciones asistidas por agentes.

1. Formula los no-objetivos en positivo. Los humanos infieren el alcance a partir de lo que se omite. Los agentes no. "No añadas autenticación en esta fase" tiene que ser una frase en el documento, o la autenticación se construirá, se probará y te la entregarán.

2. Divide el trabajo por fases. Un monolito de 40 páginas produce un pull request seguro de sí mismo, expansivo y a medias correcto. Divide el PRD en pasadas que un agente pueda terminar en una sola ejecución acotada, cada una con sus propios criterios de salida.

3. Haz que los criterios de aceptación sean verificables por máquina. "Rápido" no es un requisito, es un estado de ánimo. "p95 bajo 400ms en el endpoint de la lista de facturas" es una prueba que el agente puede escribir antes de escribir la función.

4. Pon las rutas de archivos y las restricciones de stack en el documento, no en el chat. El contexto del chat se evapora entre sesiones. La especificación no. Por eso también importa el modo plan de Claude Code: lee tus archivos y propone un plan sin editar nada hasta que lo apruebas, y ese paso de aprobación es mucho más útil cuando el plan se contrasta con una especificación escrita en lugar de con tu memoria de lo que pediste.

Aquí está el portal de facturas, dividido en una fase que un agente puede ejecutar en una sola pasada.

# Tarea de construcción: Subida y extracción de facturas (Fase 1 de 3)

## Restricciones de stack (no sustituir)
Next.js 15 App Router, TypeScript, Supabase Postgres con row-level security,
despliegue en Vercel. Ninguna dependencia nueva sin preguntar antes.

## Archivos que puedes crear o editar
- app/(portal)/invoices/upload/page.tsx
- app/api/invoices/route.ts
- lib/extraction/parse-invoice.ts
- supabase/migrations/0007_invoices.sql

## No tocar
- lib/auth/*  (la autenticación llega en la Fase 2; no añadas flujos de inicio de sesión ahora)
- Cualquier cosa bajo app/(marketing)/
- El esquema de pedidos existente. Léelo. Nunca lo migres.

## Criterios de aceptación (escríbelos primero como pruebas)
1. POST /api/invoices rechaza lo que no sea PDF con 415 y los archivos de más de 20 MB con 413.
2. Una partida con confianza < 0.85 establece invoice.status = 'review',
   nunca 'approved'.
3. Cada inserción escribe una fila de auditoría con actor_id, action, created_at.
4. GET /api/invoices?vendor=&from=&to=&status= responde en menos de 400ms
   sobre un 10,000-row seed.

## Fuera de alcance para esta pasada
Coincidencia de pedidos, UI de discrepancias, exportación CSV, notificaciones por correo.

Tres cosas cambiaron respecto a la versión humana: aparecieron las rutas de archivos, apareció una lista de "no tocar", y los criterios de aceptación se convirtieron en aserciones en lugar de frases. A qué agente se lo entregues importa menos de lo que la gente piensa, aunque vale la pena leer la comparativa de agentes de codificación antes de decidirte. Mantén los requisitos y las reglas del proyecto en archivos separados: Cursor rules y CLAUDE.md contienen las convenciones y las herramientas, el PRD contiene qué construir. Si quieres ayuda de la IA para producir el alcance desde el principio en lugar de solo consumirlo, ese es un flujo de trabajo distinto. Y para el propio paso de extracción, la elección del modelo y el bucle de evaluación son su propio trabajo de integración de IA.

Qué Cambia Cuando el PRD Va a un Equipo Externo

Cuando el PRD va a una agencia o contratista, deja de ser un documento de alineación y pasa a ser lenguaje contractual. La ambigüedad que un equipo interno resuelve con una conversación de dos minutos se convierte en una solicitud de cambio con precio. El informe Pulse of the Profession del PMI descubrió que el 47% de los proyectos fallidos no alcanzan sus objetivos por una gestión inexacta de los requisitos. Esa es la razón de ser de este documento.

Tres secciones pesan de forma desproporcionada en ese contexto. Los criterios de aceptación se convierten en puertas de aprobación, así que tienen que ser observables por alguien que no sea ingeniero. Las preguntas abiertas necesitan un responsable con nombre por parte del cliente, porque el proveedor no puede responderlas y construirá alrededor del vacío. Y el historial de cambios deja de ser burocrático: es el registro de qué se acordó y cuándo, que es lo primero a lo que recurre todo el mundo cuando hay un desacuerdo.

La línea que hemos visto fallar más de una vez es alguna versión de "los usuarios pueden exportar sus datos". Nadie escribe en qué formato. La versión cara de eso, para nosotros, se envió como una exportación CSV cuando el cliente había querido un paquete de facturas en PDF formateado con su marca, y rehacerlo consumió cerca de una semana de ingeniería que nadie había presupuestado. La lectura honesta es que el fallo estaba en el documento, no en la entrega. Un criterio de aceptación lo habría detectado en cinco minutos: dada una solicitud de exportación, cuando se genera el archivo, entonces es un PDF que coincide con el diseño proporcionado. Una línea de no-objetivos también lo habría detectado, desde el otro lado. Así que ahora es una regla en nuestro descubrimiento: cualquier requisito que dependa de un sustantivo como "exportar", "informe" o "notificación" lleva adjunto un formato, un disparador y un ejemplo práctico antes de firmar un SOW.

Eso es, en gran parte, cómo llevamos las construcciones de aplicaciones web: convertir la mitad vaga de la especificación de un cliente en líneas verificables antes de que nadie escriba código.

Lo Que Realmente Dice r/ProductManagement Sobre las Plantillas de PRD

Busca product requirements document template reddit y encontrarás la misma queja repetida en r/ProductManagement: exceso de plantilla. PRDs que nadie lee. Secciones rellenadas porque la plantilla tenía un encabezado, no porque alguien necesitara el contenido. Documentos que quedan obsoletos al día siguiente del kickoff y son silenciosamente sustituidos por un hilo de Slack. Es una crítica justa hacia la mayoría de las plantillas, incluidas varias entre los diez primeros resultados de esta búsqueda.

Nuestra respuesta: elimina secciones en lugar de rellenarlas con nada. Los perfiles de usuario van primero cuando los usuarios son obvios. El apéndice va segundo. Los hitos pueden vivir en el tracker en su lugar. La que nunca eliminamos es no-objetivos, porque es la única sección que se acorta cuanto más trabajo haces, y la única que previene de forma fiable la discusión que de otro modo tendrías en la semana seis.

Preguntas Frecuentes

¿Qué es un documento de requisitos de producto?

Un documento de requisitos de producto (PRD) establece qué está construyendo un equipo y por qué: el problema, los objetivos y sus métricas, los no-objetivos, para quién es y los requisitos que definen cuándo está terminado. Excluye deliberadamente el detalle de implementación, que pertenece a un documento de diseño técnico escrito después por ingeniería.

¿Cómo se escribe un documento de requisitos de producto?

Empieza por la declaración del problema y evita usar lenguaje de solución en ella. Añade objetivos medibles con una línea base y una fecha objetivo, y luego escribe los no-objetivos. Rellena los perfiles, las historias de usuario con criterios de aceptación Given/When/Then, los requisitos funcionales y no funcionales, las dependencias, los hitos y las preguntas abiertas con responsables.

¿Qué debe incluir un PRD?

Doce secciones: encabezado con historial de cambios, declaración del problema, objetivos y métricas de éxito, no-objetivos, usuarios y perfiles, historias de usuario con criterios de aceptación, requisitos funcionales, requisitos no funcionales, dependencias e integraciones, hitos y fases, preguntas abiertas y riesgos, y un apéndice. Cualquier cosa que no encaje en una de esas categorías probablemente no es un requisito.

¿Cuánto debe medir un PRD?

De una a dos páginas para una sola función, de tres a cinco para una fase de producto, de cinco a ocho cuando lo construye un equipo externo y los criterios de aceptación actúan como puertas de aprobación. La longitud sigue el número de decisiones que se registran, no el tamaño del producto. Las secciones vacías deben eliminarse, no rellenarse de relleno.

¿Es un PRD lo mismo que un BRD?

No. Un documento de requisitos de negocio (BRD) establece el resultado comercial que quiere la organización y las restricciones alrededor de él, normalmente antes de elegir una solución. Un PRD describe el producto que lo entrega: usuarios, comportamiento, criterios de aceptación, no-objetivos. En empresas más pequeñas, el BRD suele ser solo la sección de declaración del problema.

¿Los equipos ágiles siguen escribiendo PRDs?

Sí, normalmente como documento de una página. El backlog contiene el trabajo, pero los tickets son pésimos a la hora de contener el porqué, los no-objetivos y la métrica de éxito. Los equipos que se saltan el PRD por completo suelen redescubrirlo como una página de Confluence llamada "contexto" tres sprints después de empezar el proyecto.

¿Se puede escribir un PRD en markdown?

Markdown es el mejor formato para uno. Se pega limpiamente en Notion, Confluence, Google Docs y Linear, se versiona en Git junto al código como PRD.md, genera diffs correctos en un pull request, y es el único formato que un agente de codificación con IA lee sin perder la estructura. La plantilla de arriba está en markdown exactamente por esas razones.

¿Cómo se escribe un PRD para un agente de codificación con IA?

Sé explícito donde normalmente serías breve. Formula los no-objetivos en positivo, porque un agente no puede inferir el alcance a partir de lo que se omite. Divide el documento en fases que se puedan terminar en una sola pasada. Escribe los criterios de aceptación como aserciones con números. Nombra los archivos que el agente puede editar y los que no puede tocar.

¿Cuál es la diferencia entre un PRD y un documento de diseño técnico?

El PRD responde el qué y el por qué: problema, usuarios, comportamiento, criterios de aceptación, no-objetivos. El documento de diseño técnico responde el cómo: arquitectura, modelo de datos, contratos de API, compensaciones consideradas. Producto suele ser dueño del primero, ingeniería del segundo, y el documento de diseño debería poder leerse como una respuesta al PRD.

¿Quién es dueño del PRD: producto, ingeniería o el cliente?

Producto es dueño del documento y de las decisiones que contiene. Ingeniería es dueña de la retroalimentación de viabilidad y de los requisitos no funcionales. En construcciones con agencia, el cliente es dueño de la declaración del problema, los objetivos y todas las preguntas abiertas sobre su propio negocio. La propiedad compartida de todo el documento suele significar que nadie lo mantiene.

Para Cerrar

Tres cosas para llevarte. La plantilla solo es útil una vez rellenada, así que copia la forma del ejemplo práctico en lugar de la vacía. Los no-objetivos son la sección de más valor por palabra en el documento y la primera que la gente se salta. Y los criterios de aceptación escritos como aserciones verificables sirven igual de bien a dos lectores: un ingeniero que aprueba una entrega, y un agente que escribe la prueba.

Si estás escribiendo un PRD para entregar a un equipo externo y quieres una segunda opinión antes de que se convierta en contrato, con gusto lo leemos y marcamos las líneas ambiguas. Es la misma revisión que hacemos en nuestras propias construcciones de aplicaciones web.