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

Un documento de requisitos de producto (PRD) es una descripción breve y en lenguaje sencillo de lo que estás creando, para quién es, qué debe hacer y cómo sabrás que funciona. La IA acelera mucho escribirlo: 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 lo que se deja 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 rellenar 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 resuelve 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 corresponde a una especificación técnica aparte, si la necesitas. Tampoco es un brief de marketing ni un plan de negocio. Limitar el PRD al comportamiento del producto es lo que lo hace útil para todos los que lo leen: un diseñador, un desarrollador, una persona de negocio que lo aprueba o un generador 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 único lugar donde esté «lo que acordamos».
• Quien contrata a un freelance o a una agencia, porque un PRD claro consigue presupuestos más precisos. Consulta contratar a un desarrollador o crear con IA.
• Quien crea con IA, porque las historias de usuario y la lista de datos de un PRD dan mejores prompts que una lista de deseos sin estructura.

En qué es buena la IA y en qué no

El fallo más habitual es el inverso de la penúltima fila: la IA rellena los huecos con suposiciones verosímiles 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 escribir ningún prompt, anota notas en bruto. Las viñetas valen. Incluye:

• El problema, en una o dos frases, desde el punto de vista del usuario.
• Quién lo tiene. Sé concreto: «gestores freelance con entre 10 y 40 clientes», no «pequeñas empresas».
• Qué hacen hoy en su lugar (una hoja de cálculo, el correo, una herramienta que no les gusta).
• El único resultado que haría de la versión uno un éxito.
• Lo que ya sabes que no vas a hacer.
• Limitaciones firmes: fecha límite, presupuesto, que deba funcionar en el móvil, que deba integrarse con una herramienta que ya uses.

Si no has hablado con nadie que tenga ese problema, hazlo antes. Cómo validar una idea de app explica una forma práctica de hacerlo. Un PRD basado en suposiciones es una suposición bien presentada.

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: si mis notas no lo dicen, escribe la pregunta en Preguntas abiertas.

La última instrucción es importante. Pedir a la IA que lleve lo desconocido a «Preguntas abiertas» en lugar de rellenarlo produce un borrador mucho más honesto.

Paso 3: afina cada sección

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

Problema y usuarios

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

Si el enunciado 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, indica cómo la mediría.

Elige una o dos. «Veinte gestores lo 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 funcionalidades. Este prompt hace lo contrario. Sé implacable: la mayoría de los PRD de la versión uno 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 de dos a cuatro criterios de aceptación en formato Dado / Cuando / Entonces.

Los criterios de aceptación son la lista de comprobación con la que probarás más adelante. «Dado un horario reservado, cuando otro cliente vea el calendario, entonces ese horario no aparecerá» es comprobable. «La reserva funciona bien» no lo es.

Casos límite y permisos

Para cada historia de usuario, enumera qué ocurre 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 su sitio. Detecta con rapidez los estados vacíos y los huecos de permisos que la gente suele olvidar.

Paso 4: revísalo como un escéptico

Lee todo una vez más y comprueba:

• Cada afirmación sobre usuarios procede 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 tener que preguntarte.
• 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 limitació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 pregúntale qué no está claro. Sus preguntas son los huecos.

Plantilla de PRD para rellenar

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

Nombre del producto: [nombre] Responsable: [persona responsable de 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 supone un problema.]

3. Usuarios

4. Objetivos y métricas de éxito

• Objetivo: [el resultado que la versión uno debe conseguir]
• Métrica: [cómo lo 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:

• [funcionalidad]
• [funcionalidad]

No incluido en la versión uno:

• [funcionalidad, y por qué puede esperar]
• [funcionalidad, 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 mal escrito o un campo que falta]
• [Acceso: qué pasa cuando alguien abre una página a la que no debería tener acceso]

10. Integraciones y limitaciones

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

11. Preguntas abiertas

Del PRD a los prompts

Un buen PRD se convierte casi directamente en prompts para un generador 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 incluido en la versión uno» es lo que todavía no pides.

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 el PRD completo y pedirlo todo a la vez. Cómo escribir prompts para generadores de apps con IA explica con más detalle la parte de los prompts.

Errores habituales

• 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 estás construyendo es peor que no tener ninguno. 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 deben aplicarse siempre (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