¿Cómo escribes un buen Documento de Requisitos del Producto (PRD)?

Question

Accepted Answer

Un **Documento de Requisitos del Producto (PRD)** explica *qué* estás construyendo, *por qué*, y *cómo sabrás que funcionó* — para que ingeniería y diseño puedan construir lo correcto sin aclaraciones constantes. Un buen PRD es una herramienta de pensamiento y un artefacto de alineación, no un papeleo burocrático.

## Un esquema sólido de PRD

```text
1. PROBLEM / CONTEXT → what problem, for whom, why now
2. GOALS & SUCCESS METRICS → what outcome, how measured
3. NON-GOALS → what this explicitly does NOT cover
4. USER STORIES / REQUIREMENTS → what it must do
5. UX → flows, wireframes, key states
6. EDGE CASES → errors, empty states, limits
7. DEPENDENCIES & RISKS → what could block or break this
8. OPEN QUESTIONS → known unknowns to resolve
```

## Comienza con el por qué

La sección más importante es el **problema y objetivos**. Si el equipo entiende *por qué* y *cómo se ve el éxito*, a menudo encontrarán soluciones mejores que la que especificaste. Un PRD que es solo una especificación de características pierde esto.

## Los no-objetivos están subestimados

Establecer explícitamente qué está fuera del alcance previene el scope creep y la trampa "mientras estamos en eso...". Es tan valioso como los requisitos en sí.

## Errores comunes

```text
✗ Over-specifying the HOW → boxes in engineering's better ideas
✗ No success metric → you can't tell if it worked
✗ Writing it alone → involve eng/design early to catch issues
✗ Treating it as fixed → a PRD is a living doc
```

## Por qué es importante

La mayoría del retrabajo proviene de desalineación: el equipo construyó lo que se pidió, no lo que era necesario.

Un PRD claro expone esas brechas *antes* de que alguien escriba código.

También te obliga a ti *a ti* a pensar el problema a través.

Si no puedes escribir el objetivo y la métrica de éxito claramente, no entiendes el problema lo suficientemente bien para construirlo aún.