Plantilla de documento de requisitos de producto (PRD)
Seis documentos enlazados que llevan una funcionalidad del problema al lanzamiento: para quién es, qué debe hacer, cómo es su flujo, cómo sabrás que funcionó y cada decisión por el camino. Descárgalos como archivos Markdown: se abren en cualquier editor, muestran su diagrama en GitHub y en Obsidian, y se importan en Nodary como un mapa.
6 archivos Markdown en un .zip, 7 kB
Gratis, sin cuenta y sin correo. Úsala, modifícala, compártela.
Lee cada página antes de descargarla
La visión general cabe en una pantalla y enlaza cinco partes: desarrollo, diseño y soporte encuentran cada uno su página, y un cambio sigue siendo pequeño. Las líneas en cursiva dicen qué escribir; los ejemplos siguen una misma funcionalidad de ejemplo, enlaces para compartir que caducan.
Documentos
Archivo Plantilla de PRD/Documento de requisitos de producto.md
Documento de requisitos de producto
Cómo usar esta plantilla: las líneas en cursiva son indicaciones. Sustitúyelas por tus palabras y luego bórralas. Los valores entre corchetes los rellenas tú. Mantén esta página en una pantalla: es lo que lee primero quien tiene prisa, quien acaba de llegar o un agente de IA.
De un vistazo
| Campo | Esta funcionalidad |
|---|---|
| Funcionalidad | [Nombre] |
| En una frase | [Lo que el usuario puede hacer cuando salga] |
| Responsable de producto | [nombre] |
| Responsable técnico | [nombre] |
| Responsable de diseño | [nombre] |
| Estado | [borrador, en revisión, aprobado, publicado] |
| Versión prevista | [fecha o versión] |
Problema
Quién tiene el problema, qué le cuesta hoy y cómo lo sabes. Un problema sin pruebas es una suposición: enlaza la investigación en Usuarios y pruebas.
Ejemplo (una funcionalidad de muestra): Hay quien comparte un documento con un cliente para que lo revise y luego olvida que el enlace existe. Meses después sigue abriéndose. Tres clientes preguntaron el último trimestre cómo hacer que un enlace deje de funcionar en una fecha concreta.
[El problema, en dos o tres frases]
Objetivos y no objetivos
Los objetivos dicen qué cambia para el usuario, no qué construye el equipo. Los no objetivos son las decisiones que impiden que el alcance crezca en silencio.
- Objetivo: [lo que el usuario puede hacer, o ya no tiene que hacer]
- Objetivo: [...]
- No objetivo: [lo que esta versión deja fuera a propósito]
- No objetivo: [...]
El éxito en una línea
La medida que te dirá, un mes después del lanzamiento, si funcionó. La lista completa está en Lanzamiento y métricas.
[Métrica] pasa de [valor inicial] a [objetivo] antes del [fecha].
El resto del PRD
Cada parte es un documento propio. Enlázala en vez de copiarla, para que cada dato viva en un solo sitio y cambie en un solo sitio.
- Usuarios y pruebas: para quién es la funcionalidad y la investigación detrás del problema
- Requisitos: qué debe hacer, con prioridades y criterios de aceptación
- Diseño y flujos: el flujo, las pantallas, los estados y los casos límite
- Lanzamiento y métricas: métricas, despliegue y lista de lanzamiento
- Decisiones y preguntas abiertas: qué se decidió, quién y por qué, y qué sigue abierto
Puedes usar, modificar y compartir esta plantilla libremente. Viene de Nodary, donde estos archivos se importan como un mapa de documentos enlazados.
Archivo Plantilla de PRD/Documento de requisitos de producto/01 Usuarios y pruebas.md
Usuarios y pruebas
Para quién es la funcionalidad y qué sabes de esas personas. Cada afirmación aquí debe remitir a su fuente.
Para quién
| Quién | Qué intenta hacer | Qué se lo impide |
|---|---|---|
| [Usuario principal] | [...] | [...] |
| [Usuario secundario] | [...] | [...] |
Ejemplo (una funcionalidad de muestra): Una gestora de cuentas comparte un borrador de propuesta con un cliente durante una semana de comentarios. Hoy se pone un recordatorio para desactivar el enlace, y a veces se le olvida.
Hoy, sin la funcionalidad
Lo que hacen hoy los usuarios, paso a paso, atajos incluidos. El atajo suele ser la mejor especificación que vas a tener.
- [Paso]
- [Paso]
- [Atajo]
Pruebas
| Fuente | Qué dice | Fecha | Enlace |
|---|---|---|---|
| [Entrevista con cliente] | [...] | [fecha] | [...] |
| [Tickets de soporte] | [...] | [...] | [...] |
| [Datos de uso] | [...] | [...] | [...] |
Preguntas abiertas
- [Pregunta], [quién la responde], [para cuándo]
Archivo Plantilla de PRD/Documento de requisitos de producto/02 Requisitos.md
Requisitos
Una fila por requisito, escrita como algo que el usuario puede hacer. La prioridad es imprescindible, deseable u opcional: una versión sale cuando se cumple cada imprescindible.
Historias de usuario
| ID | Como | Quiero | Para | Prioridad |
|---|---|---|---|---|
| R1 | [usuario] | [...] | [...] | [imprescindible, deseable, opcional] |
| R2 | [...] | [...] | [...] | [...] |
| R3 | [...] | [...] | [...] | [...] |
Ejemplo (una funcionalidad de muestra): R1. Como persona que comparte un documento, quiero elegir el día en que un enlace deja de funcionar, para que un cliente pierda el acceso cuando termine el proyecto. Imprescindible.
Criterios de aceptación
Para cada imprescindible, las comprobaciones que demuestran que funciona. Escríbelas para que un tester, o un agente de IA, las ejecute sin preguntarte.
| Requisito | Dado | Cuando | Entonces |
|---|---|---|---|
| R1 | [una situación de partida] | [una acción] | [el resultado que alguien puede comprobar] |
| R1 | [...] | [...] | [...] |
Requisitos no funcionales
| Área | Requisito |
|---|---|
| Rendimiento | [...] |
| Seguridad y privacidad | [...] |
| Accesibilidad | [...] |
| Idiomas | [...] |
| Compatibilidad | [navegadores, dispositivos, versiones] |
Fuera del alcance
- [Lo que esta versión no hace, y por qué]
- [...]
Preguntas abiertas
- [Pregunta], [quién la responde], [para cuándo]
Archivo Plantilla de PRD/Documento de requisitos de producto/03 Diseño y flujos.md
Diseño y flujos
Enlaza los archivos de diseño en vez de pegarlos. Guarda aquí el flujo y las decisiones que lo explican, para que el texto y las pantallas nunca se contradigan.
Flujo de usuario
El camino principal, desde donde empieza el usuario hasta lo que obtiene. Si el equipo no sabe dibujarlo, aún no está decidido.
- Punto de entradaPrimera acción
- Primera acciónElección clave
- Elección claveConfirmación
- ConfirmaciónResultado
Mermaid
flowchart LR n0["Punto de entrada"] n1["Primera acción"] n2["Elección clave"] n3["Confirmación"] n4["Resultado"] n0 --> n1 n1 --> n2 n2 --> n3 n3 --> n4
Pantallas
| Pantalla | Propósito | Enlace al diseño | Estado |
|---|---|---|---|
| [Pantalla] | [...] | [...] | [boceto, maqueta, final] |
| [Pantalla] | [...] | [...] | [...] |
Estados
Cada pantalla tiene más estados que el caso feliz. Marca cada uno cuando esté diseñado, o escribe por qué no puede ocurrir.
- Vacío: aún no hay nada que mostrar
- Cargando
- Error, con lo que el usuario puede hacer después
- Sin permiso
- Conexión lenta o perdida
- Texto muy largo y números muy grandes
Casos límite
| Caso | Qué pasa |
|---|---|
| [...] | [...] |
| [...] | [...] |
Ejemplo (una funcionalidad de muestra): Alguien abre un enlace un minuto después de su fecha de fin: ve que el enlace caducó y a quién pedirlo, nunca una página de error.
Preguntas abiertas
- [Pregunta], [quién la responde], [para cuándo]
Archivo Plantilla de PRD/Documento de requisitos de producto/04 Lanzamiento y métricas.md
Lanzamiento y métricas
Una métrica principal, dos o tres secundarias y una salvaguarda: algo que no debe empeorar mientras la principal mejora.
Métricas
| Métrica | Tipo | Valor inicial | Objetivo | Medida con | Fecha de revisión |
|---|---|---|---|---|---|
| [...] | [principal] | [...] | [...] | [...] | [fecha] |
| [...] | [secundaria] | [...] | [...] | [...] | [...] |
| [...] | [salvaguarda] | [...] | [...] | [...] | [...] |
Despliegue
| Etapa | Quién la recibe | Fecha | Se avanza cuando |
|---|---|---|---|
| [Interna] | [el equipo] | [...] | [...] |
| [Beta] | [...] | [...] | [...] |
| [Todo el mundo] | [...] | [...] | [...] |
Lista de lanzamiento
- Artículo de ayuda escrito
- Equipo de soporte informado
- Nota de versión redactada
- Eventos de analítica comprobados
- Marcha atrás probada
Marcha atrás
Qué te haría desactivar la funcionalidad, y cómo. Decídelo antes del lanzamiento, mientras nadie está apegado al resultado.
- Damos marcha atrás si: [...]
- Cómo: [un flag, una versión, un script]
- Quién decide: [nombre]
Archivo Plantilla de PRD/Documento de requisitos de producto/05 Decisiones y preguntas abiertas.md
Decisiones y preguntas abiertas
Cuando una decisión cambie el PRD, añade una línea aquí y actualiza la página afectada. El registro dice por qué; la página dice qué es cierto ahora.
Registro de decisiones
| Fecha | Decisión | Decidido por | Por qué | Página modificada |
|---|---|---|---|---|
| [fecha] | [...] | [...] | [...] | [...] |
Ejemplo (una funcionalidad de muestra): Los enlaces funcionan hasta el final de su último día en la zona horaria de su propietario, no hasta la medianoche UTC. Lo decidieron la responsable de producto y el responsable técnico, porque en la beta clientes de otras zonas horarias perdían el acceso un día antes. Página modificada: Requisitos.
Preguntas abiertas
| Pregunta | Quién la responde | Para cuándo | Respuesta |
|---|---|---|---|
| [...] | [nombre] | [fecha] | [...] |
Cómo usarla
Escribe el problema antes que la solución
Rellena primero el problema, los objetivos y los no objetivos de la visión general, con la ingeniera y el diseñador que construirán la funcionalidad. Si los tres no estáis de acuerdo en el problema, parad ahí.
Haz comprobable cada imprescindible
Da a cada requisito imprescindible criterios de aceptación que otra persona pueda comprobar. Un requisito que nadie puede probar es un deseo.
Haz que lo revisen y mantenlo al día
Pide una revisión cuando los requisitos estén listos y actualiza el PRD cuando una decisión los cambie. Un PRD que se queda en el arranque está equivocado en el lanzamiento.
Anota qué cambió y por qué
Cada decisión va al registro de decisiones con quién la tomó. Cuando alguien pregunte por qué la funcionalidad funciona así, la respuesta estará a un enlace.
Impórtala en Nodary como un mapa
Nodary es un espacio de trabajo nativo de IA donde los documentos de un equipo se enlazan en vez de amontonarse. Importa el .zip y el PRD llega con sus cinco partes debajo, los enlaces entre páginas conservados y el diagrama dibujado. Ponlo en revisión y pide a un propietario o administrador del espacio o del proyecto que lo apruebe, mira qué cambió desde tu última visita y deja que los agentes de IA conectados por MCP lean los requisitos antes de escribir código.
- Abre el mapa de un proyecto y elige «Importar».
- Elige la pestaña «Carpeta o ZIP» y después «Elegir un ZIP».
- Selecciona el archivo descargado, revisa el árbol e importa.
El plan Free admite diez documentos por espacio de trabajo, contando la página del propio proyecto: los seis de la plantilla caben en un espacio nuevo, con sitio para tres más. Nodary también trae integrada una plantilla de especificación de producto (PRD) de una página.
Nodary para equipos de producto e ingeniería
Escribir un PRD que el equipo use de verdad
Un PRD falla de dos maneras: describe una solución que nadie cuestionó, o deja de actualizarse después del arranque. Estos hábitos evitan las dos.
Empieza por el problema
Escribe quién tiene el problema y cuánto le cuesta antes de cualquier solución. Los equipos que están de acuerdo en el problema discuten menos sobre las pantallas.
Di lo que no harás
Los no objetivos también son decisiones. Escribirlos es lo que evita que una funcionalidad crezca semana a semana.
Haz los requisitos comprobables
“Rápido” y “fácil” no se pueden comprobar. “El enlace deja de abrirse en el minuto siguiente a su fecha de fin” se puede construir y probar.
Prioriza con imprescindible, deseable y opcional
Una versión sale cuando se cumple cada imprescindible. Lo deseable y lo opcional es lo que intercambias cuando se acerca la fecha.
Enlaza las pruebas
Cada afirmación sobre los usuarios enlaza la entrevista, el ticket o los datos que la respaldan, para que quien revise la compruebe en vez de creérsela.
Mantenlo vivo
Actualiza el PRD cuando una decisión lo cambie y anota por qué. Al final debe describir lo que salió, no lo que se planeó la primera semana.
Preguntas sobre el PRD
¿Qué es un PRD?
Un documento de requisitos de producto (product requirements document, PRD) describe una funcionalidad o un producto antes de construirlo: el problema que resuelve, para quién es, qué debe hacer, cómo se mide el éxito y qué queda fuera del alcance. Suele ser responsabilidad de un product manager; ingeniería, diseño, soporte y, cada vez más, los agentes de IA de programación lo leen.
¿Qué debe incluir un PRD?
Como mínimo el problema y sus pruebas, objetivos y no objetivos, los usuarios, requisitos priorizados con criterios de aceptación, los flujos principales y los casos límite, métricas de éxito, el plan de despliegue y un registro de decisiones y preguntas abiertas. Esta plantilla tiene un documento para cada grupo.
¿Qué extensión debe tener un PRD?
La suficiente para que el equipo construya y pruebe la funcionalidad sin hacerte dos veces la misma pregunta. La visión general debe caber en una pantalla; los requisitos crecen con las decisiones, no con las ideas.
¿Qué diferencia hay entre un PRD y un documento de diseño técnico?
El PRD dice qué debe hacer la funcionalidad y por qué. El documento de diseño técnico dice cómo lo hará el sistema: arquitectura, datos, interfaces y riesgos. Escribe primero el PRD y luego enlaza los dos.
¿Pueden los agentes de IA usar el PRD?
Sí. Un PRD en documentos enlazados da a un agente el contexto que necesita. En Nodary, los agentes conectados por MCP, como Claude, ChatGPT o Cursor, leen los requisitos y el registro de decisiones con tus permisos antes de escribir.
¿Puedo usar la plantilla fuera de Nodary?
Sí. Los archivos son Markdown: Obsidian abre la carpeta descomprimida como una bóveda con todos sus enlaces, y GitHub muestra los archivos con su diagrama. Las herramientas que importan Markdown archivo por archivo conservan el texto y las tablas; comprueba cómo tratan los enlaces entre archivos.
Mantén los requisitos donde trabaja el equipo.
Importa la plantilla en Nodary y el PRD se convierte en un mapa que tu equipo y tus agentes de IA mantienen al día. Gratis con dos miembros, un proyecto y diez documentos, sin tarjeta.