Décider de réaliser une fonctionnalité ou non : une affaire de risque

Christopher Parola
Apr 17, 2018 · 4 min read

Alors, on la fait cette feature ?

Qu’il s’agisse d’un gros sujet ou d’une “petite fonctionnalité”, le Product Manager doit toujours se poser cette question : « est-ce que ça vaut le coup de le faire ? ». Cette question très saine permet de limiter son gaspillage tout en travaillant sur les sujets à plus gros impacts.

Comment répondre à cette question ?

Tout est une question de gestion du risque grâce à des éléments de preuve. Chaque réalisation présente le risque fondamental de gâcher du temps de l’équipe si la fonctionnalité ne donne pas les résultats espérés (que ce soit en terme d’usage ou de business) : l’objectif de l’équipe est donc de minimiser ce risque.

Minimiser le risque avant de se lancer

Pour minimiser ce risque, à la manière d’une équipe de recherche, on va lister les hypothèses qui nous font penser qu’on va avoir un impact. Dans le cas d’une petite fonctionnalité, pas besoin d’en faire des tonnes : un simple slide regroupant « hypothèse — preuves- mesure — conclusion » fonctionne parfaitement bien. J’utilise une adaptation du Experiment Report de LeanStack et du Hypothesis Driven Development de ThoughtWorks, que je présenterais dans un prochain article.

Experiment Report — Ash Maurya — LEANSTACK

Dans le cas d’un nouveau produit ou service, on peut sortir l’artillerie lourde avec notamment le Lean Canvas d’Ash Maurya. Passé cette étape, on doit être collectivement d’accord sur ce que l’on ne sait pas : il est temps de se mettre au travail, enfiler sa blouse et partir à la recherche de preuves.

Avant de poursuivre, une petite vérification s’impose : imaginons que toutes nos hypothèses se vérifient, dans le meilleur des cas quelles peuvent-être nos attentes ? Cette petite vérification peut nous faire économiser un temps précieux, car certaines idées qui semblent bonnes sur le papier peuvent avoir un très faible impact.

La matière à notre disposition sur le sujet est souvent déjà riche. Par exemple, MeilleursAgents et ses 10 années d’existence nous donne accès à une multitude d’informations quantitatives et qualitatives.

Si ces preuves ne sont pas suffisantes ou spécifiques, on va continuer de creuser pour minimiser le risque : tests qualitatifs sur l’existant ou des prototypes, questionnaires en ligne, discussions avec nos utilisateurs…

A-t-on un jour assez de preuves ?

Vous allez me détester mais j’ai la même conviction que Rob Fitzpatrick dans son article Good Enough ; ça dépend. Même lorsque l’on est CERTAIN de nos recherches, tant que le produit n’est pas entre les mains de nos utilisateurs, on ne sait pas ce qu’il va se passer.

Cela a deux conséquences :

  1. On n’est jamais sûr du succès à 100%
  2. Le corollaire : on n’est jamais sûr de l’échec à 100%

C’est une des compétences du Product Manager d’apprécier le moment où on peut arrêter de chercher et se lancer dans la réalisation ou non.

Dans certains cas, à la fin de la phase de recherche, l’équipe n’a toujours aucune preuve permettant de minimiser le risque. Elle n’a peut être pas trouvé d’autres hypothèses permettant d’avoir un bon impact avec un risque moindre. A ce moment, la discussion suivante arrive régulièrement : « Ok, la phase de recherche n’a pas démontré le besoin chez l’utilisateur de tel nouveau produit, mais est-ce que ça veut dire qu’il ne va pas s’en servir une fois qu’il l’aura entre les mains ?». J’ai pendant des années eu un avis très tranché sur la question : non, il ne va pas s’en servir.

Mais avec le recul, je pense que le rôle du Product Manager est d’éclairer la décision finale, ce qui est fait par les recherches. On peut donc tout à fait poursuivre le sujet, du moment que l’on est conscient que notre risque sur l’adoption du produit est maximal. On prend alors une décision basée sur une conviction qui n’est pas éclairée par des données : décision risquée mais pas nécessairement vouée à l’échec.

Consciente de ce risque, l’équipe pourra travailler à la réalisation du produit de manière à le livrer au plus tôt pour minimiser le gâchis lié à un échec potentiel, tout en apprenant un maximum de cette réalisation.

La checklist pour bien traiter les idées de fonctionnalités :

  1. Lister toutes les hypothèses (par exemple avec une Business User Story dans le cadre d’une fonctionnalité ou Lean Canvas dans le cadre d’un produit)
  2. Vérifier que dans le meilleur des cas, l’impact soit suffisant pour justifier le travail
  3. Rassembler un maximum d’éléments permettant de minimiser le risque en piochant parmi les données existantes et en collectant de nouvelles données
  4. Accepter qu’on n’aura jamais une certitude à 100% : ce qui compte, c’est d’être conscient du niveau de risque que l’on prend

Si vous tentez de suivre ces étapes la prochaines fois que l’on vous demande de réaliser une fonctionnalité, dites moi ce que ça donne pour vous !

MeilleursAgents Engineering

MeilleursAgents Engineering Teams (Product, Web & Data Teams)

Christopher Parola

Written by

VP Product @MeilleursAgents. Product enthusiastic. Former-CEO of elCurator. Speaker on PM events.

MeilleursAgents Engineering

MeilleursAgents Engineering Teams (Product, Web & Data Teams)