• Point de départ : le parcours utilisateur
  • Commencer par le problème, pas par la solution
  • Poser des hypothèses de bénéfices
• La User Story Map comme scalpel
• Le PRD : Un contrat de compréhension partagée
• Sources

Dans notre précédent article, nous parlions de priorisation des opportunités pour constituer une roadmap satisfaisante aux yeux de la direction. Nous avons évoqué, sans développer, une étape cruciale : l’affinage des opportunités, grâce à laquelle nous pourrons déterminer quelles hypothèses traiter.

Cette étape est le pont entre les opportunités sur la roadmap et le PRD à partir duquel nous allons traiter les besoins des utilisateurs.

§Point de départ : le parcours utilisateur

Dans un article un peu plus ancien, nous avons déjà étudié la Customer Journey Map (CJM) et le User Story Mapping (USM), grâce auxquels nous pouvons visualiser le terrain. Aujourd’hui, voyons comment transformer ces explorations en un document actionnable : un PRD qui a du sens.

§Commencer par le problème, pas par la solution

La règle d’or est simple : Les utilisateurs ne se soucient pas de notre solution. Ils se soucient de leurs problèmes. « Pour eux rien ne compte que leur propre satisfaction, comme le dit Mises*, l’objectif de n’importe quelle action est toujours le soulagement d’une gêne éprouvée. »*

Avant de rédiger la moindre spécification, notre PRD doit donc ancrer le contexte : la gêne à soulager. Pour cela, la Customer Journey Map permet d’identifier précisément les points de friction : où l’utilisateur se retrouve-t-il coincé, où abandonne-t-il ?

Comme nous l’avions vu, nous construisons le parcours global au travers des services de l’entreprise, puis nous identifions des lacunes, les endroits où le client est visiblement laissé à lui-même… Et c’est là que nous devons creuser.

À partir de là, notre PRD ne pourra pas commencer par « Nous allons créer un bouton X », mais par « L’utilisateur perd 10 minutes à remplir ce formulaire, ce qui génère 30% d’abandon. »

§Poser des hypothèses de bénéfices

La valeur d’une fonctionnalité n’est pas intrinsèque ; elle est subjective et dépend du bénéfice perçu par l’utilisateur, elle « devient un moyen lorsque la raison de l’homme envisage de l’employer pour atteindre une certaine fin » (Mises). Par conséquent, nous ne listons pas des fonctionnalités comme « Le système doit envoyer une notification. », mais des hypothèses de bénéfices ; nous exprimons le résultat attendu. « En notifiant l’utilisateur en temps réel, nous lui faisons gagner du temps et réduisons le risque d’erreur de saisie. »

Nous retrouvons des expressions simples : « gain de temps », « réduction de risque », « confort », etc. Elles permettent de clarifier le gain qu’apportera notre opportunité. Et si nous ne savons pas l’exprimer, nous devrions nous demander : apporte-t-elle réellement de la valeur ? Le cas échéant, il faudra revenir sur notre Customer Journey Map et approfondir notre analyse du parcours, ou bien explorer d’autres lacunes.

§La User Story Map comme scalpel

Une fois la gêne identifiée, la User Story Map de Jeff Patton devient notre meilleure allié pour la rédaction du PRD. Elle nous aide à « trancher » le problème.

Le piège que doit éviter le Product Owner est de vouloir tout mettre dans la première version. L’USM nous permet de découper suivant deux axes :

1. Par profils d’utilisateurs : Est-ce que ce besoin est le même pour un administrateur, pour un vendeur, ou pour un utilisateur final ? Nous devons donc avoir identifié en amont quels sont les profils types d’utilisateurs de notre produit.
2. Par étapes du parcours : Quelle est l’action minimale viable pour valider notre hypothèse ? Le parcours peut être affiné en listant chacune des tâches que l’utilisateur sera amené à réaliser suivant son profil. Nous chercherons ensuite à déterminer quelles actions sont essentielles. Par exemple, nous pouvons nous demander « qu’est-ce que l’utilisateur va faire s’il doit agir dans l’urgence ? »

Le User Story Map nous aide ainsi à verbaliser chaque action de chaque personne, et à formaliser ces informations dans une structure claire et facile à appréhender. Nous pouvons également identifier où exactement se trouvent les leviers sur lesquels nous pouvons agir, ou du moins par où commencer.

Personnellement, il m’est arrivé de pousser jusqu’à représenter le parcours à traiter sous la forme d’un diagramme d’activité, ou de cas d’utilisation : j’ai pu représenter visuellement le cheminement de notre utilisateur, et identifier clairement à la suite où l’utilisateur bloque. J’ai tout de même noté que dans la version finale de notre PRD, le diagramme à proprement parler devient une lourdeur plus qu’un gain : seul le problème que nous voulons traiter reste.

Néanmoins, cela permet d’affiner la compréhension du besoin au fur et à mesure des discussions avec les développeurs et dans les échanges avec les parties prenantes (clients ou commerciaux). Il peut ainsi revenir si nous sommes amenés à remettre le PRD sur le métier.

§Le PRD : Un contrat de compréhension partagée

Comme le souligne Jeff Patton, « Le véritable but de l’utilisation des récits est la compréhension partagée. » Notre PRD est le contrat de confiance qui scelle cette compréhension partagée.

Un PRD efficace pour un Product Owner junior devrait tenir sur deux pages et répondre à :

• Le Problème : (Issu du CJM) - Pourquoi on s’en occupe ?
• L’Hypothèse : (Le bénéfice) - Qu’est-ce qu’on espère gagner ?
• Le Parcours : (Issu de l’USM) - Quelles sont les étapes clés pour l’utilisateur ?
• Les Indicateurs : Comment saura-t-on que l’hypothèse est validée ?

Ainsi, nous ne rédigeons pas pour documenter, mais pour aligner les parties prenantes et les développeurs. Et la Customer Journey Map permet d’identifier où se trouvent nos leviers, la User Story Map de trouver le pourquoi, sans se précipiter sur le comment.

L’essentiel n’est pas de tout livrer, mais de livrer l’essentiel.

§Sources

• L’Action Humaine, de Ludwig von Mises
• Inspired : How to Create Tech Products Customers Love, de Marty Cagan
• User Story Mapping: Discover the Whole Story, Build the Right Product, de Jeff Patton