Comment rédiger un bon Product Requirements Document (PRD) ?

Question

Accepted Answer

Un **Product Requirements Document (PRD)** explique *ce* que vous construisez, *pourquoi*, et *comment vous saurez que ça a marché* — pour que l'engineering et le design puissent construire la bonne chose sans clarifications constantes. Un bon PRD est un outil de réflexion et un artefact d'alignement, pas du travail administratif bureaucratique.

## Un plan solide 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
```

## Commencez par le pourquoi

La section la plus importante est le **problème et les objectifs**. Si l'équipe comprend *pourquoi* et *à quoi ressemble le succès*, elle trouvera souvent de meilleures solutions que celle que vous avez spécifiée. Un PRD qui n'est qu'une spécification de fonctionnalité manque cela.

## Les non-objectifs sont sous-estimés

Énoncer explicitement ce qui est hors périmètre prévient la dérive de portée et le piège du « puisqu'on y est... ». C'est aussi utile que les exigences elles-mêmes.

## Pièges courants

```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
```

## Pourquoi c'est important

La plupart des retravaux proviennent d'un désalignement : l'équipe a construit ce qui était demandé, pas ce qui était nécessaire.

Un PRD clair met en évidence ces lacunes *avant* que quelqu'un n'écrive du code.

Cela vous force aussi à *réfléchir* à fond au problème.

Si vous ne pouvez pas écrire clairement l'objectif et la métrique de succès, vous ne comprenez pas assez bien le problème pour le construire maintenant.