Les hypothèses en product discovery

Dans le quotidien d’un Product Manager (PM), les phases de discovery et de delivery se complètent : l’une pour décider quoi développer, l’autre pour développer ce qui a été acté. Et pour savoir vers où emmener son produit, les échanges utilisateurs, la compréhension du marché et du persona user sont essentiels.
La discovery n’est pas pour autant un exercice mené au hasard, au grès de découvertes inattendues, bien au contraire 🔍. Dans notre dernier article sur les meilleures pratiques en discovery, nous vous partagions comme deuxième conseil de formuler des hypothèses à tester. Pour aller plus loin sur le sujet, cet article revient sur les frameworks de formulation d’hypothèses, les erreurs à éviter et les tests à mener pour en maîtriser l’utilisation 🚀.
Si vous avez besoin d’un apprentissage concret des méthodes du Product Management, Join Maestro propose des formations sur toutes les dimensions du rôle, de la product discovery à la delivery en passant par l’alignement. Notre pédagogie, basée sur la pratique, vous équipe pour devenir un excellent Product Manager.

Pourquoi utiliser des hypothèses en product discovery ? 🕵️‍♀️

En product management, une hypothèse est une supposition précise, facilement testable et en lien direct avec le produit. En général, elle est formulée sur le modèle : “nous pensons que…”.
Une bonne hypothèse doit pouvoir être clairement validée ou réfutée par de la donnée ou un MVP (minimum viable product). Son énoncé ne doit donc laisser aucune place à l’interprétation. Surtout, elle doit être utile au produit : l’utilisation d’hypothèses diminue le risque associé au développement produit, en s’assurant de la désirabilité de ce que l’on construit pour le end user. Formuler des hypothèses permet d’éviter des idées préconçues et raccourcis de pensée en identifiant clairement sur quelles fondations (vraies ou fausses) on construit une nouvelle feature ou un nouveau produit.

D’après Laura Klein (PM et auteure de Build Better Products), il en existe de trois natures différentes : une hypothèse peut porter sur le problème que l’on essaie de résoudre, sur la solution potentielle à développer ou bien sur la capacité d’implémentation. Elle donne ainsi l’exemple de Dropbox, pour qui différentes formulations seraient :

• Hypothèse 1, le problème à résoudre : les gens possèdent plusieurs appareils (ordinateur, téléphone, tablette…) et souhaitent accéder aux fichiers téléchargés de manière transverse.
• Hypothèse 2, la solution potentielle : les gens sont prêts à télécharger quelque chose sur leurs appareils et savent que leurs fichiers sont en sécurité dans le cloud.
• Hypothèse 3, la capacité d’implémentation : Dropbox est en mesure de développer cette solution rapidement et de faire en sorte que les gens téléchargeront et utiliseront la solution.

Mais l’exercice de l’hypothèse peut également porter sur d’autres macro catégories, comme les utilisateurs et les bénéfices qu’ils tireront de l’utilisation du produit (Forming Experimental Product Hypotheses de Chris Compston). Fondamentalement, chacune des sections du Business Model ou de la Value Prop (gains, pains, jobs-to-be-done, etc.) se prête à l’exercice.

Parfois, l’hypothèse la plus incertaine (et donc la plus risquée) porte sur le problème qu’on essaie de résoudre, parfois sur la solution la plus adéquate. Dans tous les cas, vous l’aurez compris, formuler des hypothèses claires permet d’orienter derrière la discovery sur les inconnues à plus fort impact sur le succès du produit.

Formuler des hypothèses testables 🔮

Selon Teresa Torres (product leader renommée et auteure de Continuous Discovery Habits), deux activités clés doivent rythmer le quotidien des équipes efficaces en discovery : les entretiens clients et les tests d'hypothèses. Une combinaison qu’elle explique par “les entretiens aident à découvrir des opportunités et les tests d'hypothèses à découvrir des solutions”.

Une hypothèse de type “solution” est structurée autour de quatre éléments indispensables : la capacité produit désirée par l’utilisateur, le user persona associé, le résultat désiré par l’utilisateur et la métrique qui attestera de la véracité de l’hypothèse. Une formulation type sera par exemple :
“ Nous pensons que [cette capacité produit] destinée à [ces utilisateurs] permettra d’[atteindre ce résultat]. Cette hypothèse sera validée lorsque [cette métrique / ce signal du marché] sera vérifié. ” (traduit de Josh Seiden)

Dans la pratique, un résultat est souvent la conséquence de plusieurs conditions vérifiées. Certains parlent d’“Assumption Stack”, c’est-à-dire qu’une hypothèse en implique une ou plusieurs autres. Votre formulation ressemblera probablement plus à :
“ Nous pensons que [Supposition 1] et [Supposition 2] sont vraies. Par conséquent, nous pensons que [cette capacité produit] destinée à [ces utilisateurs] permettra d’[atteindre ce résultat]. Cette hypothèse sera validée lorsque [cette métrique / ce signal du marché] sera vérifié. ”

On reprenant l’exemple de Dropbox, voici à quoi ils auraient pu aboutir pour la formulation de leur hypothèse solution :
“ Nous pensons que [les gens sont prêts à télécharger quelque chose sur leurs appareils] et [les gens savent que leurs fichiers sont en sécurité dans le cloud] sont vrais. Par conséquent, nous pensons que [la synchronisation inter-appareils de fichiers] destinée à [l’ensemble de nos utilisateurs] leur permettra [d’accéder à leurs fichiers depuis n’importe quel appareil, en temps réel]. Cette hypothèse sera validée lorsque [le taux de téléchargement de l’offre cloud sera supérieur à 80% des utilisateurs actifs] sera vérifié. ”

Comment faire émerger ces hypothèses ? Vous pouvez tester plusieurs exercices :

• Exercice 1 : Le premier, recommandé par Laura Klein, consiste à se poser la question “Pour que mon produit réussisse, ___ doit se produire” ou inversement, “Si ___ ne se produit pas, mon produit ne marchera pas”. En reprenant l'exemple de Dropbox, une formulation aurait pu être : "Si les utilisateurs ont peur du cloud, la nouvelle offre cloud de Dropbox ne marchera pas". Catégorisez les idées qui sont sorties selon leur nature (Problème, Solution, Implémentation) et triez-les entre celles qui sont réellement essentielles à la survie du produit et celles qui le sont moins. Réorganisez la première catégorie de l’idée la plus risquée à la moins risquée.
• Exercice 2 : Son conseil rejoint celui de Marc Abraham, Head of Product-Engagement chez ASOS, qui recommande de faire un pre-mortem en listant, en équipe, toutes les raisons pour lesquelles une feature ou un produit ne marcheraient pas. Puis de lister les plus réalistes et probables, comme étant les plus risqués.
• Exercice 3 : Une autre pratique consiste à partir du story mapping ou user journey et formuler à chaque étape ce qui doit être vérifié pour que l’utilisateur passe à l’étape suivante. Les hypothèses peuvent toucher à la désirabilité du produit, sa viabilité économique, sa faisabilité technique voire son caractère éthique (pour en savoir plus sur comment développer un produit responsable, c’est ici !).
• Exercice 4 : Enfin, vous pouvez faire de l’assumption mapping, en listant, en équipe, ce qui doit être vérifié pour attester de la désirabilité du produit, de sa viabilité économique et de sa faisabilité technique. Vous devez ensuite les mapper sur une matrice 2x2 selon leur degré d’importance et le niveau d’information à votre disposition. Les idées dans le carré Important x Peu d’informations sont à rechercher en priorité.

Tester ses hypothèses sur le terrain 🎰

Nous avons vu comment idéer, formuler et prioriser une hypothèse, voyons maintenant comment la tester.

Les experts recommandent de commencer par tester l’hypothèse la plus risquée d’abord (comprendre celle qui doit absolument être validée pour que le produit réussisse, en termes de désirabilité, viabilité ou faisabilité). Tami Reiss (product leader confirmée), recommande ces astuces : 

• Test sur Hypothèse 1, le problème à résoudre : Faites des recherches sur les sites de questions et forums (Google, Twitter, Quora) pour voir si les gens parlent du problème et des solutions existantes. Faites des entretiens avec de potentiels utilisateurs sur votre segment cible pour voir s’ils ont eu ce problème.
• Test sur Hypothèse 2, la solution potentielle : Faites un MVP et présentez-le à de potentiels utilisateurs. Posez-leur la question du prix qu’ils seraient prêts à débourser.
• Test sur Hypothèse 3, la capacité d'implémentation : Échangez le plus tôt possible avec votre lead engineer sur la solution envisagée, pour déterminer sa faisabilité technique.

Si la donnée qualitative ou quantitative vous confirme la véracité de votre hypothèse, passez à une autre hypothèse risquée (s’il en y en a une). Si l’hypothèse s’avère fausse, reformulez-la et retestez-la. Pensez à vérifier les implications de cette hypothèse erronée sur d’autres conditions et hypothèses reliées. 


---
Pour aller plus loin sur le sujet, on vous recommande les lectures suivantes :

• Réussir son cas de product discovery avec Maestro
• Identifying Assumptions in Product Development avec Laura Klein
• Assumptions Mapping for Product Discovery avec Productfolio
• Assumption / Validation Flowchart avec Tami Reiss

✍️ Anna Richard est incoming-PM en Fintech B2B et Startup Manager chez Bpifrance Le Hub où elle accompagne depuis 2 ans les startups seed et Série A du portefeuille sur leurs enjeux opérationnels en product et product marketing.
Alumni de la promotion 🦁 Lion du Samedi winter 2021 et Copywriting en septembre 2021.