• Première itération du PRD : le MVP
• Le besoin comme contexte du PRD
• Le pivot : le périmètre
  • Les objectifs que nous visons
  • Savoir quand nous atteignons ces objectifs
  • L’importance de savoir dire non
• Notre proposition
• Document vivant
• Conclusion
• Ressources

Comme nous l’avons vu dans notre précédent article, notre PRD commence par le Pitch, qui va faire office d’accroche : il permet au lecture de comprendre de quoi nous allons parler en quelques mots.

Mais au-delà de l’accroche se trouve le PRD à proprement parler. Nous l’avons déjà évoqué à plusieurs occasions, il a pour vocation de créer le lien entre le besoin de l’utilisateur, ou la gêne du consommateur, et notre proposition de valeur : ce que nous envisageons d’implementer. Au moment de la rédaction du PRD, nous ne savons pas encore quelle forme prendra la solution, mais nous devons tout de même poser un cadre pour que les développeurs puissent avancer…

Au minimum, de quoi expérimenter, et de quoi concevoir un MVP.

§Première itération du PRD : le MVP

Comme nous l’avons déjà vu, au stade du PRD, nous n’avons pas encore de solution concrète. Pour la première implémentation, l’itération que nous devons viser et décrire, c’est le MVP, ou Minimum Viable Product.

Pour Jeff Patton, c’est « la plus petite version d’un produit qui permet d’atteindre avec succès les résultats souhaités » et « la plus petite chose que vous puissiez créer ou faire pour prouver ou infirmer une hypothèse ». Tourné vers la satisfaction utilisateur, Dan Olsen complète en précisant que « c’est la quantité minimale de fonctionnalités que votre client cible considère comme viable, c’est-à-dire qui apporte suffisamment de valeur ».

Concrètement, c’est la version initiale qui répond à la gêne la plus importante de l’utilisateur, un point central que nous avons détaillé dans le second article de cette série.

Le MVP est l’aboutissement de l’exploration initiale. Avant lui, la phase de Discovery s’appuie sur des démonstrateurs pour « apprendre vite et à moindre coût » (Marty Cagan), via un version exploratoire qui n’a pas vocation à être conservée en production. Nous aurons par exemple des « Proof of Concept » ou des « Spikes » pour mener des expérimentations techniques plus ou moins abouties, ou encore des maquettes ou prototypes permettant d’évaluer l’expérience utilisateurs.

Cette approche s’intègre parfaitement dans une logique de sprint : une boucle itérative où l’on construit pour apprendre, on mesure les résultats, et on ajuste le tir. Ces notions de démonstrateurs et de sprints font partie d’un volet entier sur les méthodes agiles dont nous aurons l’occasion de parler, mais je ne voudrait pas que nous nous dispersions de trop ici.

Ce qui nous importe ici, c’est que ces jalons intermédiaires, jusqu’au MVP, nous permettent de contrôler en continu l’adéquation de notre proposition avec la gêne à résoudre.

§Le besoin comme contexte du PRD

Comme nous l’avons déjà vu, un PRD doit définir avant toute chose l’espace du problème. En fait, cela correspond au positionnement sur le marché, que nous avons déjà étudié par le passé : les problèmes que nous voulons traiter sont ceux des consommateurs, nos clients, et lorsque nous nous sommes intéressé à la définition du marché, nous les avons déjà vu comme étant les acteurs du marché qui vont acheter notre Produit… S’il répond à leur besoin.

Mises nous montre même que « Le capitaine, c’est le consommateur. » C’est lui qui définir « ce qui doit être produit. » : « Profit et perte sont les instruments à travers lesquels les consommateurs exercent leur suprématie sur le marché ». Les consommateurs sont les arbitres du marché, qui vont déterminer quelle est la bonne solution pour répondre à leur besoin.

Nous devons donc clairement définir quel est le profil de l’utilisateur de notre produit avant de parler de sa gêne, car lorsque nous en sommes à la rédaction de notre PRD, notre produit est déjà calibré pour des profils d’utilisateur spécifiques. Et comme le précise Marty Cagan, il doit être « très clair pour l’équipe produit qui est le principal bénéficiaire prévu de ce travail ».

De mon expérience, lorsque le profil de l’utilisateur est déjà bien cerné, et qu’il s’agit d’un produit déjà utilisé, il est fort probable que des problèmes similaires remontent : ils découlent d’usages similaires sur le même produit (le notre). La création de nouveaux produits est un sujet encore neuf pour moi, que j’explorerai en dehors de cet article.

Pour le moment, nous retrouvons les informations du contexte de notre PRD comme suit.

• Le marché ciblé, qui est le domaine dans lequel notre produit se positionne.
• Sur ce marché, nous ciblons des consommateurs spécifiques, qui sont les personnes utilisant notre produit.
• Enfin, nous écrivons ce PRD pour traiter un problème spécifique.

§Le pivot : le périmètre

§Les objectifs que nous visons

« la première question doit correspondre à un ou plusieurs des objectifs assignés à votre équipe ». Par cette affirmation, Marty Cagan nous rappelle que notre produit évolue dans le cadre plus général de la stratégie de l’entreprise, dont nous avons déjà parlé dans un précédent article. Cet objectif business permet de rappeler ce cadre.

Dans les modes de fonctionnement que j’ai eu l’occasion de pratiquer, l’équipe produit se voit assigner des objectifs par la direction ou le management (dans le meilleur des mondes, l’équipe est impliquée dans la définition de ces objectifs, mais ce n’est pas toujours le cas).

Bien entendu, si nous nous sommes donnés la peine de comprendre le besoin de l’utilisateur, c’est parce qu’il reste la motivation principale de notre proposition de valeur. Les autres objectifs traduisent donc l’ambition de l’équipe, quant à la résolution de ce problème. La définition de ces objectifs dépend grandement du problème en question, mais nous parlons souvent

• d’améliorer l’acquisition sur une fonctionnalité donnée (ou le produit), car notre solution va résoudre un problème d’accès à cette fonctionnalité, ou bien
• d’améliorer le taux d’utilisateurs allant jusqu’au bout dans l’utilisation d’un service donné, car celui-ci sera plus accessible, plus ergonomique, etc.

§Savoir quand nous atteignons ces objectifs

Une fois que nous avons nos objectifs, la difficulté est de déterminer des indicateurs quantitatifs, permettant de mesurer notre réussite.

Sur la partie business, Teresa Torres nous explique que les indicateurs sont « basés sur les données du marché et la situation économique » et donnent de la visibilité sur l’état à venir du marché.

Les indicateurs des objectifs produits concernent « la valeur apportée aux utilisateurs, basés sur des indicateurs de l’utilisation de la solution ». Ils sont sensiblement plus simple à cerner, et à mesurer, surtout pour une application web : nous disposons de toute une batterie d’outils pour traquer les clics dans les formulaires et sur les liens de notre site web, et nous pouvons également suivre les logs d’activité de l’application, qui reportent notamment les erreurs rencontrés par les utilisateurs. Ces données sont précieuses pour valider notre hypothèse sur l’usage du produit, le besoin de l’utilisateur, et in fine sur la pertinence de notre solution.

Enfin, Jeff Patton nous rappelle que la mesure ultime d’un objectif n’est pas la fonctionnalité ou même notre application, mais l’impact sur l’utilisateur :

« Nous ne mesurons pas le résultat par le nombre de fonctionnalités livrées […] Nous mesurons ce que les gens font réellement différemment pour atteindre leurs objectifs en conséquence de ce que vous avez construit. »

§L’importance de savoir dire non

Les objectifs et indicateurs de performance informent sur ce que nous voulons faire, ou le contenu du PRD. Cependant, notre produit et ses fonctionnalités on besoin d’un cadre bien délimité. Ce périmètre indique ce que nous prévoyons de faire, mais aussi ce que nous ne feront pas. Nous parlons également de scope.

Comme l’explique Dan Olsen dans The Lean Product Playbook, la stratégie, c’est avant tout décider ce qu’on ne va pas faire. Le PRD doit marquer un pivot clair entre toutes les solutions imaginables et celle que nous choisissons de valider.

Définir explicitement ce qui est hors périmètre permet d’éviter à notre produit de se disperser sur des fonctionnalités qui n’apporterons que peu de valeur, ou bien dont le coût d’intégration serait astronomique, … ou pire ; les deux à la fois. Nous avons notamment déjà parlé du « Cost of Delay » de Melissa Perri dans mon précédent article « De la vision au PRD ». Ce sont des arguments que le Product Owner peut employer pour appuyer le périmètre du PRD. Il est également essentiel d’avoir collaboré avec les équipes techniques, car ce coût se retrouve généralement dans le temps de développement qui serait requis pour aller au-délà de ce cadre…

§Notre proposition

Une fois le besoin et le périmètre clairement établis, nous allons introduire notre proposition de solution. Dès le début, il est important d’impliquer l’équipe technique dans l’exercice, car d’une part, ce sont eux qui vont réaliser le travail (ce sont les principaux concernés) et d’autre part, ils sont les mieux placés pour comprendre les enjeux de notre solutions pour le restant de l’application.

J’ai déjà eu l’occasion de développer l’importance de cette collaboration lorsque j’ai partagé mon retour sur les enjeux techniques du Product Owner. Dans le cadre du PRD, ce travail permet d’affiner notre solution, au fil des expérimentations et des itérations sur le produit.

Grâce à cette collaboration, la description de notre proposition fournira les contraintes fonctionnels, techniques, et de designs héritées de son fonctionnement actuel : son architecture technique, les choix d’ergonomie, et son fonctionnement actuel. Par exemple, introduire une nouvelle mécanique de récupération de compte peut induire un changement dans les données utilisateur à conserver et traiter (ce qui implique de bien les sécuriser) et le design d’une nouvelle page, avec des champs cachés d’un style qui n’était pas encore prévu.

Nous établissons ainsi le lien avec notre premier point sur le MVP : nous définissons et construisons notre solution en parallèle.

§Document vivant

Si nous parlons d’affiner notre définition du produit au fil de son intégration, cela signifie également que nous mettons régulièrement à jour notre PRD. Mais celà concerne également le périmètre du besoin.

Comme le souligne Teresa Torres, le travail de « Discovery » et de « Delivery » doivent mener des existences parallèles et interactives : nous affinons notre compréhension de la gêne des consommateurs au fil des retours qu’ils nous fournissent, ce qui nous permet de déterminer comment faire évoluer notre solution (le rôle de la Discovery), et en parallèle, nous appliquons les modifications sur le produit (le rôle de la Delivery).

Pour cela, nous devons entretenir des échanges réguliers avec les utilisateurs de notre produit (certains auteurs parlent d’échanges hebdomadaires). Si de nouvelles données arrivent pendant que les développeurs codent, le PRD doit refléter cette nouvelle connaissance. C’est l’essence même de l’agilité : l’optimisation volontaire basée sur la connaissance acquise.

§Conclusion

Un PRD efficace est un contrat de confiance. Il ne dit pas aux ingénieurs comment coder (ils le savent mieux que nous), mais il leur donne le contexte nécessaire sur l’utilisateur, son besoin et son usage futur du produit.

En clarifiant la proposition de valeur et en acceptant l’incertitude par l’itération, nous réduisons les frictions au sein de l’équipe et maximisons les chances de créer un produit que les utilisateurs aimeront vraiment.

§Ressources

• L’Action Humaine, Ludwig von Mises
• INSPIRED, Marty Cagan
• Escaping the Build Trap, Melissa Perri
• The Lean Product Playbook, Dan Olsen
• User Story Mapping, Jeff Patton
• Continuous Discovery Habits, Teresa Torres