# 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.

Gratis, sin cuenta y sin correo. Úsala, modifícala, compártela.

[Descargar la plantilla (.zip)](https://nodary.ai/downloads/plantilla-prd.zip)

## 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.

- Documento de requisitos de producto: La página que todos leen primero: el problema, los objetivos, qué entra y qué no, y un enlace a cada parte.
- Usuarios y pruebas: Para quién es la funcionalidad, qué hacen hoy sin ella y la investigación detrás del problema.
- Requisitos: Qué debe hacer la funcionalidad, cada requisito con su prioridad y la comprobación que lo demuestra.
- Diseño y flujos: Cómo recorre el usuario la funcionalidad: el flujo, las pantallas, los estados y los casos límite.
- Lanzamiento y métricas: Cómo sabrás que funcionó, cómo se despliega y qué te haría dar marcha atrás.
- Decisiones y preguntas abiertas: Cada decisión que cambió el PRD, con quién la tomó y por qué, y las preguntas que siguen abiertas.

### 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](https://nodary.ai/es/templates/prd#doc-users).

_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](https://nodary.ai/es/templates/prd#doc-launch).

[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](https://nodary.ai/es/templates/prd#doc-users): para quién es la funcionalidad y la investigación detrás del problema
- [Requisitos](https://nodary.ai/es/templates/prd#doc-requirements): qué debe hacer, con prioridades y criterios de aceptación
- [Diseño y flujos](https://nodary.ai/es/templates/prd#doc-design): el flujo, las pantallas, los estados y los casos límite
- [Lanzamiento y métricas](https://nodary.ai/es/templates/prd#doc-launch): métricas, despliegue y lista de lanzamiento
- [Decisiones y preguntas abiertas](https://nodary.ai/es/templates/prd#doc-decisions): qué se decidió, quién y por qué, y qué sigue abierto

_Puedes usar, modificar y compartir esta plantilla libremente. Viene de_ [Nodary](https://nodary.ai/es)_, donde estos archivos se importan como un mapa de documentos enlazados._

### Usuarios y pruebas

**Responsable:** [nombre] · **Estado:** borrador · **Última revisión:** [fecha]

_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._

1. [Paso]
2. [Paso]
3. [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]

Ver también: [Documento de requisitos de producto](https://nodary.ai/es/templates/prd#doc-overview) · [Requisitos](https://nodary.ai/es/templates/prd#doc-requirements) · [Diseño y flujos](https://nodary.ai/es/templates/prd#doc-design)

### Requisitos

**Responsable:** [nombre] · **Estado:** borrador · **Última revisión:** [fecha]

_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]

Ver también: [Usuarios y pruebas](https://nodary.ai/es/templates/prd#doc-users) · [Diseño y flujos](https://nodary.ai/es/templates/prd#doc-design) · [Lanzamiento y métricas](https://nodary.ai/es/templates/prd#doc-launch)

### Diseño y flujos

**Responsable:** [nombre] · **Estado:** borrador · **Última revisión:** [fecha]

_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._

```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
```
_El flujo principal, de [dónde empieza el usuario] a [lo que obtiene]_

#### 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]

Ver también: [Requisitos](https://nodary.ai/es/templates/prd#doc-requirements) · [Lanzamiento y métricas](https://nodary.ai/es/templates/prd#doc-launch)

### Lanzamiento y métricas

**Responsable:** [nombre] · **Estado:** borrador · **Última revisión:** [fecha]

_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]

Ver también: [Documento de requisitos de producto](https://nodary.ai/es/templates/prd#doc-overview) · [Requisitos](https://nodary.ai/es/templates/prd#doc-requirements) · [Decisiones y preguntas abiertas](https://nodary.ai/es/templates/prd#doc-decisions)

### Decisiones y preguntas abiertas

**Responsable:** [nombre] · **Estado:** borrador · **Última revisión:** [fecha]

_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] | [...] |

Ver también: [Documento de requisitos de producto](https://nodary.ai/es/templates/prd#doc-overview) · [Requisitos](https://nodary.ai/es/templates/prd#doc-requirements) · [Lanzamiento y métricas](https://nodary.ai/es/templates/prd#doc-launch)

## 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.

1. Abre el mapa de un proyecto y elige «Importar».
2. Elige la pestaña «Carpeta o ZIP» y después «Elegir un ZIP».
3. 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.

## 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.

La página: https://nodary.ai/es/templates/prd