Holistic Product Discovery : un nouveau modèle pour faire de la discovery un sport d’équipe

⌛ 7 minutes de lecture

 ✉️ Article issu du Ticket n°054

Martin Christensen est un coach et UX designer suédois qui vient de publier Holistic Product Discovery, un petit bouquin (150 pages) de vulgarisation du product management. On l’a interrogé spécifiquement sur le nouveau modèle de discovery qu’il propose, afin de s’ouvrir l’esprit (et pour le plaisir d’ajouter un autre framework sur ton étagère).

Salut Martin. Avant de parler du modèle que tu as inventé avec ton partenaire Marcus Castenfors, peux-tu nous raconter la petite histoire derrière l’écriture de ce bouquin ?

Martin Christensen : Je suis coach UX depuis 2002 et j’ai pu me rendre compte de la difficulté des organisations à faire de la product discovery. Encore aujourd’hui d’ailleurs : c’est ma principale mission auprès des clients avec qui j’ai travaillé sur les cinq dernières années. J’ai donc commencé à créer un framework pour apporter un peu de structure et les aider à sortir du chaos.

Jusqu’à ce qu’un de mes amis, Marcus, mon co-auteur, me pousse à écrire un livre sur le sujet. On l’a commencé sur Leanpub, une plateforme où tu peux mettre à disposition des lecteurs les chapitres que tu viens d’écrire afin de recevoir leurs commentaires directement. On a donc travaillé de cette manière itérative avec environ 700 lecteurs pendant deux ans et demi jusqu’à cet été, date de la publication du livre.

Un des apports majeurs du livre, c’est sa matrice 4 X 3 appelée le Holistic Product Discovery Framework (image ci-dessous). Comment l’as-tu conçu ?

M. C. : Au cours de mes expériences, j’ai remarqué que la discovery n’était pas quelque chose de naturel pour les gens du business et encore moins pour les développeurs et développeuses. Alors que cela devrait être le cas !

Si l’on reprend le postulat du cabinet IDEO au début des années 2000, les 3 qualités d’un produit qui génère un résultat (=outcome) positif sont la viabilité économique, la désirabilité design et la faisabilité technique. Autrement dit, un produit avec ces 3 qualités possède un modèle économique pérenne, il répond au besoin des consommateurs et il est compatible avec les capacités opérationnelles de l’entreprise. On pourrait d’ailleurs ajouter aujourd’hui une 4e qualité qui est l’éthique* (est-ce que mon produit provoque des dommages à des personnes, des organisations ou l’environnement ?).

Ces qualités sont donc autant de risques potentiels qu’il convient de diminuer lors de la phase de discovery. On voit donc bien qu’il convient d’avoir une approche holistique du produit. Et j’ai alors réfléchi à la façon de prendre tous ces éléments en considération.

Et c’est là où tu as confronté ces 3 critères avec les 4 faces du double diamant…

M. C. : Exactement, pour permettre de savoir à quel moment et comment amener ces questions durant le processus. J’ai réalisé qu’on pouvait en effet fusionner ces deux dimensions au sein d’un cadre unique. J’ai commencé à l’utiliser à partir de 2016 et depuis, il me sert à chacune de mes missions. 

Tu parles de vue holistique. Cela veut-il dire que tout le monde dans l’entreprise doit être impliqué dans la discovery ? N’est-ce pas un peu trop lourd ?

M. C. : Il y a plusieurs choses. D’une part, je suis convaincu que la discovery est un sport d’équipe et que, pour avoir une approche équilibrée, il faut toujours avoir ces 3 perspectives business, design et technique dans le processus en continu. Avoir un ou une PM qui gère l’ensemble ne m’a jamais semblé être une solution convenable.

J’ai par exemple pu voir une énorme différence entre des projets où des développeurs avaient assisté à des entretiens utilisateurs au préalable et d’autres où on leur demande juste de coder ce qui a été défini. Les premiers pensaient nettement plus aux problèmes qu’ils devaient résoudre. Ce qui amène, généralement, à une mise en prod’ de meilleure qualité en bout de ligne.

Toutefois, je ne dis pas que tout le monde doit être présent tout le temps. Il faut inclure autant de personnes que possible au début du projet pour que chacun et chacune aient une compréhension globale des espaces de problèmes et de solutions. Mais, ensuite, on peut réduire l’équipe lors des phases de réponses aux hypothèses et faire appel aux différentes compétences ponctuellement en fonction de l’avancement.

Pour l’anecdote, j’ai présenté le framework à une grande agence de conseil suédoise… et ils n’étaient pas contents du tout ! Cela allait en effet à l’encontre de leur modèle d’affaires qui consiste à “vendre” un maximum de consultants à leurs clients.

Dans le livre, tu recommandes de commencer le cheminement par le coin en haut à gauche. Peux-tu expliquer sommairement la façon dont il faut utiliser cette matrice ?

M. C. : En effet, il convient de commencer le plus à gauche possible, c’est-à-dire sur l’aspect problème. La plupart des gens privilégient d’abord la solution, alors que ça ne doit venir que dans un second temps.

Et la case du haut, la valeur économique, c’est parce que je travaille généralement avec des entreprises qui sont là pour gagner de l’argent ! Si la boîte se rend compte qu’elle s’apprête à travailler sur quelque chose qui ne sera pas rentable pour elle, cela ne servira à rien de poursuivre le cheminement.

Mais, en soi, tu peux commencer d’où tu veux. Je travaille par exemple avec le service public suédois. Et bien l’enjeu économique est moins présent pour eux et ils commencent plutôt au milieu de la matrice sur l’aspect besoin utilisateur. Cela dépend aussi de ton niveau d’informations sur un sujet.

C’est-à-dire ?

M. C. : Il faut bien garder une chose en tête : l’objectif n’est pas de remplir toutes les cases ! Ce framework est une aide pour structurer sa pensée. Mais ce n’est pas ni un playbook ni une liste de cases à cocher.

On dit souvent que chaque case doit correspondre à une question puissante et que la succession de ces questions permet de nous rendre compte de notre niveau d’informations et des endroits où il faut plus creuser la discovery. On en sait assez sur le besoin des utilisateurs ? Très bien, alors pas besoin d’en interroger d’autres et on peut avancer. Tout est une question de niveau de certitude que l’on accepte en fait.

Une autre chose à retenir : le processus n’est pas linéaire. On peut tout à fait revenir en arrière. Ceci afin d’éviter de se retrouver bloqué, victime de “l’effet Ikea”, aussi appelé le biais du concepteur. Comme on a construit quelque chose, on n’est moins prêt à l’abandonner, même si on se rend compte que ça ne plaît pas aux utilisateurs.

Pour résumer les choses, la discovery est un exercice d’apprentissage dont le retour sur investissement est la connaissance. En comparaison avec la delivery dont l’objectif est la découverte de l’outcome et où le retour sur investissement est la valeur.

OK, donc pour toi, l’enjeu majeur de la discovery n’est pas son aspect chronophage mais plutôt la difficulté à estimer le niveau de confiance que l’on porte à ses hypothèses, c’est ça ?

M. C. : Oui, généralement le temps n’est pas un problème. Tu peux cadrer le temps que tu as envie d’y consacrer et, avec notre modèle, tu peux voir rapidement là où tu peux porter ton investissement. Non, le problème, c’est plutôt le biais de confirmation ou le biais de l’optimisme. Les personnes qui pensent qu’elles savent déjà tout.

Nous citons beaucoup d’exemples d’échecs dans le livre à cause de cela. Souvent, c’est parce que les concepteurs ne prennent pas l’hypothèse de base qu’il y a un risque. Libre à eux de prendre ou non ce risque et de faire plus ou moins de discovery pour essayer de l’atténuer. Mais il faut en amont de chaque projet l’avoir en tête et en discuter.

Un risque qui, on le comprend dans ton modèle, peut se situer en dehors de son champ d’action mais qu’il faut malgré tout appréhender…

M. C. : Tout à fait. C’est une question de perspective. Certaines personnes ne voient pas plus loin que ce qu’elles font. Alors que le but final, c’est de créer le meilleur produit pour l’entreprise et les utilisateurs. Utiliser ce framework, c’est s’assurer de lever un peu le nez.

Il y a quelque temps, je coachais un designer UX qui se donnait à fond pour réaliser une belle interface utilisateur fluide. Je lui ai demandé quel problème il était en train de résoudre ? Il m’a regardé bizarrement, du style “de quoi tu me parles ?” L’exemple peut se dupliquer aux dev mais aussi aux PM qui se concentrent parfois sur la conception d’une belle roadmap ou de beaux tickets Jira au détriment de la finalité de leur produir. Relever la tête, c’est d’ailleurs ce qui permettra de monter d’un cran et d’atteindre la dimension éthique, écologique et durable d’un produit.

Un grand merci Martin et peut-être à une prochaine en France ou à Stockholm, où tu es basé.

M. C. : Oui, avec plaisir. Je suis venu à Paris en octobre dernier pour un événement. Même si c’était un peu compliqué étant donné que j’essaie de ne pas prendre l’avion. Il faudra que je teste le tout nouveau train entre Stockholm et Hambourg (rire) !

* Pour aller plus loin sur la dimension éthique dans le produit, Martin conseille Digital Compassion de Per Axbom, Future Ethics de Cennydd Bowles ou A Designer’s Code of Ethics de Mike Monteiro. On ajoute aussi Responsables de Fabrice des Mazery.

Un mot sur Holistic Product Discovery :

Pour Martin Christensen, il y a en fait 4 livres en un ! Chaque personne pouvant choisir la ou les parties qui l’intéresse le plus entre : 

• 1. Ce que vous devez savoir pour comprendre le problème
• 2. La première solution pour structurer votre travail : le framework dont on vient de parler
• 3. La deuxième solution pour savoir comment collaborer (passage de discovery à delivery)
• 4. La mise en pratique concrète selon son niveau de maturité produit

Il y a beaucoup de passages qui vont te paraître évidents si tu n’es pas un ou une novice dans le produit. C’est normal : à l’origine, le livre devait être un point de départ pour des personnes ne connaissant pas ou très peu le product management.

Le héraut du produit, Marty Cagan, l’a lu lors de sa phase de conception itérative. Selon l’auteur suédois, il y a trouvé de bonnes choses mais a formulé deux critiques : trop “Scrum-ish” et “trop de process”.

“Il est très axé sur les principes plutôt que sur les process. Nous aussi, mais on a vu le besoin de donner quelque chose d’utile à des personnes qui n’accordent pas autant d’importance aux principes. Sachant que notre framework est plus un guide qu’un process structuré”.

Marty leur a également dit une chose : “On peut être d’accord ou non avec ce que vous dites… mais vous avez terminé votre livre. Alors publiez-le maintenant ! Et quand cela sera le cas, j’en ferais la publicité”. Ce qu’il a fait.