Pourquoi créer une Discovery Card ?

Dans cet article, on cherche à apporter une réponse à plusieurs problématiques qui se dressent devant les équipes Product lors de la naissance d’un produit et durant son cycle de vie :

• Comment centraliser les apprentissages liés à la Discovery ?

• Quel support utiliser pour affiner la vision produit et communiquer aux différents métiers impliqués ?

• Est-ce que les fonctionnalités que l’on va développer tout au long du projet sont et seront toujours reliées à une réponse aux besoins utilisateurs ?

Un livrable permettant de répondre à ces questions est la Discovery Card !

Véritable allié lors des phases de découverte et de conception, la “Discovery Card” possède une valeur ajoutée dans les différentes phases de développement, de mise en production et même pour des produits déjà matures. Elle est faite pour vérifier que les efforts fournis ont un impact direct sur les utilisateurs !

Concrètement, c’est un seul support qui permet de partir d’un besoin client et de l’objectif que l’entreprise cherche à atteindre afin de lier :

• Les différentes catégories d’utilisateurs (ou personae)
• Leurs préférences avec des verbatims forts
• Les préférences clés qui se dégagent
• Les fonctionnalités permettant de répondre aux préférences clés

Un prérequis essentiel est d’étudier les ressources à disposition sur :

• L’entreprise
• Les utilisateurs
• Le produit (dans le cas d’un produit existant)

C’est ce qui peut s’apparenter à une phase d’immersion.

1. la phase de découverte ou Discovery

C’est l’étape la plus consommatrice de temps et d’énergie mais aussi la plus enrichissante et importante ! Lorsque l’on démarre ou rejoint une équipe produit, il est primordial de savoir à quel besoin on veut répondre et quel est l’objectif.

Une première boussole consiste à décrire le cas d’usage principal ou “First Use Case”. Le “FUC” est un outil de focus qui démontre toute son utilité dans les phases de commencement d’un projet ou quand on a le sentiment d’être perdu :

First Use Case :

Je suis…..[Utilisateur cible]……..

Et lorsque je ……..[Cas d’usage]……..

Ce qui compte le plus pour ……..[Besoin]……..

Mais il s’avère que ……..[Contrainte]……..

Et je dois donc ……..[Contournement]……..

⚠️Toutefois, si vous croyez avoir identifié un besoin insatisfait mais qu’il ne rencontre aucune contrainte ou ne génère aucun contournement, il s’agit probablement d’un besoin trop faible.⚠️

Décrire précisément le cas d’usage principal identifié au cours de la phase d’immersion permet de mettre le doigt sur le ou les utilisateurs principaux à mettre en évidence sur l’outil, la thématique centrale et d’identifier des premières hypothèses qu’il va falloir vérifier.

Les utilisateurs ou groupe d’utilisateurs ciblés ne doivent pas avoir de secret pour vous, de ce fait, il va falloir les observer, comprendre leur manière de travailler, capter leurs émotions, frustrations dans le but de se mettre à leur place et en tirer un maximum d’apprentissages.

Pour cela, nous allons présenter deux outils qui requièrent la sollicitation de 5 utilisateurs à minima par persona identifié, la mise en situation, appelée aussi “Go and see” ou “Shadow” et l’interview.

L’objectif de ces entretiens est de ressentir vous-même les émotions rencontrées afin qu’elles nourrissent plus tard l’élaboration d’une réponse:

• La mise en situation : Cette approche consiste à observer l’expérience utilisateur en situation réelle d’utilisation du produit existant.
• L’interview : Il s’agit ici de mener une série d’entretiens individuels afin d’identifier et comprendre les besoins et frustrations des utilisateurs.

Comment préparer et mener ces 2 entretiens :

Avant l’entretien :

• Lister les utilisateurs à étudier
• Définir les objectifs de recherche
• Définir les hypothèses et/ou principales convictions qui doivent être validées ou invalidées
• Définir les parcours critiques à étudier afin que les utilisateurs préparent des exemples [Mise en situation]
• Rédiger des questions ouvertes non directives impliquant des réponses non biaisées [Interview]

Pendant l’entretien :

• Rappeler les objectifs à l’utilisateur pour faciliter la compréhension de la démarche
• Placer l’utilisateur au centre de l’attention pour qu’il s’exprime
• Observer les réactions, expressions du visage et postures
• Noter toutes les imperfections sans chercher à les résoudre [Mise en situation]
• Noter un maximum de verbatims pour conserver le sens, les émotions et le détail des réponses [Interview]

Les 3 erreurs à ne pas commettre durant les entretiens :

• Ne pas biaiser les réponses, privilégier des questions ouvertes non-directives
• Ne pas parler de solutions durant les entretiens ce qui fermerait la discussion
• Diversifier ses utilisateurs pour avoir des retours d’expérience hétérogènes

Après ces entretiens menés vient le temps de l’analyse…

Pour en savoir plus sur cette étape, n’hésitez pas à lire notre article dédié à la phase de Discovery ICI

2. Analyser les retours pour identifier les préférences

Il est temps d’ouvrir le champ des possibles via l’analyse des interviews utilisateurs et mises en situation, les apprentissages tirés sont la clé pour se forger une conviction produit. Il est nécessaire et très intéressant d’intégrer les équipes techniques et design après un premier travail de l’équipe produit afin d’avoir une vision pluridisciplinaire et de mieux trier les informations reçues pour explorer différentes alternatives.

????N’hésitez pas à conserver des verbatims utilisateurs, c’est ce qui renforce votre discours produit lorsqu’il faut défendre une décision à différents métiers éloignés du terrain !

3. Définir la ou les préférences clés qui vont vous aiguiller durant tout le projet

Jusqu’ici vous avez :

• Mené votre phase de Discovery
• Challengé les apprentissages avec vos équipes
• Mis en lumière vos utilisateurs, les verbatims et leurs préférences sur la Discovery Map

Tout ce travail ne vous dira pas quel choix faire en termes de préférences clés, mais vous avez toutes les cartes en main pour prendre les bonnes décisions produit et apporter une réponse à une ou plusieurs préférences !

????Il est pertinent de s’allier d’un Product Designer pour nourrir sa réflexion et sa créativité.

⚠️Note : Une fois que vous avez mis le doigt sur la ou les préférences clés devant répondre aux besoins des utilisateurs, conservez-les tout au long du projet sur vos supports afin de vous assurer que tout ce qui influe dans le Product Backlog respecte les préférences clés.

Le cas échéant, vous pourrez poser les bonnes questions :

• Est-ce que ce nouveau besoin ajoute de la valeur au produit ?
• Est-ce que c’est un besoin isolé ou répondant à une problématique commune ?

Le temps du partage et de l’alignement des métiers

Le plus dur est fait ! Vous avez :

• Approfondi le contexte métier et compris les enjeux et objectifs
• Appris à connaître et comprendre vos utilisateurs
• Identifié ce qui est réellement important pour répondre à leurs besoins
• Aligné l’équipe sur la vision produit

À ce moment, en tant que Product Owner, vous incarnez la voix de l’utilisateur et avez désormais une conviction forte. L’objectif est maintenant de relier cette conviction au contexte métier et d’embarquer toutes les parties prenantes autour de celle-ci.

La Discovery Card facilite la communication pour convaincre les décisionnaires de votre expertise terrain dont ils sont, pour la plupart très éloignés.

C’est un outil qui tend à simplifier une réalité organisationnelle complexe et qui cache énormément d’effort de recherche, de synthèse et de priorisation. Cela permettra à votre audience d’apprécier les résultats de l’étape de Discovery, de l’enrichir et de s’assurer que le produit va dans la bonne direction.

???? Une fois que les parties prenantes sont convaincues et embarquées, l’équipe peut désormais réouvrir le champ de la réflexion pour apporter des réponses fonctionnelles aux préférences clés.

4. Identifier et prioriser les lots de fonctionnalités

Maintenant, c’est en vous appuyant sur l’expertise des équipes design et techniques que vous identifierez des fonctionnalités différenciantes pour compléter votre Discovery Card :

Concrètement, les fonctionnalités doivent permettre de répondre à ces quatre questions :

• L’utilisateur va-t-il choisir de l’utiliser ?
• Est-ce que l’utilisateur va savoir comment l’utiliser ?
• L’équipe technique valide-t-elle la faisabilité ?
• Est-ce que les parties prenantes sont alignées ?

Une fois le support complet, vous pouvez présenter les lots de fonctionnalités aux équipes décisionnaires en identifiant pour chaque lot :

• Le niveau de priorité
• La préférence clé à laquelle elle répond
• Des macro-estimations techniques
• Les KPIs qui permettront de suivre l’impact des fonctionnalités

Comment suivre les besoins des utilisateurs durant tout le projet ?

Il est pertinent pour les produits avec un cycle de vie long de réaliser plusieurs vagues de discovery afin que l’évolution des besoins utilisateurs fasse évoluer les préférences clés à suivre et ainsi le produit lui-même.

Plusieurs avantages :

• Challenger les besoins produit

L’hypothèse validée il y’a 6 mois ne l’est peut-être plus actuellement.

• S’assurer d’avoir un seuil d’acceptabilité pour chaque préférence clé

L’équipe et les décisionnaires doivent avoir le même seuil d’acceptabilité pour une préférence clé afin de ne pas investir trop d’effort sur des fonctionnalités déjà satisfaisantes.

• Valider la réponse aux besoins utilisateurs

Le travail abattu jusque-là est conséquent, il est important de communiquer sur l’atteinte des objectifs (ou non) et préparer la suite.

• Identifier les nouvelles préférences clés

C’est en étant fréquemment au plus près des utilisateurs que l’on s’assure que les fonctionnalités développées jusqu’à présent ont l’impact escompté mais aussi que l’on prépare les fonctionnalités de demain pour être toujours plus impactant.

Comment cela m’a aidé dans mon quotidien :

J’ai utilisé cet outil en tant que Product Owner chez Bpifrance pour la conception et le pilotage de la livraison du nouveau back-office de traitement des demandes de prêts digitaux des entreprises françaises.

Cet outil a permis de rendre visuel tous les besoins et d’identifier celui partagé par tous les utilisateurs, le plus impactant pour le produit dans leur quotidien. En outre, cela a évité de perdre du temps sur des cas d’usages secondaires ou des besoins isolés remontés par une petite partie des utilisateurs, temps souvent précieux dans des projets avec des jalons prédéfinis.

Une fois les préférences clés identifiées, cet outil m’a permis de mener les ateliers ainsi que de communiquer avec les différents métiers avec ce support pour centrer les réflexions sur ce qui est vraiment important pour les utilisateurs autour du projet.

Finalement, la Discovery Card m’a évité de consacrer des efforts à des tâches qui ne répondaient pas aux besoins des utilisateurs, et de prioriser celles qui ont un véritable impact sur la valeur du produit pour ces derniers tout au long des phases du projet.