Qu’est-ce qu’un document sur les exigences du produit (PRD) ?

Un aperçu du document prototypique de gestion de produit

Kenton Kivestu, ex-Google, ex-BCG, fondateur chez RocketBlocks Publié : 11 septembre 2019 | Dernière mise à jour : 8 novembre 2019

Bases du PRD | Contenu du PRD | Walkthrough du PRD | Exemple complet du PRD

Un PRD est un ensemble structuré de directives sur ce que doit être un produit (ou une fonctionnalité).

En fin de compte, les PRD sont les goldilocks des documents de développement de produit : il ne peut pas être trop tarte à la crème (par ex, un communiqué de presse) ni ne peut être trop technique (par exemple, un plan de mise en œuvre détaillé d’ingénierie).

Donc, une façon utile de penser à un PRD est le document-pont qui peut prendre la vision de haut niveau du produit et la définir et l’étendre suffisamment pour qu’un ingénieur puisse écrire un plan de mise en œuvre crédible à partir de ce document.

Pourquoi les entreprises se donnent-elles la peine de rédiger des PRD ? Les PRD servent d’artefact de base qui expose la raison d’être d’un produit / d’une fonctionnalité en répondant à des questions fondamentales : Pourquoi devrions-nous le construire ? Quel problème va-t-il résoudre ? À quoi devrait-il ressembler ? À quoi ressemblera le succès ?

Quelles entreprises utilisent les PRD et qui les rédige ? (Haut)

En outre, la nomenclature préférée varie d’une entreprise à l’autre (et parfois même d’une équipe à l’autre !). Par exemple, Google désigne historiquement ces documents sous le nom de PRD, tandis que la société de jeux Zynga les désigne sous le nom de specs, qui est un raccourci pour les spécifications du produit.

Enfin, les chefs de produit sont souvent les auteurs des PRD, mais ce n’est pas vrai dans tous les cas. En particulier, dans les petites entreprises et les startups, un PRD pourrait être rédigé par un fondateur, un CTO, un responsable de l’ingénierie ou un autre responsable aidant au développement du produit. Mais, quel que soit l’auteur d’un PRD, la contribution des membres clés de l’équipe interfonctionnelle est essentielle pour produire un bon PRD.

Quelles sections et quels contenus doivent être inclus dans un PRD ? (Haut)

Les équipes qui utilisent des PRD ont tendance à s’installer sur une liste de sections  » incontournables  » dans un PRD qui ont du sens pour la taille de leur organisation, la cadence des versions, le stade et la complexité du produit. Ici, nous nous concentrerons sur une poignée de sections  » suspectes habituelles  » qui sont couramment incluses dans beaucoup de PRD :

• Contexte & justification : pourquoi construisons-nous ceci ?
• Goals & métriques de succès : quel est l’objectif concret de faire ceci ?
• Cas d’utilisation : quels sont les cas d’utilisation spécifiques que cela doit permettre ?
• Formalités : qu’est-ce qui doit être construit ?
• Questions ouvertes : quelles sont les questions auxquelles il faut répondre avant de pouvoir commencer ?

Pour passer en revue chacune de ces sections de PRD, nous allons imaginer que nous écrivons un PRD pour un petit ajout à l’application mobile Uber destinée aux coureurs. Imaginons que nous écrivions un PRD pour ajouter un petit extrait de texte descriptif à la page qu’Uber affiche aux riders lorsqu’ils ouvrent l’app après un trajet terminé (capture d’écran ci-dessous).

Exemple de PRD : mises à jour de l’app Uber faisant face aux coureurs (Haut)

Maintenant, sautons le pas et parcourons chaque section et imaginons à quoi pourrait ressembler un PRD abordant ce problème.

Section 1 : Contexte & justification

Cette section devrait exposer le contexte central qui éclaire pourquoi une fonctionnalité ou un produit particulier est envisagé. Elle peut inclure des anecdotes de l’équipe de support, des observations issues de la recherche UX, des données de marché à l’appui ou des idées que l’équipe a sur la direction dans laquelle le produit doit évoluer.

Selon la culture de l’équipe et la portée de la fonctionnalité, cette section peut être assez courte ou longue. Certaines organisations adorent effectuer des analyses détaillées, très quantitatives, qui plaident en faveur de la fonctionnalité.

Pour notre exemple de PRD Uber, nous pourrions imaginer quelque chose comme ceci :

Des sessions récentes de recherche sur les utilisateurs ont montré que de nombreux usagers omettent souvent de noter leur conducteur sur cet écran parce qu’ils ne se souviennent pas du conducteur qu’ils notent (ex, de nombreux usagers ne voient même jamais leur conducteur en face à face puisqu’ils sont à l’arrière).

Puisque les évaluations des conducteurs constituent un ensemble de données important pour nos algorithmes et nos opérations, tout « coup de pouce » que nous pouvons donner aux utilisateurs pour qu’ils évaluent les conducteurs aura un impact important et cumulatif sur l’entreprise.

Section 2 : Objectifs & métriques de succès

Puis, la section des objectifs exposera, sans surprise, le ou les objectifs spécifiques à accomplir par la fonctionnalité / le produit. Alors que la section du contexte peindra une image de la raison pour laquelle l’équipe pourrait penser que l’effort est important, la section des objectifs devrait mettre un pieu spécifique dans le sol sur la façon dont l’entreprise / l’équipe / le produit en bénéficiera et comment le mesurer.

Pour en revenir à notre PRD Uber, la section des objectifs pourrait ressembler à :

Piloter une augmentation de 5 % des cavaliers évaluant les conducteurs lorsqu’ils sont confrontés à cet écran d’évaluation de l’exécution de la course.

Section 3 : Cas d’utilisation

Les cas d’utilisation précisent comment les clients interagiront avec les changements de fonctionnalités proposés. L’objectif est de décrire le contexte spécifique dans lequel les clients feront l’expérience de la fonctionnalité et comment cela aidera les clients à accomplir des tâches spécifiques.

De nouveau, nous allons revenir à notre exemple d’écran de notation d’achèvement de trajet Uber :

Travis a récemment pris un Uber tard le vendredi soir après avoir rattrapé des amis. Il n’utilise plus Uber jusqu’à mercredi prochain, lors d’une journée de travail chargée, et c’est à ce moment-là qu’il ouvre l’application et voit la note d’achèvement de la course du vendredi soir. Il ne se souvient pas de la dernière fois qu’il a pris un Uber et ne reconnaît pas le chauffeur. En conséquence, il appuie sur le bouton « Skip » plutôt que de noter le conducteur.

Section 4 : Exigences

Ceci pourrait être considéré comme la « viande » d’un PRD, où ce qui est réellement construit sera décrit. En fonction de la fonctionnalité ou du produit en question, cette section pourrait inclure des wireframes de fonctionnalité, des maquettes de fidélité complète, des détails sur les changements qui devront être apportés sur le front-end (par exemple, les applications mobiles) et/ou le back-end (par exemple, les bases de données, le traitement, etc.).

Regardons à quoi cela pourrait ressembler pour l’exemple d’Uber :

Front-end

• Afficher un nouvel extrait de texte descriptif sous l’invite de notation actuelle
• Copier (exemple) : « Votre trajet de vendredi soir »

API

• Lorsque vous demandez les détails du trajet (par ex, conducteur, image du conducteur, etc), saisissez également le descripteur du trajet (pas besoin de construire une nouvelle logique ici, il suffit d’utiliser les mêmes descripteurs de trajet que nous avons déjà mis dans les sujets de reçus de trajet par courriel, au lieu des horodatages spécifiques).

Section 5 : Questions ouvertes

Enfin, les questions ouvertes sont une section utilisée comme une sorte de  » parking  » pour soulever des questions que l’auteur doit étudier, sur lesquelles il doit prendre une décision ou sur lesquelles il doit obtenir des commentaires avant de considérer que le PRD est terminé.

• Quelle couleur et quelle taille doit avoir le texte du descripteur à l’écran ? Cc @design – pouvez-vous recommander les bons paramètres ici ?
• Quelle est la granularité des descripteurs de manège qui sont générés (par ex, deviennent-ils plus spécifiques que, disons, vendredi soir ?)
• Si cette fonctionnalité ne produit pas les résultats souhaités, quelles prochaines étapes devrions-nous envisager ?

Mettre tout ça ensemble : un exemple complet de PRD (Haut)

Si vous mettez tout ce que nous avons discuté ensemble, vous obtiendrez finalement un document qui ressemble à celui ci-dessous (lien vers le document fictif ici). REMARQUE : il ne s’agit *pas* d’un véritable PRD Uber – c’est un exemple représentatif et fictif basé sur un scénario plausible.

Même une fonctionnalité extrêmement simple comme celle détaillée pourrait générer un PRD de plus d’une page ! Comme vous pouvez l’imaginer, des fonctionnalités plus compliquées peuvent finir par générer des PRD beaucoup, beaucoup plus longs que l’exemple discuté ici.

Résumé : réflexions finales sur le PRD

Ce que nous avons passé en revue ci-dessus est un instantané représentatif de ce à quoi ressemble un PRD aujourd’hui.

Comme mentionné, il s’agit d’un échantillon représentatif, mais qui devrait donner une idée directionnellement précise de ce à quoi un PRD pourrait ressembler. Ne soyez pas surpris cependant si vous voyez différents formats là-bas ou différents types de contenu inclus (par exemple, une section d’estimations de travail d’un chef d’ingénierie sur le temps qu’il faudra pour construire, etc.) Par exemple, voici un excellent modèle de PRD mis en place par Kevin Yien, un chef de produit chez Square.

Enfin, les plateformes de communication modernes et les outils de productivité comme Slack, Google Docs, Notion, Quip, Office Online, Dropbox Paper, Asana, auront un impact significatif sur l’évolution des PRD dans les décennies à venir. Déjà, nous avons vu les PRD évoluer pour devenir des documents  » vivants  » qui étiquettent les contributeurs clés, sollicitent des commentaires et des réactions en ligne et intègrent des données supplémentaires (par exemple, des tableaux, des captures d’écran, etc.).

Cependant, tout cela étant dit, une chose essentielle ne changera pas : la nécessité d’un type de document produit pour aligner les parties prenantes, servir de schéma directeur de haut niveau et traduire la vision en exigences concrètes du produit.

.