Voir la source de Comment construire un Arbre Opportunité-Solution

[[Category: Découverte Produit]]
Auteur : Ed Biden<br />
Source : [https://www.hustlebadger.com/what-do-product-teams-do/how-to-build-an-opportunity-solution-tree/ How to build an Opportunity Solution Tree]<br />
----
Traducteur : Fabrice Aimetti<br />
Date : 19/08/2025<br />
----
Traduction :<br />
<br />
Pour les équipes qui naviguent dans le monde complexe de l'innovation, les arbres opportunité-solution sont un outil visuel très utile pour visualiser la façon dont vous réfléchissez et pour repérer les prochaines étapes de votre travail.<br />
<br />
En présentant votre travail sous la forme d'une structure arborescente, vous êtes obligé d'être clair sur la manière dont le travail s'articule pour atteindre vos objectifs, et de faire des choix conscients entre les différentes possibilités.<br />
<br />
Cet article décrit ce que sont les arbres opportunité-solution (''OST ~ Opportunity Solution Tree'') et comment les utiliser.<br />
<br />
Que vous décidiez ou non de créer votre propre arbre opportunité-solution, le fait d'envisager la discovery de cette manière peut vous fournir un modèle mental qui vous permettra de prendre des décisions plus efficaces quant à la recherche à effectuer et à la manière de le faire.<br />
<br />
Dans ce guide, nous vous présenterons le concept des arbres opportunité-solution, nous vous dirons quand les utiliser un et comment en construire un excellent.<br />

==Que sont les arbres opportunité-solution ?==
[[Fichier:OSTs.png|700px|border|link=]]<br/>
<br/>
Les arbres opportunité-solution (OST) décrivent :
* les '''objectifs métier''' que vous visez
* Les '''opportunités''' que vous pouvez exploiter pour atteindre ces objectifs
* Les '''solutions''' que vous pourriez utiliser pour réaliser chaque opportunité
* Les '''tests des suppositions''' que vous pouvez effectuer pour accroître la confiance dans ces solutions.
<br/>
Il s'agit d ['une autre façon de visualiser votre progression dans la discovery, d'un point de vue légèrement différent du double diamant classique du [https://www.hustlebadger.com/what-do-product-teams-do/design-thinking/ design thinking], et c'est un excellent moyen d'articuler vos [https://www.hustlebadger.com/what-do-product-teams-do/developing-the-pillars-of-your-product-strategy/ axes stratégiques].<br/>
<br/>
Alors que le design thinking vous montre une approche détaillée du développement d'une idée unique, les arbres opportunité-solution vous aident à visualiser plusieurs approches à la fois, reflétant le fait que la plupart des équipes produits travailleront (et devraient travailler) sur plusieurs choses en même temps.<br/>

 '''Opportunités vs Problèmes'''
 Une différence évidente entre le design thinking et les arbres opportunité-solution est que le design thinking parle de l'espace "problème", alors que les arbres opportunité-solution parlent d' "opportunités". Il s'agit d'une différence purement sémantique, les deux termes désignant la même chose. Le fait d'utiliser des "opportunités" au lieu de "problèmes" permet de reconnaître qu'il n'est pas toujours nécessaire de résoudre les problèmes des utilisateurs pour créer de la valeur pour l'entreprise. Parfois, nous pouvons travailler sur quelque chose qui a une valeur métier-affaire pure (par exemple, la tarification ou la croissance).

Les arbres opportunité-solution ont été développés par [https://www.producttalk.org/2016/08/opportunity-solution-tree/ Teresa Torres] en 2016, et sont rapidement devenus l'un des frameworks les plus populaires utilisés par les PM et les concepteurs pour naviguer dans la discovery.

==Quels sont les bénéfices des arbres opportunité-solution ?==
Les arbres opportunité-solution vous aident à réfléchir à la discovery et à communiquer votre stratégie à votre équipe et aux autres parties prenantes.<br/>
<br/>
Pour ce faire, ils présentent deux avantages principaux :
# '''Lier la réalisation et la discovery aux impacts métiers (“'business outcomes”').''' Lorsqu'ils sont lus de haut en bas, les arbres opportunité-solution tracent une ligne directe entre le travail effectué par l'équipe produit (discovery et réalisation) et l'impact métier qu'il soutient. Cela permet à chacun de comprendre pourquoi un élément de travail est important.
# '''Priorisation des alternatives''' - Lorsqu'ils sont lus d'un côté à l'autre, les arbres opportunité-solution vous aident à prioriser les alternatives au même niveau. Par exemple, quelles opportunités devons-nous poursuivre en premier ? Quelles sont les solutions les plus prometteuses ?
<br/>
L'ensemble de ces éléments permet de prendre de meilleures décisions et d'être plus confiant quant à l'action à mener.<br/>

==Quand utiliser un arbre de solutions d'opportunités==
Les arbres opportunité-solution sont un excellent outil à utiliser lorsque les conditions suivantes sont réunies :
* '''Vous travaillez sur un produit existant''' : vous devez avoir des opportunités et des solutions à proposer. Si, au contraire, vous travaillez sur un produit créé de toutes pièces, vous essayez de déterminer quelle est votre valeur ajoutée et à quoi pourrait ressembler un MVP raisonnable. Dans ce cas, il est préférable de mener des [https://www.hustlebadger.com/what-do-product-teams-do/qualitative-user-research/ entretiens approfondis avec les utilisateurs] et d'utiliser le design thinking pour aller de l'avant.
* '''Vous êtes dans une [https://www.hustlebadger.com/what-do-product-teams-do/product-roadmap-templates/ "phase bleue"]''' : vous devriez travailler avec une équipe autonome et pilotée par les impacts. En revanche, si vous êtes dans une "phase rouge" et que l'on vous demande de fournir une partie d'un projet plus vaste, il est probable que quelqu'un d'autre aura décidé de la solution à mettre en place. Vos principales priorités seront de gérer les délais et les dépendances, plutôt que de faire du travail de discovery supplémentaire.

==Comment construire un arbre opportunité-solution==
Les arbres opportunité-solution sont construits de manière descendante au départ, et leur construction comporte quatre étapes clés, correspondant aux quatre niveaux différents qu'ils proposent :
# '''Impact'''
# '''Opportunités'''
# '''Solutions'''
# '''Tests des suppositions'''

Examinons chacun de ces points plus en détail.

==Impact==
La plupart des équipes produit se voient attribuer des objectifs par les responsables produit ou les PDG, mais vous devrez peut-être les affiner pour les rendre plus concrets afin d'éviter tout désalignement.<br/>
<br/>
Nous aimons utiliser une combinaison (mission + indicateurs) pour définir un impact :
* '''Mission''' : un énoncé inspirant sur ce que vous essayez d'accomplir. Vous pouvez souvent l'interpréter comme votre objectif.
* '''Indicateurs''' : comment savoir si vous avez atteint votre mission. Les indicateurs doivent servir à mesurer la mission, et non à la définir. Un bon format est le suivant : faire passer [l'indicateur] de [la base de référence] à [cible] d'ici [la date].  
<br/>
Par exemple : 
* '''Mission''' : offrir une expérience d'onboarding fluide. 
* '''Indicateur''' : augmenter le taux de réussite du processus d'onboarding de 85 % à 92 % d'ici le 31 mai.

 '''Mission''' : Augmenter notre base d'utilisateurs
 '''Indicateur''' : Faire passer le nombre d'utilisateurs mensuels actifs (MAU) de 80 000 à 120 000 d'ici le 31 mars.

Il convient de noter que la plupart des équipes produit [https://www.hustlebadger.com/metrics/product-success-metrics/ ne se voient pas attribuer (et ne devraient pas se voir attribuer) des objectifs métier très ambitieux] tels que "augmenter le chiffre d'affaires" ou "maximiser la croissance". Des objectifs vagues comme ceux-ci ont tendance à définir un champ d'opportunités tellement vaste que, à moins que l'équipe ne soit très expérimentée, elle peut avoir du mal à savoir par où commencer. Comme le dit le dicton, "la créativité aime les contraintes" : si vous êtes PDG ou responsable produit, vous obtiendrez de meilleurs résultats de la part de vos équipes en leur donnant un impact plus précis sur lequel se concentrer.

==Opportunités==
[[Fichier:Opportunities branch off outcome in OST.png|900px|border|link=]]<br/>
<small>''Les opportunités découlent de l'impact dans l'OST''</small><br/>
<br/>
Une fois que vous avez une idée claire de l'impact à atteindre, vous êtes prêt à commencer à cartographier l'espace des opportunités et à prioriser 1 à 2 opportunités sur lesquelles vous concentrer.<br/>

===Cartographier les opportunités===
Pour comprendre quelles opportunités existent, vous devrez mener plusieurs types de recherches génératives :
* '''Entretiens utilisateurs''' : discuter directement avec les utilisateurs pour comprendre leur vision du monde et leur expérience.
* '''Analyse comportementale''' : explorer les données dont vous disposez sur les utilisateurs pour identifier des tendances.
* '''Cartographie des processus''' : visualiser les processus et les flots utilisateurs pour comprendre tous les points de contact et toutes les interactions.
* '''Experts du domaine''' : obtenir la contribution des parties prenantes et d'autres personnes qui connaissent très bien le domaine.
<br/>
Cette approche est très similaire à la manière dont vous étudieriez l'espace du problème dans le cadre du design thinking.<br/>
<br/>
Au fur et à mesure que vous découvrez des opportunités, vous pouvez les ajouter à votre arbre opportunité-solution, en filtrant les problèmes ou les opportunités des utilisateurs qui ne sont pas réellement liés à l'impact souhaité. Ce n'est pas parce qu'un utilisateur se plaint de quelque chose ou qu'une partie prenante le mentionne que cela constitue une opportunité.<br/>

 '''Exemple :'''
 
 Vous êtes PM dans une entreprise de e-commerce et votre impact désiré est d'améliorer l'activation, c'est-à-dire le nombre d'utilisateurs effectuant leur premier achat. Vous avez discuté avec des utilisateurs existants et découvert que leurs principales frustrations sont les suivantes :  
 a) trouver les bons articles  
 b) le processus de retour s'ils achètent le mauvais article  
 
 '''a) est une opportunité.''' Faciliter la recherche des bons articles pourrait augmenter le nombre d'utilisateurs effectuant un premier achat.
 
 '''b) n'est pas une opportunité.''' Ce problème n'apparaît qu'après le premier achat d'un client. Résoudre ce problème peut être une bonne chose en général, mais cela ne vous aidera pas à atteindre votre objectif.

===Prioriser les opportunités===
Lorsque vous identifiez les opportunités qui pourraient vous permettre d'atteindre votre objectif, vous devez les prioriser en permanence afin de vous concentrer sur quelques-unes à la fois. Vous devez émettre une supposition sur les opportunités qui auraient le plus grand impact si elles étaient exploitées.<br/>
<br/>
Souvent, c'est évident. Une opportunité est constamment évoquée par les utilisateurs ou dispose d'un mécanisme beaucoup plus puissant pour vous aider à atteindre votre objectif.<br/>
<br/>
Si ce n'est pas le cas, rappelez-vous qu'il s'agit d'un processus politique : en fin de compte, vous souhaitez obtenir un consensus et l'adhésion aux opportunités que vous choisissez, tout en étant objectivement dans le juste.<br/>
<br/>
Quatre grandes catégories d'activités peuvent vous aider à prioriser les opportunités :
# '''Évaluation de l'opportunité''' : créer un modèle d'impact pour comprendre dans quelle mesure cette opportunité pourrait contribuer à l'impact que vous visez.
# '''Facteurs liés aux clients''' : comprendre combien d'utilisateurs seraient concernés par cette opportunité (c'est-à-dire le ''reach''/la portée/l'incidence) et quelle importance elle revêt pour eux (c'est-à-dire la gravité).
# '''Facteurs liés à l'entreprise''' : comprendre les implications métiers/affaires plus larges et l'alignement avec la mission, la vision et la stratégie globales de votre entreprise.
# '''Facteurs liés au marché''' : évaluer comment le fait d'adresser cette opportunité affecterait la position de votre produit sur le marché.
<br/>
L'effort ne fait pas partie de cette priorisation, car nous n'évaluons pas encore les solutions. Nous ne voulons pas préjuger de la difficulté à adresser une opportunité avant d'avoir eu l'occasion de générer diverses options. Même si les opportunités dont nous partons peuvent nécessiter beaucoup d'efforts, une solution simple et efficace peut apparaître assez facilement si nous savons qu'il s'agit de l'opportunité clé sur laquelle travailler.<br/>
<br/>
S'il existe une réponse claire et évidente, construisez un argumentaire en sa faveur et persuadez les autres. Si plusieurs opportunités semblent à peu près équivalentes, ne vous en faites pas trop : peu importe celle que vous choisissez ! Commencez par celle qui est la plus facile sur le plan politique ou celle que vous préférez personnellement.<br/>
<br/>
Comme nous l'avons dit, vous devez considérer cette priorisation comme une supposition et accumuler des preuves pour ou contre celle-ci au fur et à mesure que votre travail avance.<br/>
<br/>
Quoi que vous fassiez, ne vous concentrez pas sur trop d'opportunités à la fois, et concentrez-vous idéalement sur une ou deux seulement. Fractionner votre temps entre plusieurs opportunités signifie que vous fractionnez votre apprentissage et vos efforts, et que vous ferez moins de progrès sur chaque opportunité. Une fois que vous aurez pris en compte les coûts de changement, vous aurez tendance à aller plus lentement dans l'ensemble.<br/>

==Solutions==
[[Fichier:OSTs_Solutions_branch_off_opportunities_in_OST.png|900px|border|link=]]<br/>
<small>''Les solutions découlent des opportunités dans l'OST''</small><br/>
<br/>
Vous ne pouvez pas créer de valeur sans diffuser de solutions, et souvent, le meilleur apprentissage vient de la présentation de solutions potentielles à de vrais utilisateurs. Une fois que vous avez décidé de l'opportunité sur laquelle vous allez vous concentrer, vous pouvez commencer à réfléchir aux solutions qui ont du sens et à la manière de les prioriser.

===Générer des solutions===
Une fois encore, cela reflète le design thinking, cette fois-ci dans sa [https://www.hustlebadger.com/what-do-product-teams-do/design-thinking/ phase d'idéation]. Vous pouvez organiser une session d'idéation avec un groupe diversifié de parties prenantes, ou préférer laisser cette tâche à votre designer.<br/>
<br/>
L'essentiel ici est de se concentrer sur la quantité avant de s'engager dans quoi que ce soit. Si vous n'avez pas d'alternatives parmi lesquelles choisir, vous n'avez rien à comparer. Il n'y a pas de stratégie sans options.<br/>

===Prioriser les solutions===
Contrairement aux opportunités, où il est généralement judicieux de se concentrer sur une seule à la fois, dans le domaine des solutions, il est souvent préférable d'envisager plusieurs options à la fois.<br/>
<br/>
Les meilleures équipes produit travaillent en parallèle sur un petit ensemble de solutions (peut-être 4 à 8). Bien qu'il y ait toujours une hypothèse sur l'ordre dans lequel celles-ci devraient être développées, approfondir la recherche ou mettre en œuvre l'une de ces solutions nous en apprendra probablement davantage sur les autres.<br/>
<br/>
Dans le même temps, il est très courant que la discovery diminue notre confiance dans une solution donnée. Dans ce cas, il est utile de disposer d'autres solutions en réserve que nous pouvons mettre en avant. Cela nous donnera le temps d'itérer ou d'abandonner l'idée initiale sur laquelle nous travaillions.<br/>

[https://www.hustlebadger.com/what-do-product-teams-do/discovery/ Quelle est la quantité suffisante de discovery ?]. Cela dépend d'un certain nombre de facteurs, tels que : 
* '''Le coût de développement''' : le temps et l'argent nécessaires pour  construire la solution 
* '''Le scénario pessimiste''' : le degré de gravité du pire scénario possible
* '''La maturité et la culture de l'entreprise''' : les enjeux (par exemple, les revenus) et notre culture de prise de décision
* '''Le coût d'opportunité''' : ce que nous pourrions construire à la place
<br/>
Mais c'est aussi une question de temps. Dans un monde idéal, vous avez renforcé votre confiance au-delà des risques que vous voyez dans une fonctionnalité au moment où elle atteint le haut du backlog. Si ce n'est pas le cas, vous devez alors décider si vous souhaitez la diffuser quand même ou occuper votre temps d'une autre manière (par exemple, en travaillant sur des bugs ou la dette technique).<br/>
<br/>
Planifier les suppositions que vous devez tester vous aide à tirer le meilleur parti de votre temps et augmente vos chances d'avoir suffisamment confiance en chaque solution que vous construisez.<br/>

==Test des suppositions==
[[Fichier:OSTs Assumption tests mapped off potential solutions in an OST.png|500px|border|link=]]<br/>
<small>''Les tests de suppositions cartographient les solutions potentielles dans l'OST.''</small><br/>
<br/>
Chaque fois que vous lancez une nouvelle solution, vous faites un pari qui, vous l'espérez, créera de la valeur pour l'entreprise ou les utilisateurs. Quatre types de risques contribuent aux chances globales de réussite d'une solution :
* '''Risque lié à la valeur''' : les clients veulent-ils vraiment cette solution ? l'apprécient-ils à sa juste valeur ?
* '''Risque lié à la facilité d'utilisation''' : les utilisateurs peuvent-ils comprendre cette solution ? savent-ils comment elle fonctionne ?
* '''Risque technique''' : pouvons-nous développer cette solution ? est-elle évolutive, sécurisée et fiable ?
* '''Risque de viabilité''' : l'entreprise peut-elle fournir ce produit ? cela crée-t-il une complexité opérationnelle ? est-ce légal ?
<br/>
[[Fichier:OSTs risks.png|border|link=|600px]]<br/>
<br/>
Vous souhaitez réduire ce risque à un niveau gérable avant de vous engager à livrer une solution donnée. Les meilleurs PM s'attaquent d'emblée aux risques les plus importants et renforcent la confiance dans une solution en effectuant des tests de suppositions successifs qui font progresser la solution sur [https://www.hustlebadger.com/what-do-product-teams-do/discovery/ l'échelle de confiance].<br/>
<br/>
Deux frameworks vous aident à réfléchir à cette question :
# '''Cartographie des suppositions''' : identification et priorisation des composantes du risque pour une solution.
# '''Tests itératifs''' : augmentation systématique de la confiance dans la solution globale.

===Cartographie des suppositions===
[[Fichier:OSTs Assumption mapping matrix.png|600px|border|link=]]<br/>
<small>''Matrice de cartographie des suppositions''</small><br/>
<br/>
Vous pouvez identifier les suppositions en passant en revue votre solution proposée et en notant les suppositions relatives aux quatre types de risques (valeur, utilisabilité, technique, métier).<br/>
<br/>
Une excellente façon de procéder consiste à réunir un groupe multifonctionnel et à demander à différentes personnes d'évaluer l'idée sur différentes catégories de risques. Par exemple, un ingénieur se concentre sur les suppositions techniques, un concepteur se concentre sur les suppositions d'utilisabilité, etc.<br/> 
<br/>
Vous pouvez ensuite représenter vos suppsotions sur une  matrice 2×2 opposant le risque à la certitude.<br/>
<br/>
Le '''risque''' (élevé – faible) correspond à la criticité de cette supposition vis-à-vis de l'efficacité de la solution. Si une supposition erronée rendait toute la solution inutile, le risque serait élevé (par exemple, tout le monde serait ravi de payer en bitcoins).<br/>
<br/>
La '''certitude''' (connue à inconnue) correspond à la quantité de preuves dont vous disposez actuellement pour étayer vos suppositions. Ainsi, si vous disposez de certaines preuves étayant une supposition, mais que vous souhaitez en avoir davantage, celle-ci se situe au milieu. Si la supposition est une supposition hasardeuse, elle se situe à l'extrême droite.<br/>
<br/>
Vous pouvez alors prioriser les suppositions à haut risque et à faible certitude, qui sont les plus importantes à tester en premier. Cela vous permet de traiter les risques liés aux composants un par un, plutôt que de tester l'ensemble de la solution, ce qui est un moyen beaucoup plus efficace de renforcer la confiance dans une solution dès le départ.<br/> 
<br/>
Considérez chaque supposition comme une hypothèse, puis réfléchissez aux tests que vous pouvez effectuer pour recueillir des preuves qui confirmeront ou infirmeront cette hypothèse.<br/>
<br/>
Un test peut consister à :
* Construire un prototype et le présenter aux utilisateurs.
* Réaliser une étude technique pour comprendre comment vous construiriez une fonctionnalité.
* Discuter avec les parties prenantes pour comprendre les implications métiers d'une fonctionnalité.
* Effectuer une analyse comportementale pour comprendre plus en détail le comportement réel des utilisateurs.
* Et ainsi de suite.
<br/>
Idéalement, vous devriez d'abord effectuer des tests rapides et peu coûteux pour gagner en confiance, avant de passer à des tests plus coûteux et plus élaborés afin de minimiser les risques vraiment importants. C'est le principe de base des tests itératifs.<br/>

===Tests itératifs===
[[Fichier:OSTs Tests itératifs.png|border|link=|700px]]<br/>
<br/>
La confiance dans une solution ne vient pas d'un seul coup, et il est rare d'avoir une certitude absolue sur une hypothèse donnée. Dans la plupart des cas, la confiance dans une solution se construit au fil du temps, en effectuant des tests successifs, chacun d'entre eux renforçant votre confiance, mais nécessitant plus de temps et d'argent.<br/>
<br/>
Par exemple, si vous essayez de réduire le risque technique :
* Une conversation avec votre responsable technique pour savoir si cela est théoriquement possible peut prendre quelques minutes.
* Le responsable technique qui examine le code pour vérifier quelques éléments peut prendre une heure.
* Un spike technique peut être limité à un ou deux jours.
<br/>
Et si vous essayez de réduire le risque lié à l'utilisabilité :
* Obtenir les feedbacks de votre équipe sur une maquette peut prendre quelques minutes.
* Obtenir les commentaires d'une poignée d'utilisateurs réels sur un prototype de haut niveau peut prendre des heures.
* Obtenir les feedbacks d'un grand nombre d'utilisateurs réels nécessitera probablement un prototype détaillé ou un MVP, dont la création peut prendre des jours, voire des semaines.
<br/>
Vous ne voulez pas vous engager dans le MVP avant d'avoir obtenu les feedbacks de votre équipe. Mais les feedbacks de votre équipe ne suffisent pas à eux seuls à justifier la création de la fonctionnalité.<br/>
<br/>
Il faut plutôt considérer les différents types de preuves comme appartenant à une hiérarchie :<br/>
<br/>
[[Fichier:OSTs Hustle Badger confidence scale.jpg|link=|border|600px]]<br/>
<small>''[https://www.hustlebadger.com/what-do-product-teams-do/joe-tinston/ Échelle de confiance] Hustle Badger''</small><br/>
<br/>
Vous progressez pas à pas dans cette échelle, en testant les suppositions principales à tous les niveaux ou presque :<br/>
<br/>
[[Fichier:OSTs levels.png|border|link=|800px]]<br/>

 1. Plusieurs idées issues de la session d'idéation, que le PM priorise afin de les approfondir avec l'équipe.
 2. Feedbacks sur le wireframe présenté aux utilisateurs. Les enseignements tirés sont réintégrés dans l'ensemble des conceptions et du séquençage.
 3. Une idée particulière reçoit un bon feedback des clients, l'équipe convertit donc le wireframe en prototype.
 4. Le prototype présente quelques problèmes d'utilisabilité, l'équipe effectue donc plusieurs itérations pour les résoudre.
 5. Les données du test A/B sont positives, l'équipe déploie donc la fonctionnalité auprès de tous les utilisateurs.

Au fur et à mesure, vous répertoriez vos principales suppositions et votre niveau global de confiance dans chacune d'elles dans votre arbre opportunité-solution. Pour chaque supposition de votre arbre opportunité-solution, vous n'essayez pas d'effectuer des tests ni d'atteindre directement le niveau de confiance le plus élevé possible. Ces deux approches vous conduiraient à effectuer des tests longs et coûteux alors que vous auriez pu découvrir les problèmes beaucoup plus rapidement et à moindre coût.<br/>
<br/>
Au lieu de cela, vous essayez de comprendre le profil de risque global d'une fonctionnalité à travers les quatre catégories de risque (valeur, utilisabilité, technique et métier) et de planifier la prochaine étape logique, car elle augmente votre confiance avec un minimum d'efforts.<br/>

===Répondre aux tests des suppositions===
Chaque fois que vous effectuez un test, vous recueillez des preuves concernant vos hypothèses. La suite dépendra du fait que ces preuves corroborent ou non votre hypothèse :
* '''Supposition corroborée''' : investissez dans des tests plus poussés ou développez un produit réel
* '''Preuves non concluantes''' : intégrez les enseignements tirés et refaites le test
* '''Supposition rejetée''' : dépriorisez cette solution par rapport aux autres dans votre OST afin de vous donner le temps de la repenser.

==Problèmes courants==
L'un des principaux avantages de l'utilisation des arbres opportunité-solution est qu'ils permettent de visualiser certaines erreurs courantes dans la discovery, ce qui les rend plus faciles à repérer et à éviter.<br/>
<br/>
Passons en revue quelques-unes de ces erreurs, ainsi que les tactiques que vous pouvez utiliser si vous êtes confronté à l'un de ces problèmes.<br/>

===Solutions non liées aux impacts===
Les opportunités que vous adressez et les solutions que vous élaborez n'auront pas d'incidence significative sur l'impact que vous souhaitez obtenir. Ou vous n'avez même pas défini l'impact que vous recherchez.<br/>
<br/>
[[Fichier:OSTs no impact.png|border|link=|800px]]<br/>

====Solution====
Avant toute chose, essayez de définir vous-même l'impact souhaité en fonction du contexte métier dans lequel vous évoluez. Partagez ensuite cette définition avec vos principales parties prenantes afin de recueillir leur avis et de vous mettre d'accord avec elles. Si vous obtenez des réponses différentes de la part des différentes parties prenantes, ne vous opposez pas directement à elles. Réunissez tout le monde dans la même pièce et animez une discussion sur ce qui est réellement le plus important à faire.<br/>
<br/>
Vous ne pouvez pas gagner si tout le monde attend de vous que vous fassiez des choses différentes, et si vous n'avez pas de résultat clairement défini, c'est pratiquement garanti.<br/>

===Impacts multiples et contradictoires===
Vous vous dispersez entre plusieurs impacts, ce qui se traduit par un manque de concentration dans votre travail. Cela peut arriver très facilement si vous utilisez des [https://www.hustlebadger.com/what-do-product-teams-do/okr-template/ OKR] et avez défini plusieurs résultats clés qui vous mènent dans des directions différentes (plutôt que d'être différentes façons d'exprimer un seul objectif).<br/>
<br/>
[[Fichier:OSTs Multiple competing outcomes.png|border|link=|800px]]<br/>

====Solution====
Si vous définissez vos propres objectifs, déterminez lequel est le plus important et mettez les autres de côté. Les progrès sont inversement proportionnels au nombre de priorités que vous avez, vous devez donc limiter autant que possible le nombre d'objectifs à un seul.<br/>
<br/>
Cela dit, il n'est pas toujours possible de faire comprendre aux parties prenantes les inconvénients d'avoir trop d'objectifs concurrents. Si vous le pouvez, demandez-leur de classer les objectifs par ordre d'importance afin de savoir sur quoi vous concentrer et d'avoir une indication sur la proportion de votre temps qu'ils attendent de vous pour atteindre un objectif donné. Cela fonctionne mieux lorsque vous convertissez ce pourcentage théorique en jours/semaines.

 « D'accord, vous voulez donc que nous consacrions 50% de notre temps à améliorer la recherche, puis 25% à examiner le processus de paiement et de onboarding.
 
 Cela signifie donc que nous consacrerons 6 semaines à la recherche et 3 semaines au paiement et à l'onboarding. »  

Vous pouvez souligner l'intérêt de se concentrer sur un nombre réduit de sujets en leur rappelant le temps qu'il a fallu pour mettre en place certaines fonctionnalités par le passé (qui est presque toujours plus long que ce que les gens imaginent).<br/>

===Un manque d'alternatives===
Vous n'avez aucune alternative, que ce soit au niveau des opportunités, des solutions ou les deux. Cela se produit lorsque vous n'avez pas effectué suffisamment de recherches génératives pour découvrir davantage de problèmes rencontrés par les utilisateurs, ou suffisamment de réflexion pour créer davantage de solutions potentielles. Sans alternatives, vous ne pouvez pas savoir si vous vous concentrez sur le travail de plus grande valeur, car vous n'avez rien à quoi le comparer.<br/>
<br/>
[[Fichier:OSTs Lack of alternatives.png|border|link=|250px]]<br/>

====Solution====
Allez sur le terrain et discutez avec les utilisateurs pour comprendre quels autres problèmes ils rencontrent. Organisez une [https://www.hustlebadger.com/what-do-product-teams-do/ideation-session/ session d'idéation] pour trouver d'autres solutions potentielles. Vous pouvez le faire tout en continuant à travailler sur la seule opportunité/solution dont vous avez connaissance pour le moment, cela ne vous ralentira pas.<br/>
<br/>
À mesure que vous en apprendrez davantage sur les alternatives, vous pourrez alors vous tourner vers des sujets à plus fort impact si vous en trouvez, ou vous serez convaincu que vous travaillez déjà sur les sujets les plus importants.<br/>

===Trop de solutions / tests de suppositions===
Vous avez beaucoup trop de solutions ou de tests de suppositions à gérer. Vous vous perdez dans les détails. Cela peut arriver lorsque vous recevez beaucoup de demandes provenant d'autres équipes et de clients. La cause racine est généralement que votre stratégie n'est pas assez solide : vous ne disposez pas d'un filtre de haut niveau efficace pour éliminer les mauvaises idées.<br/>
<br/>
[[Fichier:OSTs Too many solutions and assumption tests.png|border|link=|800px]]<br/>

====Solution====
Cessez un instant de regarder votre backlog et votre arbre opportunité-solution, et prenez une feuille de papier vierge. À votre avis, qu'est-ce qui ferait vraiment bouger les choses ? Et pourquoi pensez-vous cela ?<br/>
<br/>
Le travail sur les produits est basé sur des hypothèses. Autrement dit, vous ne devez pas proposer une multitude d'idées pour ensuite décider quoi faire, mais plutôt avoir une idée de ce qu'il faut faire, puis la faire évoluer à mesure que vous obtenez davantage de preuves. Si vous n'avez pas d'hypothèse de départ, vous finirez par être paralysé par une liste interminable de discovery à faire pour déterminer sur quoi travailler.<br/>
<br/>
Si vous avez besoin d'aide pour élaborer une hypothèse stratégique, consultez notre modèle de [https://www.hustlebadger.com/what-do-product-teams-do/creating-a-strategy-development-plan/ stratégie éclair].<br/>

===Mélanger solutions et opportunités===
Vous confondez solution et opportunité. Vous ne savez pas si les clients apprécieront votre solution et vous n'avez pas envisagé d'alternatives. Cela peut arriver lorsque vous (ou une partie prenante) êtes tellement convaincu par une solution que vous essayez de la présenter comme une opportunité afin de vous assurer qu'elle soit adoptée. Et il est assez facile de le faire inconsciemment, sans même se rendre compte de l'erreur que l'on commet.<br/>
<br/>
[[Fichier:OSTs Mixing solutions and opportunities.png|border|link=|700px]]<br/>

====Solution====
Le test consiste ici à vous demander : « De quelles différentes manières pourrais-je aborder cette opportunité ? ». S'il n'y a qu'une seule façon de la traiter, alors il s'agit d'une solution. Les opportunités peuvent faire l'objet de multiples solutions.

Prenons les deux exemples suivants :
# « Je souhaite filtrer ma recherche par couleur » -> la seule approche ici consiste à créer un filtre de couleur, il s'agit donc d'une solution.
# « Je souhaite obtenir de meilleurs résultats de recherche » -> vous pourriez créer un filtre par couleur, personnaliser les résultats, modifier l'algorithme de tri... Il existe de nombreuses solutions potentielles à cette affirmation, il s'agit donc d'une opportunité.

Si vous travaillez sur une solution et que vous ne savez pas quelle est l'opportunité, posez-vous la question suivante : « Pourquoi est-ce important ? » La réponse sera probablement l'opportunité que vous recherchez.

==Résumé==

 Arbre opportunité-solution : [https://miro.com/miroverse/opportunity-solution-tree-canvas/ Miro]

Les arbres de solutions d'opportunités (OST) sont une technique visuelle puissante qui permet de cartographier vos découvertes. Ils vous aident à relier les expériences et les fonctionnalités à des résultats commerciaux plus larges, ainsi qu'à hiérarchiser les tâches les plus importantes à accomplir.<br/> 
<br/>
Les arbres de solutions d'opportunités comportent quatre niveaux principaux :
* '''Impact''' : l'impact que vous visez
* '''Opportunités''' : les défis que vous pouvez relever pour atteindre votre résultat
* '''Solutions''' : réponses potentielles aux opportunités que vous avez identifiées
* '''Tests de suppositions''' : moyens d'accroître votre confiance dans l'efficacité de votre solution
<br/>
Vous pouvez créer un arbre opportunité-solution après avoir mené quelques entretiens avec des utilisateurs afin de vous aider à cartographier l'espace. Ensuite, vous devez vous baser sur des hypothèses, cartographier votre réflexion actuelle dès que possible, puis mettre à jour votre arbre au fur et à mesure que vous recueillez davantage d'informations.