Découvrir la méthode FOCUSED de Discovery Discipline à travers une étude de cas

En Product Management, la Discovery est une étape cruciale pour la réussite d’un Produit. Dans cet article, nous nous intéressons à l’ouvrage Discovery Discipline de Tristan Charvillat et Rémi Guyot. Ils proposent une méthode actionnable, articulée en 7 étapes clés : le framework FOCUSED. Plus structuré que la méthode double diamant, il permet d’approfondir les problèmes utilisateurs, de tester des solutions et de prendre des décisions éclairées !

Ce que vous allez apprendre

• Les 7 étapes du framework FOCUSED avec, en fil rouge, une étude de cas sur laquelle nous avons travaillé dans le cadre de notre mission.
• Comment utiliser le framework FOCUSED comme boîte à outils pour favoriser la convergence et la prise de décision.

Merci à l’équipe produit de HomeExchange d’avoir accepté de partager le cas d’usage qui illustre cet article.

Idées principales du framework FOCUSED

Chaque étape du framework FOCUSED propose une liste d’activités dans laquelle il est possible de sélectionner celles qui conviennent le mieux à son projet, ainsi qu’un livrable visant à faciliter le travail de convergence. Vous pourrez retrouver un template de ces livrables ici, que vous pouvez dupliquer dans votre espace notion et adapter à votre cas.

1) FRAME (Cadrer) :

• Objectif : clarifier les ambitions du projet et définir les objectifs à atteindre
• Activités : connexion vision-projet, brainstorm inversé, observation des métriques dans la durée, analyse de l’historique
• Livrable : le Project Ambition qui doit présenter :
  • Le Success criteria : l’impact à atteindre
  • Le Damage control : le risque que l’on est prêt à prendre
  • La Timebox : le temps à allouer à la Discovery

Cas concret :

En tant que Product Manager chez HomeExchange, je voudrais pouvoir calculer l’empreinte carbone des voyages de mes utilisateurs. En effet, la société est labellisée B-corp et le calcul des externalités de la société est un objectif stratégique.

Pour cela, je voudrais disposer de données déclaratives de nos utilisateurs sur les moyens de transport empruntés lors de leurs voyages. La base de données issue de ce questionnaire sera mise à disposition d’une société spécialisée dans le calcul d’empreinte carbone. Les réponses doivent aussi me permettre de réaliser une analyse qualitative pour faire de la sensibilisation aux modes de voyages les plus durables.

Voici mon Project Ambition :

• Success criteria : 70% des voyages réalisés par nos utilisateurs donnent lieu à une déclaration
• Damage control :
  • Un risque de peu de complétion ou drop si le flow est trop long.
  • Un risque de données faussées si les questions présentent des biais ou si les utilisateurs ressentent un jugement vis-à-vis de l’aspect écologique ou non de leur mode de voyage.
• Timeboxing : La Discovery ne doit pas dépasser un trimestre (c’est le temps de discovery que l’on est prêt à allouer au projet, et intégré dans la roadmap du quarter).

2) OBSERVE (Observer) :

• Objectif : identifier le cas d’usage principal (le problème à résoudre) qui fera office de boussole tout au long de la Discovery (et donc, écarter les cas d’usage secondaires).
• Activités : mises en situation, interviews téléphoniques, veille sur les réseaux sociaux et app stores, questionnaire en ligne, analyse des retours du service client, visites à domicile, cartes d’empathie, analyse des données comportementales
• Livrable : First Use Case (cas d’usage principal pour la cible définie)

Cas concret :

Après plusieurs entretiens en interne avec l’équipe RSE et le service relation client, je détermine que mon First Use Case est celui-ci :

En tant que responsable RSE

Lorsque je souhaite pouvoir faire estimer l’impact carbone de notre entreprise

J’ai besoin de pouvoir fournir des données fiables et précises à un organisme d’expertise climatique

Or, nous ne disposons pas actuellement de ces informations

Actuellement j’utilise des outils externes pour envoyer des formulaires en ligne mais ceux-ci sont rarement complétés

Un second cas d’usage est celui de mes utilisateurs qui aimeraient connaître l’impact carbone de leur voyage et devraient actuellement réaliser les calculs eux-mêmes. Je choisis de ne pas en faire mon First Use Case car j’ai peu de certitudes concernant le nombre d’utilisateurs qui seraient réellement intéressés par cette fonctionnalité. En effet cette appétence n’est pas facile à mesurer car nous n’avons pas de données quantitatives dessus. Concernant la donnée qualitative, elle comporte un risque de biais car c’est un sujet sur lequel les déclarations et les actions réelles peuvent différer.

En revanche, l’enjeu RSE fait partie des objectifs stratégiques de l’entreprise et j’ai un haut niveau de certitude sur le fait que ma fonctionnalité ait un impact positif en ce sens.

3) CLAIM (Déclarer) :

• Objectif : réfléchir à une solution sous un angle marketing et clarifier la promesse faite aux utilisateurs.
• Activités : benchmark interne, benchmark externe, brainstorm, communiqué de presse, focus group.
• Livrable : Launch Tweet (tweet de lancement fictif de moins de 280 caractères).

Cas concret :

Etant donné mon First Use Case, j’imagine un communiqué interne :

“Hello l’équipe RSE, nous lançons une fonctionnalité permettant à nos utilisateurs de répondre au sein du produit à nos questions sur leur mode de voyage. Ces données seront mises à disposition de notre partenaire d’expertise climatique, ce qui permettra d’estimer l’impact carbone de ces voyages.”

4) UNFOLD (Dérouler) :

• Objectif : identifier les points de contact principaux de l’expérience utilisateur
• Activités : architecture (représenter les différentes pages produits sollicitées sous forme de flow), mapping multicanal, avant/après (permettant d’avoir une vision de l’expérience complète), Journey line.
• Livrable : 5 touchpoints (mapping des 5 étapes clés du parcours utilisateur qui vont faciliter l’adoption de la fonctionnalité ou du produit).

Cas concret :

Je représente les différents moments de l’expérience utilisateur où ma fonctionnalité sera mise en avant, que ce soit au sein du produit ou par des actions CRM :

Au sein de l’équipe produit, nous décidons également de lancer la fonctionnalité dans un premier temps sur l’application mobile avant le site web, car l’usage du mobile est plus important au cours d’un échange.

5) STEAL (Voler) :

• Objectif : rechercher les solutions déjà existantes sur le marché pour « identifier les patterns les plus puissants et réutilisables pour votre solution ».
• Activités : décomposition du problème, usual suspects, grande battue, mise en place d’une bibliothèque d’écrans.
• Livrable : Gold nuggets (captures d’écran de fonctionnalités et solutions existantes dont s’inspirer pour son produit).

Cas concret :

Avec mon Product Designer, je réalise un benchmark de différents flows sur des applications mobiles permettant aux utilisateurs de répondre à des questions. Je veux m’inspirer de ceux qui permettent de donner des réponses de manière rapide et fluide et intégrer des éléments de gamification pour maximiser le taux de réponses.

On centralise nos trouvailles et on met en lumière les bonnes idées (gold nuggets) sur FigJam.

6) EXECUTE (Exécuter) :

• Objectif : donner vie à sa solution et la transformer en une version tangible
• Activités : design jam, step and stretch, guerilla interviews, revue de simplification, retours à distance, prototypage, design system
• Livrable : Happy Path (constitué du prototype de la solution et de 3 hypothèses qui, si elles sont validées, permettront de basculer en Delivery)

Cas concret :

Un Product Designer prend le lead sur cette étape et réalise sur Figma un prototype à faire tester à des utilisateurs.

Les hypothèses que nous souhaitons valider sont :

• on suppose que le flow ne doit pas comporter plus de 7 questions ni durer plus de 2 minutes afin d’éviter des abandons en cours de questionnaire et obtenir 70% de réponses.
• on suppose que le moment le plus propice à l’intégrer au parcours est à la fin du voyage, au moment de noter son expérience, afin que les données soient exactes et que les utilisateurs soient incités à répondre après la notation de leur échange.

7) DECIDE (Décider) :

• Objectif : tester la solution imaginée et valider les hypothèses formulées en étape 6 (”Execute”) afin de décider si le travail de Discovery est terminé et peut être lancé en Delivery.
• Activités : test d’utilisabilité, Rapide Iterative Testing and Evaluation (RITE), automatisation et externalisation des tests, diffusion en direct.
• Livrable : Go/No Go (un No-Go de la part d’un des membres de l’équipe sera l’occasion d’évaluer un éventuel point bloquant ou de rediscuter afin de trouver un consensus).

Cas concret :

On utilise l’outil Maze pour faire tester le prototype à des utilisateurs. Le prototype nous permet aussi de faire tester la solution en interne à nos stakeholders (RSE, relation client) et d’obtenir une estimation globale de l’effort technique en T-shirt sizing.

Nous avons la chance d’avoir une communauté engagée avec un panel d’ambassadeurs, ce qui nous permet d’obtenir rapidement des réponses.

Après quelques itérations suite aux retours des utilisateurs et stakeholders, on présente le projet en résumant les grandes étapes et livrables de la méthode dans une réunion avec les parties prenantes et c’est un GO qui est donné au projet 🎉

Il est ajouté à la roadmap Delivery du prochain quarter.

Conclusion

Le framework FOCUSED présente donc plusieurs points forts : il est structuré et actionnable, centré sur l’utilisateur et encourage la collaboration entre les différentes parties prenantes.

Ne vous laissez cependant pas intimider par les 7 étapes clés. La durée de chacune d’entre elles peut varier considérablement, en particulier si vous disposez déjà de données préexistantes.

N’hésitez donc pas à adapter la méthode aux besoins spécifiques de votre produit et à votre contexte.

À vous de jouer !