Comment rédiger un PRD à partir duquel les développeurs peuvent expédier

La plupart des documents sur les exigences produit échouent pour la même raison : ils décrivent les fonctionnalités plutôt que les problèmes et les résultats. Un chef de produit écrit "le système devrait avoir un tableau de bord avec des graphiques". Un ingénieur lit cela et demande : quels graphiques ? Quelles données ? Pour qui ? Pourquoi des graphiques plutôt qu'un tableau, une exportation ou un e-mail automatisé ?

Le PRD devient une liste de souhaits de fonctionnalités. Les ingénieurs l'interprètent différemment de ce que le PM voulait. La portée s'étend dans trois directions à la fois. Deux mois plus tard, l'équipe a construit quelque chose qui correspond techniquement aux spécifications mais ne résout le problème de personne.

Un bon modèle de document d'exigences produit fait bien une chose : il donne aux ingénieurs suffisamment de contexte pour prendre des milliers de micro-décisions sans avoir à revenir au PM pour chacune d'entre elles. Il répond « pourquoi » avant « quoi » et « pour qui » avant « comment ».

C'est le format que nous utilisons àSavipendant notrePhase de découverte et PRD. Nous avons expédié des produits complexes à partir de ces documents, notammentFenado IA, une plateforme agent qui transforme les invites textuelles en applications Web fonctionnelles, qui dessert désormais 50 000 utilisateurs.

Les 7 sections dont votre PRD a besoin

Un modèle de document sur les exigences du produit utile comporte sept sections. Chaque section impose un type spécifique de clarté. Sautez-en un et vous créez un vide qui se remplit d'hypothèses au cours du développement.

1. Énoncé du problème

Énoncez le problème en termes d’une personne spécifique éprouvant une douleur spécifique. Trois questions structurent cette section :

• Qui a ce problème ?Nommez le personnage. "Les responsables des opérations dans les entreprises de logistique comptant entre 50 et 200 chauffeurs" sont utiles. Les "utilisateurs" ne le sont pas.
• Est-ce douloureux ?Quantifiez le coût. Temps perdu, argent perdu, erreurs créées. "Les répartiteurs passent 3 heures par jour à attribuer manuellement des itinéraires" est un problème qui mérite d'être résolu. "L'affectation des itinéraires pourrait être améliorée" ne dit rien aux ingénieurs.
• Que font-ils maintenant ?Décrivez la solution de contournement actuelle. Les gens résolvent ce problème aujourd’hui, même si leur solution est lente, manuelle ou sujette aux erreurs. Comprendre la solution de contournement indique aux ingénieurs à quoi ressemble « assez bon » et où se situe la barre.

L'énoncé du problème est le fondement. Si l'ingénierie comprend bien le problème, elle fera de meilleurs compromis de conception sans escalader les décisions. Si ce n'est pas le cas, attendez-vous à un message Slack pour chaque ambiguïté de la spécification.

2. Indicateurs de réussite

Définissez à quoi ressemble « fait » avec des chiffres spécifiques. Des objectifs vagues comme « améliorer l’expérience utilisateur » sont impossibles à mesurer et impossibles à atteindre. Comparez ces deux :

• Vague:"Rendre l'intégration plus rapide"
• Spécifique:"Réduisez l'intégration des nouveaux utilisateurs de 3 jours à 2 heures en éliminant l'étape d'importation manuelle des données"

La version spécifique indique aux ingénieurs sur quoi se concentrer. Ils savent que l’étape d’importation des données constitue le goulot d’étranglement. Ils savent que l'objectif est de 2 heures, et non de 2 minutes, ce qui change le degré d'automatisation qui mérite d'être construit. Incluez 3 à 5 métriques. Au-delà de cela, vous optimisez trop de résultats à la fois, ce qui signifie que vous n'optimisez aucun d'entre eux.

3. User stories regroupées par persona

Regroupez les histoires par personne effectuant l'action, et non par domaine de fonctionnalité. Cela incite les ingénieurs à penser aux flux de travail plutôt qu'aux écrans. Une user story suit le format :"En tant que [persona], je veux [agir] pour obtenir [un résultat]."

Un exemple pour un SaaS de réservation de taxi :

• Passagère:"En tant que passager, je souhaite obtenir une estimation tarifaire avant de réserver afin de pouvoir comparer les prix."
• Conductrice:"En tant que conducteur, je souhaite voir le lieu de prise en charge sur une carte afin de pouvoir naviguer sans appeler le passager."
• Opératrice:"En tant qu'opérateur de flotte, je souhaite voir tous les trajets actifs dans une seule vue afin de pouvoir réaffecter les chauffeurs en cas d'annulation."

Trois personnes différentes, trois besoins différents, trois interfaces différentes. Le regroupement par personnalité évite l'erreur courante de créer un écran qui essaie de servir les trois et ne sert bien aucun d'entre eux.

4. Limite de portée (ce que vous ne construisez PAS)

Cette section compte autant que la liste des fonctionnalités. La limite de portée est un accord écrit sur ce que le produit ne fera pas au cours de cette phase. Sans cela, la portée s'étend dès le premier jour, car chaque partie prenante suppose que sa fonctionnalité préférée est incluse.

Écrivez des exclusions explicites :

• "Pas d'application mobile dans la v1. Web uniquement avec un design réactif."
• "Pas de support multilingue avant la phase 2."
• "Paiements traités par la redirection Stripe Checkout ; pas de flux de paiement personnalisé."
• "Le panneau d'administration est uniquement interne ; pas de marque blanche pour les locataires."

Chaque exclusion empêche une conversation qui aurait autrement lieu au milieu du sprint lorsque quelqu'un dit "attendez, je pensais que nous construisions cela aussi". Mettez les décisions difficiles dans le document dès le départ, pas dans le stand-up dans trois semaines.

5. Contraintes techniques

Répertoriez les éléments non négociables qui limitent la façon dont le produit est construit. Ce ne sont pas des détails d’implémentation (ne spécifiez pas de bases de données ou de frameworks ici). Il s’agit d’exigences commerciales et de conformité que l’ingénierie doit connaître avant de choisir son approche.

• Intégrations :"Doit extraire les données d'inventaire du système SAP existant du client via RFC." Les ingénieurs doivent connaître les dépendances tierces avant de concevoir la couche de données.
• Performance:"Le tableau de bord doit se charger en moins de 2 secondes avec 10 000 lignes de données." Cette contrainte détermine les décisions concernant la mise en cache, la pagination et l'opportunité de pré-agréger les données.
• Conformité:"Toutes les données des patients doivent être cryptées au repos et en transit. Conformité HIPAA requise." Cette seule phrase change toute l’approche de l’infrastructure.
• Résidence des données :"Les données des utilisateurs doivent rester dans les centres de données de l'UE." Cela élimine certains fournisseurs de cloud et certaines régions.

Les contraintes techniques empêchent l'ingénierie de créer quelque chose qui fonctionne en phase de préparation et qui échoue en production, car personne n'a mentionné l'intégration SAP avant la sixième semaine.

6. Wireframes ou flux d'utilisateurs

Les wireframes n'ont pas besoin d'être soignés. Ils doivent être clairs. Un prototype Figma fonctionne, tout comme un diagramme dessiné à la main et photographié avec l'appareil photo d'un téléphone. Ce qui compte, c'est que le document montre comment un utilisateur se déplace dans le système, écran par écran.

Inclure au minimum :

• Le chemin heureux pour chaque personnage (le flux attendu quand tout va bien)
• États d'erreur et cas extrêmes (que se passe-t-il en cas d'échec du paiement, lorsque des données sont manquantes, lorsque l'utilisateur perd la connectivité)
• Le point d’entrée (comment l’utilisateur découvre-t-il cette fonctionnalité pour la première fois ?)

Les flux d'utilisateurs exposent une complexité que les descriptions textuelles cachent. Vous pouvez décrire un processus de paiement en deux phrases. Lorsque vous le dessinez, vous réalisez qu'il y a sept écrans, trois chemins de branchement et deux points d'intégration. Ce visuel force une estimation honnête.

7. Jalons avec critères d'acceptation

Divisez le projet en étapes de 2 à 4 semaines. Chaque jalon fournit un incrément de travail que les parties prenantes peuvent voir et tester. Pour chaque étape, écrivez des critères d'acceptation binaires : réussite ou échec, terminé ou non.

• Jalon 1 (semaines 1-2) :L'utilisateur peut s'inscrire, se connecter et voir un tableau de bord vide. Acceptation : le flux d'authentification fonctionne avec l'e-mail/mot de passe et Google OAuth. Le tableau de bord s'affiche avec une messagerie à état zéro.
• Jalon 2 (semaines 3-4) :L'utilisateur peut créer et modifier des projets. Acceptation : les opérations CRUD fonctionnent. La validation du formulaire détecte les champs vides et les noms en double. Les données persistent d’une session à l’autre.
• Jalon 3 (semaines 5-6) :L'utilisateur peut inviter des membres de l'équipe et attribuer des rôles. Acceptation : l'e-mail d'invitation est envoyé dans les 30 secondes. L'utilisateur invité peut accepter et accéder au projet avec les autorisations appropriées.

Les jalons créent des points de contrôle naturels pour la correction de cap. Si l’étape 2 prend quatre semaines au lieu de deux, vous le savez avant le début de l’étape 3. Vous pouvez ajuster la portée, le calendrier ou le budget avant que les dépassements ne surviennent.

Erreurs courantes qui brisent un PRD

Écrire 40 pages que personne ne lit

Si votre PRD fait plus de 10 pages, les ingénieurs le parcourront. Ils liront la première section, passeront à la partie pertinente à leur sprint et passeront à côté du contexte qui lie leur travail aux objectifs du produit. Un document concis qui est lu vaut mieux qu'un document complet stocké dans Google Drive. Visez 5 à 10 pages avec des liens vers du matériel supplémentaire (wireframes, données de recherche, analyse concurrentielle) pour les personnes qui veulent de la profondeur.

Spécification des détails de mise en œuvre

Un PRD doit décrire ce que fait le produit et pourquoi. Il ne doit pas spécifier que le backend utilise PostgreSQL avec un schéma spécifique, ou que le frontend utilise React avec Redux. Ce sont des décisions techniques qui appartiennent à l’équipe d’ingénierie. Lorsqu'un chef de produit précise les détails de la mise en œuvre, deux choses se produisent : les ingénieurs se sentent microgérés et le produit se retrouve enfermé dans des décisions techniques prises sans contexte technique complet. Énoncez la contrainte (« doit gérer 10 000 utilisateurs simultanés ») et laissez les ingénieurs choisir les outils.

Aucune limite de portée

C'est l'erreur la plus coûteuse. Sans limite de portée écrite, les parties prenantes supposent des choses différentes sur ce qui est inclus. Le PDG attend une application mobile. Le vice-président des ventes s'attend à une intégration CRM. Le Premier ministre ne s’attendait ni à l’un ni à l’autre. Au moment où ces hypothèses font surface, l’équipe a brûlé trois semaines de construction dans la mauvaise direction. Notez ce qui est exclu. Obtenez l’approbation des exclusions. Référez-vous à eux lorsque quelqu'un demande "pouvons-nous également ajouter..."

Répertorier les fonctionnalités sans expliquer pourquoi

"Le système devrait avoir un centre de notification." Pourquoi? Qui est informé ? À propos de quoi? Dans quelle mesure ces notifications sont-elles urgentes ? L'utilisateur doit-il agir en conséquence ou sont-ils informatifs ? Une fonctionnalité sans « pourquoi » est construite selon l'interprétation de l'ingénieur, qui peut ne pas correspondre aux besoins de l'utilisateur. Associez les fonctionnalités aux user stories et aux indicateurs de réussite. Si une fonctionnalité ne correspond pas à une user story, demandez-vous si elle appartient à cette phase.

Modèle de document sur les exigences du produit

Copiez ce modèle et remplissez-le pour votre prochain projet. Chaque section comprend des invites pour guider votre écriture.

Comment Savi utilise les PRD dans la phase de découverte et PRD

Lorsque vous démarrez un projet avecSavi, la deuxième étape de notreprocessusest Découverte et PRD. Nous définissons ensemble la portée, les fonctionnalités et l’architecture technique. Vous obtenez un document détaillé sur les exigences du produit avec les étapes et les prix avant qu'un code ne soit écrit.

Ce n'est pas une formalité. Le PRD est le contrat entre ce que vous attendez et ce que nous construisons. Chaque fonctionnalité, jalon et critère d'acceptation du PRD devient un élément de ligne dans le plan de projet. Lorsqu'une question surgit pendant le développement, nous vérifions d'abord le PRD, puis en parlons ensuite. Cela réduit la boucle de rétroaction de quelques jours à quelques minutes.

Voici ce que couvre notre processus Discovery & PRD :

• Validation du problème :Nous remettons en question vos hypothèses. Si le problème que vous décrivez ne correspond pas à ce que vivent vos utilisateurs, il est pire de créer rapidement une mauvaise solution que de créer lentement la bonne solution.
• Négociation du périmètre :Nous travaillons sur ce qui appartient à la v1 et ce qui devrait attendre. PourFenado IA, cela signifiait commencer par la génération d'applications sur une seule page avant de passer à une sortie full-stack avec des schémas de base de données et des routes API. La première version a prouvé la valeur fondamentale ; la deuxième version l'a développé.
• Esquisse d'architecture technique :Avant d'estimer, nous décrivons l'architecture du système. Cela détecte très tôt les signaux d’alarme : complexité de l’intégration, goulots d’étranglement en matière de performances, exigences de conformité qui modifient l’approche de l’infrastructure.
• Jalons à prix fixe :Chaque étape du PRD correspond à un prix fixe. Vous savez ce que vous payez pour chaque livrable avant le début de l'ingénierie. Pas de surprises en matière de facturation horaire, pas de délais indéterminés.

La phase Discovery & PRD prend 3 à 5 jours ouvrés. Le résultat est un document que vous pouvez remettre à n'importe quelle équipe d'ingénierie, pas seulement la nôtre, et qui disposera de suffisamment de contexte pour estimer, planifier et construire. C'est le test d'un bon PRD : un ingénieur compétent qui ne vous a jamais parlé peut-il lire ce document et créer le bon produit ?

La rédaction du PRD est la première décision d'ingénierie

Le PRD n'est pas un document que vous rédigez avant le début de l'ingénierie. C'est la première décision d'ingénierie. La qualité de votre document d'exigences produit détermine si votre équipe passe son temps à créer le produit ou à débattre de ce que devrait être le produit.

Utilisez les sept sections. Soyez précis dans chacun. Notez ce que vous ne construisez pas. Définissez le succès avec des chiffres. Et lorsque vous touchez une section que vous ne pouvez pas remplir, c'est le signal pour faire plus de recherches avant d'écrire plus de code.

Un PRD de cinq pages qui répond aux bonnes questions surpassera un PRD de quarante pages qui répond aux mauvaises.

Questions fréquemment posées