Cómo escribir un PRD (documento de requisitos de producto): estructura, ejemplo completo y primer borrador con IA gratis

Resumen ejecutivo

• Un PRD (Product Requirements Document) es el documento que explica qué problema resuelve una funcionalidad, para quién, cómo se mide el éxito y qué entra y qué no en el alcance.

• Un buen PRD tiene siete secciones: problema, objetivo y métrica, usuarios, alcance y fuera de alcance, requisitos, riesgos y preguntas abiertas.

• Incluimos un ejemplo completo para una funcionalidad de una app y un prompt para que un asistente de IA gratuito arme el primer borrador a partir de tus notas.

• Un PRD bien escrito es también una gran pieza de portfolio para quien busca su primer puesto en producto.

Cuando una funcionalidad sale mal, casi nunca es por el código. Es porque diseño entendió una cosa, desarrollo otra y negocio esperaba una tercera. El PRD existe para evitar eso: es el lugar donde se escribe, antes de construir, qué problema se quiere resolver y cómo se va a saber si funcionó. En CoderLibrary ya explicamos qué hace un Product Manager y cómo escribir historias de usuario y criterios de aceptación. El PRD es la pieza que va antes y las ordena. Y como hoy cualquier asistente de IA gratuito puede ayudarte con el primer borrador, armar uno ya no lleva días.

Qué es un PRD y cuándo se usa

El PRD es un documento corto (de una a cinco páginas, en general) que el Product Manager escribe para alinear al equipo antes de diseñar y desarrollar una funcionalidad o un producto. No es un manual técnico ni una lista de tareas: es el acuerdo sobre el qué y el por qué. El cómo queda en manos de diseño y desarrollo. La guía de Atlassian sobre documentos de requisitos de producto lo describe como un documento vivo, que se actualiza a medida que el equipo aprende.

Se usa sobre todo cuando:

• La funcionalidad involucra a varios equipos (diseño, desarrollo, datos, soporte, marketing).

• El alcance no es obvio y hay que decidir qué queda afuera.

• Hay que justificar la inversión ante líderes o stakeholders.

Las 7 secciones de un buen PRD

1. Problema: qué le pasa al usuario o al negocio hoy, con datos si los hay. Sin solución todavía.

2. Objetivo y métrica de éxito: qué querés lograr y cómo lo vas a medir. Una métrica principal y, si hace falta, una o dos de control.

3. Usuarios: quiénes tienen el problema y en qué contexto. Puede incluir personas o segmentos.

4. Alcance y fuera de alcance: qué se va a construir en esta versión y, tan importante como eso, qué no.

5. Requisitos: lo que la solución tiene que cumplir, escrito como historias de usuario o como requisitos funcionales, con criterios de aceptación.

6. Riesgos y dependencias: qué puede salir mal, qué depende de otros equipos o proveedores.

7. Preguntas abiertas: lo que todavía no se sabe y quién lo va a responder.

Muchas plantillas suman cronograma, diseño de referencia o plan de lanzamiento. Sirven, pero estas siete secciones son el núcleo. El glosario de ProductPlan sobre el PRD repasa variantes según el tipo de empresa.

Ejemplo completo: recordatorio de turnos en una app de salud

Una app ficticia permite reservar turnos con profesionales de la salud. Este es un PRD resumido para una funcionalidad nueva. Los números son de ejemplo.

1. Problema

El 18% de los turnos reservados en la app terminan en ausencia sin aviso. Los profesionales pierden ingresos y los pacientes que esperan un turno no consiguen lugar. En las encuestas, la razón más citada es «me olvidé».

2. Objetivo y métrica de éxito

Reducir las ausencias sin aviso. Métrica principal: tasa de ausencias sin aviso, de 18% a menos de 12% en los tres meses posteriores al lanzamiento. Métrica de control: que la tasa de cancelaciones con aviso no suba tanto como para dejar turnos vacíos sin reasignar.

3. Usuarios

Pacientes con turnos reservados desde la app, sobre todo los que reservan con más de una semana de anticipación (el grupo con más ausencias).

4. Alcance

Entra: notificación push 24 horas antes, con botones «Confirmo» y «Cancelar»; liberación automática del turno si el paciente cancela. Fuera de alcance en esta versión: recordatorios por WhatsApp, lista de espera automática y penalidades por ausencia.

5. Requisitos

• Como paciente, quiero recibir un recordatorio 24 horas antes de mi turno para no olvidarme. Criterio: la notificación muestra profesional, fecha, hora y dirección.

• Como paciente, quiero cancelar desde el recordatorio para no tener que entrar a la app. Criterio: al tocar «Cancelar», el turno queda libre en menos de un minuto.

• Como profesional, quiero ver en mi agenda qué turnos están confirmados. Criterio: los confirmados se marcan con un ícono distinto.

6. Riesgos y dependencias

Un porcentaje de usuarios tiene las notificaciones desactivadas; habrá que medir el alcance real. Depende del equipo de plataforma para el servicio de notificaciones.

7. Preguntas abiertas

¿24 horas es el mejor momento o conviene probar 48? ¿Qué hacemos con turnos reservados el mismo día? Responsable: equipo de producto con datos, antes del inicio del desarrollo.

Cómo armar el primer borrador con IA gratis

Un asistente gratuito como ChatGPT, Gemini o Claude es muy bueno para ordenar notas sueltas en una estructura. Un prompt que funciona:

«Actuá como Product Manager. Con estas notas, escribí un PRD de no más de dos páginas con estas secciones: problema, objetivo y métrica de éxito, usuarios, alcance y fuera de alcance, requisitos como historias de usuario con criterios de aceptación, riesgos y dependencias, preguntas abiertas. No inventes datos: donde falte información, escribí [COMPLETAR]. Al final, listá 5 preguntas que un desarrollador o un diseñador me haría al leerlo. Notas: [pegá tus notas].»

Dos detalles importan: pedirle que marque lo que falta en vez de inventarlo, y pedirle las preguntas del equipo, que te muestran los huecos antes de la reunión.

Qué revisar antes de compartirlo

• ¿El problema se entiende sin la solución? Si la sección de problema ya describe la funcionalidad, reescribila.

• ¿La métrica se puede medir hoy? Si no hay datos para medirla, agregá el trabajo de instrumentación al alcance.

• ¿Hay un fuera de alcance explícito? Es la sección que más discusiones ahorra.

• ¿Los datos son reales? Revisá cada número que haya puesto la IA.

• ¿Lo leyó alguien de diseño y de desarrollo? Un PRD que nadie discutió no alinea a nadie.

Después del PRD viene la planificación del trabajo. Si tu equipo trabaja con sprints, te sirve Scrum en la práctica: cómo aplicar metodología ágil en tu equipo.

El PRD como pieza de portfolio

Si buscás tu primer puesto en producto, escribir un PRD para una funcionalidad de una app que uses todos los días es una de las mejores formas de mostrar cómo pensás. Elegí un problema real, explicá con qué datos lo detectarías, definí la métrica y dejá claro qué quedaría fuera de alcance. Muchos procesos de selección para Product Manager incluyen un ejercicio parecido.

Cursos recomendados de Coderhouse

El curso de Product Manager trabaja la definición de problemas, métricas y requisitos, con ejercicios prácticos que podés sumar a tu portfolio. Si querés una formación más amplia en producto, la carrera de Producto suma discovery, UX y estrategia.

Preguntas frecuentes

¿Cuál es la diferencia entre un PRD y una historia de usuario? La historia de usuario describe una necesidad puntual; el PRD agrupa el problema, el objetivo, el alcance y todas las historias de una funcionalidad.

¿Los equipos ágiles siguen usando PRD? Muchos sí, en versiones más cortas y vivas, como una página en Notion o Confluence que se actualiza durante el desarrollo.

¿Quién escribe el PRD? Normalmente el Product Manager, con aportes de diseño, desarrollo, datos y negocio.

¿Puedo dejar que la IA escriba todo el PRD? Puede armar la estructura y el primer borrador, pero el problema, los datos y las decisiones de alcance tienen que salir de vos y del equipo.