Cómo escribir un documento de requisitos de producto (PRD) con IA (plantilla gratis)

Un documento de requisitos de producto (PRD, por sus siglas en inglés) es una descripción breve y en lenguaje sencillo de lo que estás construyendo, para quién es, qué debe hacer y cómo sabrás que funciona. La IA hace que escribirlo sea mucho más rápido: le das notas en bruto y las convierte en secciones estructuradas, historias de usuario y casos límite. Tu trabajo es aportar las decisiones que la IA no puede tomar (el objetivo, el alcance y qué queda fuera) y revisar lo que añade.

Esta guía explica qué debe incluir un PRD, una forma paso a paso de redactarlo con cualquier asistente de IA, prompts para cada sección y una plantilla para completar que puedes copiar.

Para qué sirve un PRD (y para qué no)

Un PRD responde a cuatro preguntas:

1. ¿Por qué construimos esto? ¿Qué problema, y para quién?
2. ¿Qué debe hacer en la primera versión?
3. ¿Qué no hará todavía?
4. ¿Cómo sabremos que funcionó?

No es un diseño técnico. No dice qué base de datos o framework usar; eso va en una especificación técnica aparte, si la necesitas. Tampoco es un brief de marketing ni un plan de negocio. Mantener el PRD centrado en el comportamiento del producto es lo que lo hace útil para todos los que lo leen: un diseñador, un desarrollador, un stakeholder que lo aprueba o un creador de apps con IA que lo convierte en código.

Quién lo necesita

• Fundadores en solitario que quieren frenar el crecimiento descontrolado del alcance antes de que empiece.
• Equipos pequeños que necesitan un solo lugar donde viva “lo que acordamos”.
• Quien contrata a un freelancer o una agencia, porque un PRD claro produce presupuestos más claros. Consulta contratar a un desarrollador o construir con IA.
• Quien construye con IA, porque las historias de usuario y la lista de datos de un PRD hacen mejores prompts que una lista de deseos sin estructura.

Qué hace bien la IA y qué no

El fallo más común es el contrario de la penúltima fila: la IA rellena con seguridad los huecos con suposiciones plausibles sobre tus usuarios. Trata todo lo que escriba sobre usuarios, tamaño de mercado o comportamiento como una pregunta que hay que verificar, no como un hecho.

Paso 1: vuelca lo que sabes

Antes de pedir nada, escribe notas en bruto. Las viñetas valen. Cubre:

• El problema, en una o dos frases, desde el punto de vista del usuario.
• Quién lo tiene. Sé específico: “contables freelance con entre 10 y 40 clientes”, no “pequeñas empresas”.
• Qué hacen hoy en su lugar (una hoja de cálculo, un correo, una herramienta que no les gusta).
• El único resultado que haría que la versión uno fuera un éxito.
• Lo que ya sabes que no vas a hacer.
• Restricciones firmes: fecha límite, presupuesto, que funcione en el móvil, que se integre con una herramienta que ya usen.

Si todavía no has hablado con nadie que tenga ese problema, hazlo primero. Cómo validar una idea de app tiene una forma práctica de hacerlo. Un PRD basado en suposiciones es una suposición bien formateada.

Paso 2: pide a la IA un primer borrador

Pega tus notas y pide un borrador con una estructura fija. Un prompt que funciona bien:

Estas son mis notas sobre un producto. Conviértelas en un documento de requisitos de producto usando exactamente estas secciones: Resumen, Problema, Usuarios, Objetivos y métricas de éxito, Alcance (dentro / fuera), Historias de usuario con criterios de aceptación, Datos, Permisos, Casos límite, Preguntas abiertas. Que no ocupe más de dos páginas. No inventes datos sobre usuarios ni sobre el mercado: cuando mis notas no digan algo, escribe la pregunta en Preguntas abiertas.

La última instrucción es importante. Pedirle a la IA que mande lo desconocido a “Preguntas abiertas” en lugar de rellenarlo produce un borrador mucho más honesto.

Paso 3: afina cada sección

Revisa el borrador sección por sección. Estos prompts de seguimiento ayudan:

Problema y usuarios

Reescribe el planteamiento del problema en una o dos frases desde el punto de vista del usuario. Sin palabras de solución.

Si el planteamiento del problema menciona tu producto, en realidad está describiendo una solución, no un problema.

Objetivos y métricas de éxito

Sugiere tres métricas de éxito para la versión uno que pueda medir en el primer mes con un número reducido de usuarios. Para cada una, explica cómo la mediría.

Elige una o dos. “Veinte contables la usan cada semana durante un mes” es medible. “Mejorar la productividad” no lo es.

Alcance

Enumera todo lo de este PRD que podría pasar a una versión posterior sin romper el flujo principal.

Las herramientas de IA tienden a añadir funciones. Este prompt les hace hacer lo contrario. Sé implacable: la mayoría de los PRD de la primera versión son demasiado grandes. Qué es un MVP explica por qué las primeras versiones pequeñas te enseñan más.

Historias de usuario y criterios de aceptación

Escribe cada requisito como una historia de usuario (“Como [usuario], quiero [acción] para que [resultado]”) con dos a cuatro criterios de aceptación en formato Dado / Cuando / Entonces.

Los criterios de aceptación son la lista de comprobación contra la que probarás más adelante. “Dado un horario reservado, cuando otro cliente mira el calendario, entonces el horario no aparece” es comprobable. “La reserva funciona bien” no lo es.

Casos límite y permisos

Para cada historia de usuario, enumera qué pasa con datos vacíos, entradas no válidas, una petición de red lenta o fallida, y un usuario que no debería tener acceso.

Aquí es donde la IA se gana el sueldo. Es rápida detectando los estados vacíos y los huecos de permisos que la gente olvida.

Paso 4: revísalo como un escéptico

Lee todo una vez más y comprueba:

• Cada afirmación sobre usuarios viene de ti o de una investigación, no de la IA.
• El alcance “fuera” es al menos tan largo como el alcance “dentro”.
• Cada historia de usuario tiene criterios de aceptación que alguien podría probar sin preguntarte a ti.
• La sección de datos enumera cada tipo de registro que guarda la app y quién puede verlo.
• Las preguntas abiertas tienen un responsable y una fecha.
• Nada técnico se ha colado, salvo que sea una restricción real (“debe funcionar sin conexión” es un requisito; “usar Redis” no lo es).

Después, compártelo con una persona que vaya a usar o construir el producto y pídele que diga qué no está claro. Sus preguntas son los huecos.

Plantilla de PRD para completar

Cópiala en un documento y reemplaza los corchetes. Elimina las secciones que de verdad no apliquen.

Nombre del producto: [nombre] Responsable: [persona que toma las decisiones] Estado: [borrador / en revisión / acordado] — Última actualización: [fecha]

1. Resumen

[Dos o tres frases: qué es, para quién y el resultado principal.]

2. Problema

[El problema desde el punto de vista del usuario. Qué hace hoy y por qué le duele.]

3. Usuarios

4. Objetivos y métricas de éxito

• Objetivo: [el resultado que debe lograr la versión uno]
• Métrica: [cómo la medirás y el objetivo]
• No objetivo: [algo que la gente podría suponer y que esta versión no pretende hacer]

5. Alcance

En la versión uno:

• [función]
• [función]

No está en la versión uno:

• [función, y por qué puede esperar]
• [función, y por qué puede esperar]

6. Historias de usuario

Historia 1: Como [usuario], quiero [acción] para que [resultado].

• Dado [contexto], cuando [acción], entonces [resultado].
• Dado [contexto], cuando [acción], entonces [resultado].

Historia 2: Como [usuario], quiero [acción] para que [resultado].

• Dado [contexto], cuando [acción], entonces [resultado].

7. Datos

8. Permisos

[Quién puede iniciar sesión, qué roles existen y qué puede ver y cambiar cada rol.]

9. Casos límite

• [Estado vacío: qué se muestra cuando todavía no hay datos]
• [Entrada no válida: qué pasa con un correo incorrecto o un campo vacío]
• [Acceso: qué pasa cuando alguien abre una página que no debería]

10. Integraciones y restricciones

[Pagos, correo electrónico, herramientas existentes, fechas límite, presupuesto, dispositivos en los que debe funcionar.]

11. Preguntas abiertas

De PRD a prompts

Un buen PRD se convierte casi directamente en prompts para un creador de apps con IA:

• El resumen, los usuarios y la tabla de datos se convierten en tu primer prompt.
• Cada historia de usuario se convierte en un prompt de seguimiento.
• Cada criterio de aceptación se convierte en algo que compruebas en la vista previa.
• La lista de “no está en la versión uno” es lo que no pides todavía.

Construir una historia cada vez y comprobar sus criterios de aceptación antes de pasar a la siguiente es mucho más fiable que pegar todo el PRD y pedir todo a la vez. Cómo escribir prompts para creadores de apps con IA cubre el lado de los prompts con más detalle.

Errores comunes

• Escribir la solución como si fuera el problema. “Los usuarios necesitan un panel” es una solución. “Los propietarios no pueden ver qué facturas están vencidas sin abrir cada una” es un problema.
• No tener sección de “fuera de alcance”. Sin ella, cada conversación vuelve a abrir el alcance.
• Dejar que la IA invente usuarios. Los perfiles que inventa la IA parecen reales y no lo son.
• Métricas que no puedes medir. Si no tienes forma de contarlo, no es una métrica.
• No actualizarlo nunca. Un PRD que ya no coincide con lo que construyes es peor que no tenerlo. Mantén una fecha de “última actualización” y cámbiala cuando cambien las decisiones.

Usar un PRD con Mythex

Si construyes en Mythex, puedes pegar tu PRD directamente en el chat. Empezar en modo Plan encaja bien con un PRD: el agente lo lee, propone un enfoque y una lista de pasos que puedes revisar en una pestaña de plan, y solo empieza a cambiar archivos cuando pulsas Build. También puedes guardar como conocimiento del proyecto las partes que siempre deben aplicarse (público, marca, reglas) para no repetirlas en cada chat. Los documentos del chat explican los modos Build, Plan y Ask, y las plantillas son una forma rápida de ver cómo podría ser una primera versión antes de escribir el documento completo.

Preguntas