Qu'est-ce qu'un document d'exigences produit ?
Un bon document d'exigences produit identifie les objectifs de tout nouveau produit, service ou fonctionnalité; il décrit avec précision le produit que votre équipe va construire.
Un document d'exigences produit simple et efficace doit clairement définir les objectifs du produit, les utilisateurs cibles et l'utilisation prévue.
It is the foundation that any agile product team needs to ensure all stakeholders involved are aligned and the roadmap for the product team is clear. The PRD will be the most referenced resource throughout your product build.
Qu'est-ce qui fait un document d'exigences produit efficace ?
Les documents d'exigences produit n'ont pas besoin de faire des pages et des pages. Soyons francs, les gens lisent en diagonale, ils repèrent les mots-clés et comprennent l'essentiel. Pour créer un document d'exigences produit indolore, il est essentiel de garder les choses aussi brèves que possible, concises et agréables à l'œil - n'ayez pas peur d'utiliser des visuels pour le support.
→ Par exemple, chez Slite, nous utilisons des croquis pour définir les fonctionnalités et les interactions.
Even if you manage to create an outstanding product requirements document, it doesn’t guarantee that your product build will be a success, but it will certainly give it the best possible starting blocks.
Un guide complet du document d'exigences produit
Comment un PRD peut-il aider une équipe de développement de produits ?
Les équipes de développement de produits sont de loin l'équipe la plus touchée par un document d'exigences produit. Ce sont elles qui se référeront le plus souvent aux plans de projet et qui devront connaître le document comme leur poche pour s'assurer qu'elles travaillent en collaboration et efficacement.
Le PRD jouera un rôle plus modeste dans la stratégie produit, la vision et la feuille de route produit plus larges. C'est l'une des ressources essentielles, en dehors des talents, qui permet une excellente gestion de produit.
Cependant, cela ne s'arrête pas à l'équipe de développement. Le marketing, les ventes, le développement commercial, le support et d'autres équipes devront se référer au modèle pour comprendre pleinement ce qui va arriver et le calendrier. Si toutes les équipes sont d'accord avec le document, elles planifieront mieux dans leurs domaines afin de pouvoir soutenir le nouveau produit du mieux possible lorsqu'il sera prêt.
Ce que le PRD signifie pour un chef de produit
En tant que chef de produit (PM), vous devriez être le principal contributeur à toute documentation technique comme un modèle de spécifications de produit ou un PRD, mais cela ne signifie pas que vous devez le faire seul. C'est à vous - en tant que PM - de trouver les meilleures ressources dans votre équipe pour vous aider à créer différentes parties du PRD :
- Utilisez un designer pour les wireframes et les maquettes
- Embauchez un marketeur pour les personas et les user stories
- Le chef de produit est responsable de la gestion de l'ensemble du processus de définition des exigences du produit.
Si ce processus est bien géré, les chefs de produit doivent utiliser ce document comme une ressource pour eux-mêmes tout au long du processus et comme une ressource pour les autres parties prenantes à consulter continuellement.
Quelle est la différence entre un PRD et un MRD ?
Les gens confondent souvent ce qu'est un PRD et ce qu'est un MRD. Ils sont différents mais ont tendance à aller de pair. Un document d'exigences du marché doit être créé avant le document d'exigences du produit.
En bref, un MRD est une étude qui identifie les besoins et les opportunités du marché avec un produit de votre entreprise. Le PRD identifie le produit qui peut être construit pour saisir l'opportunité.
Que doit contenir un PRD ?
Un bon modèle de départ de PRD sera différent selon votre entreprise et votre équipe. Cependant, la plupart des documents d'exigences produit doivent inclure :
- Buts et objectifs
- Principales parties prenantes
- Personas d'utilisateurs & Histoires
- Détails de la version
- Conception et wireframes
- Risques
- Feuille de route et interactions futures
Encore une fois, il ne s'agit que d'un aperçu général de la façon dont un PRD peut apparaître. Vous pouvez juger nécessaire d'inclure tous les éléments ci-dessus dans votre document, ou vous pouvez n'inclure que les éléments que vous jugez pertinents pour votre processus de développement de produit.
1. Buts et objectifs
Cette partie est le « pourquoi » de la construction de ce document de produit en premier lieu. Il fournit le contexte autour du cycle de vie du produit et la façon dont il s'aligne sur la mission et la vision plus larges de votre entreprise / produit.
Essayez de clarifier les problèmes que ce produit est conçu pour résoudre. Cela permettra à votre équipe de développement de créer un produit qui résout son objectif et le fait d'une manière agréable pour l'utilisateur final.
2. Principales parties prenantes
Une partie simple mais souvent négligée du PRD est l'identification des principales parties prenantes dans le processus de feuille de route du produit. Cela doit inclure - mais ne se limite pas à - le chef de produit, les concepteurs internes ou externes, les développeurs de produits, le propriétaire du document et tous les rapports directs ou les postes de direction qui sont impliqués.
Tous ceux qui espèrent participer à votre projet doivent savoir vers qui se tourner et pour quoi faire. Une propriété claire est essentielle.
3. Personas et histoires d'utilisateurs
Ces personas sont essentiels dans le processus de développement et le résultat d'un produit. Chaque persona que vous créez doit agir comme une contribution à l'expérience du produit et doit avoir un objectif ou un défi particulier pour aider votre produit à atteindre son objectif final. Ils aident à fournir les cas d'utilisation du produit.
De nombreux nouveaux projets de produits ont tendance à mal tourner ici ; ils tournent autour de personas construits trop similaires les uns aux autres, ne changeant que le sexe ou l'âge. Concentrez-vous sur vos personas d'utilisateurs. Qui sont-ils ? Quel âge ont-ils ? À quel sexe s'identifient-ils ? Quelle est leur profession ? D'où viennent-ils ? Quel est leur nom ? Et surtout, quel besoin spécifique votre produit résout-il ?
Assurez-vous que tous ces facteurs sont différents mais précis par rapport aux données dont vous disposez. Utilisez Google Analytics, les médias sociaux et d'autres données d'audience pour vous aider à les construire.
Qu'est-ce qu'un exemple de persona PRD ?
Nommer les personas aidera une équipe de développement de produits à concevoir pour quelqu'un, pas pour quelque chose. Construisez suffisamment de personas pour que l'équipe puisse s'identifier et comprendre, ce faisant, elle créera un produit final qui correspond aux besoins identifiés de quelqu'un - et donc du marché.
Soutenez ces personas avec des user stories. Voici un exemple de document d'exigences de persona : « En tant que Cindy, quelqu'un qui fait XYZ, j'ai besoin de ce produit pour XYZ. » En utilisant ces besoins des clients comme support lors de la conception d'un nouveau produit, votre équipe de conception créera quelque chose qui reste fidèle à son objectif et à son adéquation au marché.
Ces histoires doivent principalement se concentrer sur une fonctionnalité particulière du produit. Au lieu de ressembler à une proposition de projet, le persona doit répondre à un point sensible, identifié dans le MRD, et à la valeur que la fonctionnalité apportera.
4. Notes de version
Elles sont si importantes, non seulement pour aider une équipe de produit à s'assurer que la feuille de route du produit reste sur la bonne voie, mais aussi pour les autres équipes impliquées. Elles aideront les gens à gérer leur charge de travail afin qu'ils soient en mesure de soutenir le produit au moment où ils en ont besoin.
Les notes de version du produit doivent inclure les noms des étapes importantes, les fonctionnalités, les correctifs et les améliorations à venir.
5. Conception et wireframes
Les conceptions visuelles et les wireframes sont indispensables pour tout document d'exigences produit réussi. Ils aident les ingénieurs à comprendre la vision de la conception et à répondre aux points sensibles des personas d'utilisateurs.
En introduisant des wireframes à ce stade, vous êtes en mesure d'identifier les problèmes et de trouver des solutions qui n'auraient pas été apparentes sans une aide visuelle. Ne considérez pas la conception à ce stade comme une conception graphique. Votre wireframe doit fonctionner comme un plan ou une carte de base pour l'endroit où vos fonctionnalités principales s'intégreront dans une page et quelles pages doivent être en premier lieu.
Les wireframes n'ont pas besoin d'être quelque chose de beau, mais ils doivent donner à vos ingénieurs et aux autres parties prenantes une vision claire de la façon dont le produit sera utilisé et de la façon dont un utilisateur naviguera dans le produit.
6. Risques
Le don de la rétrospective est une chose si puissante. Nous ne savons pas si un produit réussira ou échouera, ni tous les obstacles que nous pourrons rencontrer tout au long du processus de développement. Ce que nous pouvons faire, c'est essayer d'identifier autant de risques que nous pouvons rencontrer en cours de route.
Un risque peut être n'importe quoi, d'un calendrier incertain à un nouveau code ou talent, une intégration particulière ou une ressource externe nécessaire. En identifiant les risques au début du document de produit, l'équipe de produit peut surmonter tous les défis les plus importants dès que possible et préparer un plan B pour toute situation.
7. Feuille de route et itérations futures
Un produit n'est jamais vraiment une œuvre finie. Il doit être dans un état de flux constant, apprenant de son utilisation, s'adaptant et évoluant vers de nouvelles technologies ou de nouveaux besoins des consommateurs. La première itération de votre produit doit être exactement cela, une première ébauche.
En tant que propriétaire ou chef de produit, demandez-vous quelles exigences fonctionnelles sont essentielles pour le MVP et ce qui peut attendre la deuxième ou la troisième itération. Envisagez même ce qu'il est préférable de reporter jusqu'à une deuxième ou une troisième itération, et qui pourrait être défendu avec des données utilisateur à l'appui.
Essayez de planifier la feuille de route future de votre produit pour que les membres de l'équipe de conception et d'ingénierie comprennent quelles bases doivent être posées maintenant pour rendre ces versions possibles. Tenez compte de l'objectif de tout votre travail futur, du délai dans lequel vous prévoyez qu'il sera livré et de sa priorité par rapport aux autres fonctionnalités.
Exemple de modèle de document d'exigences produit
La façon de rédiger un document d'exigences produit peut être une tâche ardue, et il est difficile de savoir par où commencer. C'est une bonne idée de commencer avec un modèle de document d'exigences produit pour vous aider à démarrer votre processus.
Ci-dessous, nous vous fournissons un exemple de PRD que vous pouvez utiliser et adapter à vos propres besoins.
Comment rédiger un document d'exigences produit ?
Étape 1 : Étudiez
Un PRD (qui signifie « document d'exigences produit ») doit se concentrer sur le problème que votre produit résout. Recherchez les besoins et les désirs des clients, et ce qu'ils paient actuellement pour des produits similaires.
Comment les concurrents abordent-ils le problème ? Comment pouvez-vous mieux répondre aux besoins des clients ?
Parlez à vos experts en marketing, en vente et en technique des avantages et des inconvénients des technologies disponibles. Toutes ces recherches vous aideront à diriger votre équipe de développement de produits avec confiance et efficacité.
Étape 2 : Définir les valeurs fondamentales du produit
Votre modèle de document d'exigences du produit doit expliquer clairement comment le produit s'aligne sur les objectifs généraux et la stratégie de produit de votre entreprise. Présentez la proposition de valeur de votre entreprise comme un argumentaire éclair. Assurez-vous que tout le monde sait ce qu'une mise en œuvre réussie du produit doit apporter pendant le processus de conception et de mise en œuvre.
Étape 3 : Créer une philosophie de produit
La définition des principes du produit aide votre équipe à le développer. Voici quelques exemples de PRD :
- Sûr
- Fiable
- Intuitif
Cet exercice de proposition de valeur permet d'affiner les principes de votre produit et guide votre équipe lorsqu'elle définit les tâches des utilisateurs et les fonctionnalités du produit.
Étape 4 : Identifier les profils, les objectifs et les tâches des utilisateurs
Un exercice ciblé sur votre profil d'utilisateur, vos objectifs et vos tâches vous aide à construire votre produit efficacement. Par exemple, les PRD doivent indiquer à qui il s'adresse, quels sont ses objectifs de produit et comment il l'utilisera.
Créer un profil d'utilisateur
Votre document de produit doit identifier l'utilisateur principal du produit le plus important pour votre entreprise en termes de ventes. Lorsque vous envisagez de nouvelles fonctionnalités, demandez à votre équipe comment cet utilisateur réagirait et utiliserait cette fonctionnalité. Concentrez-vous sur les besoins, les désirs, les habitudes et les attitudes de la majorité de vos utilisateurs principaux plutôt que d'essayer de satisfaire tous les clients potentiels.
Définir les objectifs de l'utilisateur
Un document d'exigences du produit doit identifier ce que les utilisateurs veulent accomplir. Les utilisateurs ont souvent du mal à expliquer exactement ce qu'ils veulent. Identifiez les besoins et les obstacles de l'utilisateur afin que les concepteurs et les ingénieurs puissent trouver la meilleure solution.
Définir les tâches de l'utilisateur
Lorsque vous élaborez votre PRD, créez des tâches conviviales avec votre équipe. Explorez les moyens d'atteindre rapidement et facilement les objectifs de l'utilisateur. Ensuite, évaluez les meilleures alternatives.
Étape 5 : Énumérer les fonctionnalités de votre produit
L'essentiel de votre PRD décrira la fonctionnalité et les contraintes des fonctionnalités imposées à la conception du produit. La fonctionnalité du produit est décrite dans les exigences fonctionnelles. Les exigences non fonctionnelles décrivent les limitations de la conception du produit.
Étape 6 : Tester votre concept
Les chefs de produit et les développeurs prennent souvent leur projet de PRD trop au sérieux. Il est trop tard pour apporter des modifications majeures lorsque les commentaires de la version bêta arrivent. Les outils de prototypage modernes facilitent les tests de validation de prototype de produit pour obtenir des commentaires. Les trois types de tests de validation de produit sont les suivants :
- faisabilité
- utilisabilité
- test de concept
Étape 7 : Critères de publication
Votre document d'exigences doit hiérarchiser et classer les exigences et les objectifs de publication comme « incontournables », « très souhaitables » et « agréables à avoir ». Cela vous aide à commercialiser le produit et à suivre l'évolution des exigences.
Établir des mesures de réussite quantifiables telles que :
- Performance
- Fiabilité
- Facilité d'utilisation
- Sécurité
- Capacité de prise en charge
- Évolutivité
- Localisation
- Autres facteurs de produit pertinents
Étape 8 : Réviser votre projet de PRD
Assurez-vous que le développeur comprend le problème du PRD et que l'assurance qualité dispose de suffisamment d'informations pour élaborer un plan de test. Résolvez tous les problèmes soulevés par vos parties prenantes lors de la rédaction de votre PRD.
Étape 9 : Gérer le développement du produit
Lorsqu'un problème lié aux exigences survient, reportez-vous au PRD. S'il n'y a pas de réponse, résolvez et enregistrez la décision. Tout au long du développement et du lancement du produit, votre PRD donne à toute votre équipe une compréhension claire de ce que vous visez.
Les pièges lors de la création d'un document d'exigences du produit
Le processus de test
Lors de votre premier test d'utilisabilité, vous verrez les problèmes qu'ils rencontrent et comment les résoudre. Pour des tests d'utilisabilité efficaces :
- Testez l'utilisabilité avant la mise en œuvre, pas après
- Effectuer plusieurs itérations
- Impliquer les autres parties prenantes
- Concentrez-vous sur les actions de l'utilisateur, pas sur les mots
- Observer les interactions de l'utilisateur avec le produit
Si vous n'avez pas d'ingénieurs en utilisabilité dans votre personnel, engagez une entreprise spécialisée dans les tests d'utilisabilité et ajoutez leur contribution à votre document d'exigences.
Rester axé sur le client
Les clients sont rarement aussi férus de technologie que les créateurs de produits. Par exemple, les documents d'exigences du produit qui semblent intuitifs pour vos concepteurs peuvent être obscurs pour les utilisateurs potentiels. Une mauvaise première impression peut aigrir votre produit sur un client. C'est pourquoi les commentaires des clients pendant le développement sont un élément précieux du processus.
Ne partez pas des solutions
Votre document d'exigences du produit doit spécifier le problème à résoudre, et non la façon dont le produit le résoudra. Une approche basée sur les solutions peut amener vos ingénieurs à faire des hypothèses incorrectes et laisser votre équipe de développement confuse et frustrée.
Pas assez de détails
Votre document de produit doit donner beaucoup de latitude aux ingénieurs et aux concepteurs. Les membres de l'équipe combleront les lacunes du PRD. Prévoyez les problèmes qui surviennent pendant le développement, prévoyez du temps pour les résoudre rapidement et mettez à jour le PRD au besoin.
Trop détaillé
Trop de détails peuvent amener les membres de l'équipe à ne pas lire le PRD. Les produits complexes peuvent avoir besoin de documents de niveau inférieur pour chaque sous-système. Le modèle de PRD makes allowances for complicated projects.
Trop de fonctionnalités
Bien qu'il soit tentant de répondre à tous les besoins des clients, cela peut être contre-productif pour les produits de haute technologie. Les fonctionnalités ajoutées gonflent le produit, ce qui entraîne la confusion des utilisateurs et l'augmentation des coûts de maintenance. Soyez discipliné lorsque vous ajoutez des fonctionnalités à votre document d'exigences du produit.
Axé sur l'ingénierie
Vous pouvez surcharger le chef de produit si votre équipe d'ingénierie est éprise d'une nouvelle technologie. Les règles de gestion de projet vous obligent à écouter les ingénieurs, mais à vous concentrer sur la valeur et à donner des exemples d'exigences que les clients achèteront et que votre entreprise peut construire.
Axé sur le marketing
Un exemple de problème de document d'exigences axé sur le marketing est celui des « promotions », des fonctionnalités spéciales ou des achats supplémentaires en échange de paiements supplémentaires. Les promotions peuvent entraîner la confusion et la frustration des clients. Elles nécessitent également la construction, les tests, la maintenance et la prise en charge de plusieurs versions du produit. Et les clients peuvent découvrir que les nouvelles fonctionnalités ne répondent pas à leurs besoins. Évaluez chaque fonctionnalité proposée et sachez quand vous retirer.
Traçabilité des exigences
Votre PRD doit prendre en charge la traçabilité des exigences et suivre les problèmes, les cas de test, les bogues et les résolutions de problèmes pour chaque exigence. Un outil intégré de gestion des exigences, tel que SLITE, peut clarifier la signification de votre PRD et simplifier considérablement la traçabilité des exigences.
Gérez facilement un PRD et les processus de produit avec Slite
Ce n'est pas parce que vous avez réussi à créer un document d'exigences de produit efficace que votre équipe l'utilisera nécessairement comme point de référence, ou même qu'elle saura où le trouver. Slite est là pour vous aider à gérer les nouveaux processus de produit en gardant votre équipe connectée aux ressources impressionnantes que vous créez :
- Partagez votre PRD et d'autres documentations logicielles en temps réel, avec les membres de votre équipe qui en ont besoin.
- Centralisez les connaissances de votre équipe, plus besoin de passer d'une personne à l'autre pour obtenir des informations.
- Accédez instantanément à une multitude de modèles qui peuvent aider vos processus de produit à exceller.
