Plantilla de PRD con IA: las secciones, un prompt para cada una y un ejemplo resuelto

Qué tiene que conseguir la plantilla

Un documento de requisitos de producto tiene dos lectores. Quien construye, que puede ser un compañero, un contratista o un agente de programación, necesita saber qué hacer y cuándo parar. Quien revisa necesita comprobar que lo que se entregó es lo que se acordó. La plantilla sirve a ambos cuando cada requisito es una sola afirmación verificable y cada no-objetivo está escrito.

Las secciones están elegidas para que cada una responda a un tipo distinto de pregunta:

Mantén el documento por debajo de dos páginas. Un PRD que nadie lee es un PRD que no existe.

La plantilla de PRD en Markdown

Copia este bloque en una página, en un archivo del repositorio o en un editor. Sustituye todo lo que está entre corchetes y borra cada línea de guía cuando la sección esté escrita.

PRD: [Nombre de la función o del producto]

Responsable: [Nombre]
Estado: [Borrador / En revisión / Acordado]
Última actualización: [AAAA-MM-DD]
Resumen: [Una frase: qué es, para quién y qué sustituye]

**1. Problema**
Hoy, [quién] [hace qué apaño] cuando necesita [conseguir algo].
Le cuesta [tiempo, dinero o riesgo que has observado].
Evidencia: [entrevistas, tickets de soporte, llamadas de ventas, tu propio uso; di cuántos]

**2. Objetivos**
G1. [Métrica] pasa de [valor actual] a [meta] antes de [fecha].
G2. [Métrica] pasa de [valor actual] a [meta] antes de [fecha].
Cómo lo mediremos: [el panel, la consulta o el informe]

**3. Historias de usuario**
US-1. Como [rol], cuando [situación], quiero [acción], para [resultado].
US-2. Como [rol], cuando [situación], quiero [acción], para [resultado].
US-3. Como [rol], cuando [situación], quiero [acción], para [resultado].

**4. Criterios de aceptación**
Para cada historia, una o más comprobaciones que un revisor pueda aprobar o rechazar.
AC-1a. Dado [estado], cuando [acción], entonces [resultado observable].
AC-1b. Dado [estado], cuando [acción], entonces [resultado observable].
AC-2a. Dado [estado], cuando [acción], entonces [resultado observable].
Prioridad: [Must / Should / Could] para cada historia.

**5. No-objetivos**
No haremos [cosa] en esta versión porque [razón].
No haremos [cosa] en esta versión porque [razón].

**6. Riesgos y preguntas abiertas**
R1. [Riesgo]. Probabilidad [baja/media/alta]. Si ocurre: [respuesta].
R2. [Riesgo]. Probabilidad [baja/media/alta]. Si ocurre: [respuesta].
Abierta: [una pregunta que debe responderse antes de empezar a construir, y quién la responde]

Dos convenciones soportan casi todo el peso. Cada historia y cada criterio tienen una clave estable (US-1, AC-1a), de modo que un mensaje de commit, una incidencia o una auditoría pueden señalarlos. Y cada criterio está escrito como dado-cuando-entonces, así que es una prueba antes de ser código.

Un prompt para cada sección

Un único prompt de "escríbeme un PRD" produce un documento seguro de sí mismo con evidencia inventada y objetivos genéricos. Pedir una sección cada vez, con los datos que realmente tienes, deja al modelo menos margen para inventar. Estos son los prompts que usamos; las partes entre corchetes son lo que rellenas antes de enviar.

1. Problema. "Estas son mis notas de [N] conversaciones con clientes y [N] tickets de soporte: [pegar]. Escribe la sección Problema en menos de 120 palabras, con la forma 'Hoy, [quién] hace [apaño] cuando necesita [tarea]. Le cuesta [coste]'. Usa solo costes que aparezcan en las notas. Termina con una línea de Evidencia que cuente las fuentes."
2. Objetivos. "El problema es: [pegar]. Nuestros números actuales son: [métrica, valor]. Propón tres objetivos como 'G#. [métrica] pasa de [actual] a [meta] antes de [fecha]'. No inventes valores actuales; si necesitas uno que no te he dado, escribe TBD."
3. Historias de usuario. "Problema y objetivos: [pegar]. Escribe como máximo cinco historias de usuario con la forma 'Como [rol], cuando [situación], quiero [acción], para [resultado]'. Un rol por historia. Ordénalas según lo directamente que sirvan a G1."
4. Criterios de aceptación. "Para cada historia de abajo, escribe dos o tres criterios de aceptación como 'Dado [estado], cuando [acción], entonces [resultado observable]'. Cada uno debe poder comprobarlo alguien que no vea el código. Marca cualquier historia para la que no puedas escribir un criterio comprobable." Este es el paso donde una historia floja se delata: si el modelo no puede escribirle una prueba, tú tampoco.
5. No-objetivos. "Dadas estas historias, enumera seis cosas que un ingeniero razonable podría dar por incluidas pero no lo están. Para cada una, escribe 'No haremos [cosa] en esta versión porque [razón]'." Después recorta la lista a las que de verdad tentarían a tu equipo.
6. Riesgos. "Enumera las cuatro formas más probables en que esta función falle tras el lanzamiento, técnicas o comerciales. Para cada una: probabilidad y la respuesta que daríamos. Marca todo lo que estés adivinando."

Pide una sección, léela, corrígela y pega la versión corregida en el siguiente prompt. La cadena de secciones corregidas es la verdadera salvaguarda; el modelo solo ve lo que ya has aprobado.

Ejemplo resuelto: un enlace de reserva para una consultora de dos personas

Aquí está la plantilla rellenada para una función pequeña y con forma realista. Las cifras son ilustrativas.

PRD: Enlace público de reserva

Responsable: Dana
Estado: Acordado
Última actualización: 2026-10-28
Resumen: Una página pública donde un cliente potencial elige un hueco de
30 minutos en nuestro calendario compartido, sustituyendo el ir y venir
de correos que hacemos hoy.

**1. Problema**
Hoy, un cliente potencial que quiere una llamada nos escribe, e
intercambiamos de media cuatro mensajes para acordar una hora. En las 22
llamadas del último trimestre eso fueron unas tres horas de tiempo de los
fundadores, y dos clientes potenciales dejaron de responder antes de
fijar una hora.
Evidencia: búsqueda en el correo enviado de los últimos 90 días; 22 hilos
contados.

**2. Objetivos**
G1. Mensajes intercambiados por llamada reservada pasa de 4 a 1 antes del
15 de diciembre.
G2. Llamadas reservadas al mes pasa de 7 a 10 antes del 31 de enero.
Cómo lo mediremos: recuento de hilos etiquetados "agenda" en la bandeja
compartida; tabla de reservas en el espacio de trabajo.

**3. Historias de usuario**
US-1. Como cliente potencial, cuando abro el enlace, quiero ver los huecos
en mi zona horaria, para no reservar a las 3 de la madrugada por error.
US-2. Como fundador, cuando se reserva un hueco, quiero tenerlo en mi
calendario con los datos del cliente, para no preparar la llamada de
memoria.
US-3. Como fundador, cuando estoy de vacaciones, quiero que no se ofrezca
ningún hueco, para que nadie reserve en una semana en la que no estoy.

**4. Criterios de aceptación**
AC-1a. Dado un visitante en UTC+9, cuando carga la página, entonces las
horas se muestran en UTC+9 y el nombre de la zona es visible.
AC-1b. Dado un hueco ya reservado, cuando carga la página, entonces ese
hueco no se ofrece.
AC-2a. Dada una reserva completada, cuando abro el calendario, entonces
existe un evento con el nombre, el correo y las notas del cliente en
menos de 60 segundos.
AC-3a. Dada una solicitud de vacaciones aprobada que cubre un día, cuando
carga la página, entonces no se ofrece ningún hueco ese día.
Prioridad: US-1 Must, US-2 Must, US-3 Should.

**5. No-objetivos**
No haremos pago al reservar porque la primera llamada es gratuita.
No haremos eventos de grupo porque nunca nos han pedido uno.
No haremos marca personalizada porque nosotros dos somos la marca.

**6. Riesgos y preguntas abiertas**
R1. Reserva duplicada si la sincronización del calendario se retrasa.
Probabilidad media. Si ocurre: correo de confirmación con enlace para
reprogramar, revisado a diario.
R2. Reservas de spam. Probabilidad baja. Si ocurre: exigir confirmación
por correo antes de bloquear el hueco.
Abierta: ¿ofrecemos también huecos de 15 minutos? Dana decide el viernes.

Fíjate en lo que el ejemplo no contiene: ni "experiencia encantadora", ni arquitectura, ni capturas de pantalla. AC-3a es una prueba que un revisor puede ejecutar en dos minutos. Los no-objetivos son las tres cosas por las que un contratista preguntaría con más probabilidad.

Dónde guardarlo y qué hacer con él después

Un PRD en una ventana de chat se pierde en cuanto se cierra la pestaña. Necesita un sitio con historial de versiones, para ver qué cambió entre "Borrador" y "Acordado", y una forma de convertir sus historias en trabajo.

En Atrix, la plantilla de PRD es una página alojada con las mismas secciones que el Markdown de arriba, más una tabla de requisitos donde cada fila tiene una clave, una afirmación comprobable, su aceptación y una prioridad MoSCoW. La ejecución Develop del agente va en el sentido contrario: dale un brief corto y el paso "Redactar los requisitos" escribe el problema, el usuario objetivo, el alcance, los requisitos numerados y los no-objetivos en una página; los pasos siguientes proponen una arquitectura y las incidencias planificadas que puedes aceptar en el backlog. Conviene conocer los límites: una ejecución consume una de las ejecuciones mensuales del plan (100 en Builder, 500 en Studio), no hay plan gratuito, y el agente redacta a partir de tu brief, así que un brief flojo da un PRD flojo. La página del agente de IA enumera lo que produce cada ejecución.

Si quieres que el PRD lo lea un agente de programación en lugar de una persona, el artículo hermano sobre escribir un PRD que Claude Code o Cursor puedan construir cubre las restricciones adicionales.

Errores habituales que la plantilla está diseñada para evitar

• Objetivos sin valor actual. "Aumentar las conversiones" es un deseo. "Pasar del 2,1 % al 3 % antes de marzo" es un objetivo. Si no conoces el valor actual, escribe TBD y averígualo antes de empezar a construir.
• Historias que son funciones disfrazadas. "Como usuario, quiero un panel" no tiene situación ni resultado. Pregunta qué intentan conseguir.
• Criterios que necesitan el código para comprobarse. "La API devuelve 200" es un detalle de implementación. "Dada una reserva completada, cuando abro el calendario, entonces el evento existe" es lo que ve el usuario.
• No-objetivos vacíos. Si la sección está en blanco, el alcance no se ha decidido; lo decidirá quien lo construya.
• Una sección de riesgos que solo enumera riesgos técnicos. "Nadie lo usa" es el fallo más común y debe estar en la lista.

Preguntas frecuentes

¿Qué es una plantilla de PRD con IA?

Una plantilla de documento de requisitos de producto escrita para que un asistente de IA pueda redactar cada sección a partir de datos que tú aportas, y para que un revisor pueda comprobar el resultado. La de arriba tiene seis secciones: problema, objetivos, historias de usuario, criterios de aceptación, no-objetivos y riesgos, cada una con su prompt.

¿Un PRD para un producto de IA es distinto de un PRD normal?

Las secciones son las mismas. Lo que cambia son los criterios de aceptación: una función de IA necesita criterios para los casos en que el modelo se equivoca, es lento o no está disponible, y un umbral de precisión declarado en lugar de "funciona correctamente". Añade un no-objetivo para los comportamientos que no intentarás cubrir en la primera versión.

¿Cuánto debe ocupar un PRD?

Menos de dos páginas para una función, tres o cuatro para un producto nuevo. Si una sección se alarga más, suele ser un documento de diseño o un backlog escondido dentro del PRD. Sácalo y enlázalo.

¿Puedo pedirle a ChatGPT o Claude que escriba el PRD entero?

Puedes, y el resultado se leerá bien, que es justo el problema. Un PRD de un solo prompt inventa evidencia y valores actuales porque no tiene ninguno. Pedir una sección cada vez con tus propios números, y corregir cada una antes de la siguiente, mantiene el documento honesto.

¿En qué se diferencia esto de GitHub Spec Kit?

Spec Kit es un kit de herramientas para agentes de programación que convierte una especificación en un plan, tareas y código mediante comandos en el chat del agente. Esta plantilla es la especificación en sí, escrita para que una persona la acuerde antes de que empiece ese proceso. Encajan: escribe el PRD y después dáselo al paso specify.

¿Adónde van los criterios de aceptación cuando el PRD está acordado?

Cada uno se convierte en la definición de terminado de una incidencia. En Atrix, la tabla de requisitos de la página del PRD es lo que la auditoría de requisitos comprueba después: compara lo planificado con la línea base congelada, no el código fuente. La entrada del glosario sobre PRD explica los términos.

Siguiente paso

Copia el Markdown de arriba, o abre la plantilla de PRD alojada y rellénala con tu equipo. Si prefieres partir de un brief, el agente de Atrix redacta la primera versión en una página durante la prueba de 7 días.

Fuentes

Precios de ChatPRD y GitHub Spec Kit, ambos consultados en octubre de 2026.