Quand on développe un produit, une solution, il y a un enjeu à s’assurer que l’on développe toujours le minimum qui apporte le plus de valeurs à l’utilisateur. Cela suppose que l’on a déjà bien identifié le problème à résoudre suite à une investigation problèmes.

Il y a une raison évidente à cet enjeu qui sonne comme de la bonne gestion, de la limite de coûts, éviter de gaspiller. Au delà du principe qui sonne trivial, ce n’est pas si facile parce que souvent les équipes que j’ai accompagné sont lancées. Elles ont un produit déjà existant et surtout une équipe de production qu’il faut occuper et des clients qui en demandent toujours plus.

L’autre raison c’est que trop de propositions noie votre proposition de valeur. Dans le Running Lean on parle de l’UVP. L’unique proposition de valeur. Quand votre produit commence à faire plein de trucs, il a tendance à tout faire un peu mal et surtout il est plus difficile à positionner et à vendre. Peut-être qu’il vaut mieux multiplier les produits que multiplier les propositions de valeurs dans un produit …

On doit toujours lutter contre la tendance naturelle de penser solution avant tout. Après tout si vous vous êtes lancés dans un projet c’est que vous aviez des idées, des idées de solutions. Et dont c’est naturel chez vous de proposer de nouvelles solutions. Pensez toujours à revenir au pourquoi cette solution, quel problème sous-jacent ? Est-ce toujours une réponse au problème initial de mes utilisateurs que j’essaye de résoudre ?

Et surtout, essayez toujours de tester vos idées de solution le plus vite possible, en limitant l’investissement dans le développement de cette solution pour l’instant. Idéalement, si vous pouviez faire un test sans avoir à produire une ligne de code ce serait top. Une maquette c’est déjà moins cher mais c’est aussi déjà du temps. Parfois pourtant, coder la solution peut-être rapide et peu coûteux, dans ce cas c’est quand même la bonne option. Bref, il y a un arbitrage à faire et une réflexion à mener à ce stade.

L’objectif de cet article est de vous fournir une méthodologie en quelques points pour démarrer une investigation solutions et prendre la décision la plus éclairée possible face à une idée de solution.

Encore une fois, je n’invente rien, j’ai déjà parlé de ce sujet dans mon condensé du running lean, et je vous encourage à lire le running lean.

Dans la démarche du Running Lean il y a une distinction entre les entretiens solutions qui se concentrent sur un élément de l’expérience utilisateur, un problème résolu et les entretiens MVP ou l’on va tester l’expérience globale (de la découverte de l’offre à sa première utilisation). Les deux sont très proches et s’apparentent globalement à la même démarche inspirée de tests utilisateurs guidés par l’usage. Sur ce sujet, je vous recommande de lire un autre bouquin : don’t make me think.

Quand mener une investigation solutions ?

Deux situations :

• En démarrage de projet, vous pensez avoir identifié un problème qui vaut le coup d’être résolu et vous souhaitez maintenant proposer une solution adaptée.
• En cours de projet, vous souhaitez améliorer votre solution en apportant des éléments de peaufinage ou des changements majeurs (genre une nouvelle fonctionnalité, une refonte d’interface, un nouveau parcours utilisateur).

Démarrer une investigation

Ça peut paraître trivial mais je trouve toujours bon de formuler l’intention de l’investigation avant de démarrer une réunion de démarrage d’investigation (ou en tout cas de formaliser cette intention en début de réunion). Par exemple : cette investigation a pour but de tester le tableau de bord qui solutionne le problème « il est difficile d’avoir une vision globale du pipe ». En gros, quelle solution on teste face à quel problème.

Parmi les éléments que vous allez devoir produire pour cette investigation, il y a ce que l’on appellera « l’artefact solution ». L’artefact solution est ce que vous allez présenter à vos prospects ou utilisateurs pour qu’ils se fassent une bonne idée de la solution que vous proposez. Cet artefact peut être juste un pitch, un storyboard, un wireframe, une maquette, un prototype plus ou moins abouti.

Cet artefact solution est l’élément central de votre investigation. Il est important qu’il ne vous prenne pas trop de temps à produire, de minimiser son coût mais en même temps, s’il n’est pas d’assez bonne qualité vous allez faire perdre du temps à vos interlocuteurs (et perdre vous aussi du temps).

Je vous propose donc de résoudre ce démarrage d’investigation en deux séances :

Arbitrage de l’artefact solution

Dans une première réunion d’une heure maximum vous allez cadrer l’intention de l’investigation et les contours de l’artefact solution.

Dans l’ordre, vous allez essayer de produire les éléments suivants (et si vous ne produisez pas tout, vous le finirez sur la réunion suivante) :

• Formalisation de l’intention de l’investigation (comme discutée précédemment)
• Description de la cible des personnes que l’on veut en entretien
• Définir les contours de l’artefact solution
• lister au moins 10 contacts ou un canal d’acquisition qui devrait vous permettre de toucher au moins 10 contacts
• rédiger une trame d’entretien
• rédiger un mail type (ou autre message de recrutement si vous passez par autre chose qu’un mail)
• définir qui mène l’investigation et qui sont ces +1 dans l’équipe (c’est plus confortable d’être deux à mener un entretien, il n’y a qu’une personne qui parle mais l’autre apporte un second regard permettant de questionner et éviter les biais de confirmation positives, il apporte du recul sur la méthode)
• Définir le calendrier de l’investigation : date à laquelle vous allez revoir et valider l’artefact solution, nombre de semaines que vous voulez consacrer à cette investigation (si vous avez notamment des contraintes par rapport à la production, c’est là qu’il faut les formaliser et en tenir compte) et baliser sur les semaines à venir au moins deux demis journées par semaine dédiées aux entretiens
• définir un rdv pour le rituel de suivi hebdomadaire de l’investigation
• brancher votre calendrier à un outil de prise de rendez-vous (par exemple calendly) et mettre le lien pour prendre rendez-vous dans votre mail type
• produire un template de prise de notes
• produire un template de suivi de l’investigation
• organiser l’envoi des mails de recrutement

Comme son nom l’indique, le point clef de cette réunion c’est la définition des contours de l’artefact solution. C’est là dessus que vous devez passer le plus de temps. Le jeu est d’essayer de produire au moindre coût ce qui va donner la meilleure idée possible de votre solution. Alors forcément, le mieux c’est de coder la solution, mais c’est probablement le plus cher. Mais comme parfois ça reste pas cher, ça peut valoir le coup. Donc faites l’exercice des extrêmes :

• commencez par produire, là de suite, le moins cher : juste un pitch écrit de la solution.
• demandez aux personnes de votre équipe solution (qui doit probablement inclure au moins une personne de la production) si sur la base de ce pitch il est déjà possible d’estimer un coût ou temps de production.

Si la réponse à la question de l’estimation du coût est positive : vous avez une estimation de temps ou coût de production mais surtout déjà c’est que votre pitch est clair et donc probablement suffisant.

Si la réponse à la question de l’estimation du coût est négative : il faut demander à l’équipe de quoi ils auraient besoin (quel ou quels artefact(s)) pour se faire une idée.

Je n’ai pas vraiment la formule magique sur comment trancher. Pour moi, il faut prendre la décision en un temps court et peser rapidement le combien ça coûte de faire mieux qu’un pitch, est-ce que l’on peut se le permettre ou pas. Et puis, il faut avoir en tête aussi que probablement que votre première version d’artefact ne sera pas optimisé puisque c’est aussi un but de l’investigation d’améliorer par itération votre proposition de solution.

Lancement de l’investigation

Souvent, lors de la première réunion, on n’arrive pas à produire tout ce que j’ai listé. Parce que la réunion a surtout permis de cerner les contours de l’artefact solution.

Donc la deuxième réunion, celle du lancement officielle elle a deux objectifs :

• finir la liste des points précédents d’éléments à produire
• faire une dernière revue de l’artefact solution qui va servir de support afin de s’assurer que toute l’équipe a le même niveau de connaissance de cet artefact.

Suivre l’investigation de semaine en semaine

Chaque semaine vous allez mener de nouveaux entretiens et consigner vos apprentissages. A la fin de la semaine, vous pourrez produire une synthèse des derniers enseignements. La synthèse doit rester très courte, le plus simple possible.

Ce qui est intéressant à compiler :

• combien d’entretiens ont été menés
• les profils des interlocuteurs
• la liste des 3 principaux comportements surprenants (ou problèmes de l’artefact). Le but étant d’identifier s’il faut améliorer la solution ou si vous faites carrément fausse route.
• éventuellement des enseignements supplémentaires (opportunité, éléments de vocabulaire, mises en relation … )
• éventuellement des points à améliorer dans votre trame d’entretien

Lors du rituel de début de semaine, vous présenterez à l’équipe ces éléments par transparence, pour que tout le monde soit au même niveau d’information et pour que les uns et les autres puissent vous fournir du recul et éviter vos propres biais. Si nécessaire durant ce rituel, vous modifierez votre trame d’entretiens ou votre choix de cibles. Vous aborderez également le planning de la semaine à venir.

Dans un rythme idéal, celui qui est présenté dans le running lean, vous devriez mener 10 entretiens par semaine.

Mener un entretien solution

C’est surtout sur ce point que la lecture de Don’t make me think vous sera pratique.

Un entretien solution c’est 20 min et 10 min pour mettre au propre vos notes. Essayez de ne rien écrire pendant l’entretien et de synthétiser rapidement après l’entretien en une page.

L’entretien solution il démarre par un minimum de questions démographiques (le contexte, vérifier que l’interlocuteur est dans la cible, éventuellement prise de quelques infos qu’il vous manque en terme de connaissance utilisateurs), puis on reformule le problème adressé pour valider là encore que l’interlocuteur est la bonne cible (si jamais il dit « bah non j’ai pas ce problème moi », il faut basculer en entretien problème), et ensuite on lance la démo.

L’idée de la démo c’est que vous devez parler le moins possible et laisser l’utilisateur découvrir la solution. Pour cela, il vous faut :

• mettre l’utilisateur à l’aise sur le fait que vous ne jugez pas sa performance, qu’il est observé mais qu’il n’y a pas de mauvais comportement, c’est la solution que l’on juge.
• l’inviter à penser à haute voix pendant qu’il manipule l’artefact, qu’il exprime son ressenti et sa démarche de parcours.
• lui donner une tâche précise à réaliser (précise mais large, le but c’est pas de lui dire de cliquer sur un bouton, mais de traiter une situation d’usage par exemple : nous aimerions que vous procédiez à une inscription et que vous déposiez votre premier projet).

Personnellement, les entretiens solutions, je trouve ça bien de les filmer. La plupart je ne les garde pas. Mais c’est parfois pratique pour les membres de l’équipe qui ne l’ont pas vu, et quand on relève un comportement surprenant, le montrer est plus efficace que le raconter. Si vous choisissez de filmer, pensez bien à demander l’autorisation en début d’entretien.

Toujours de bons conseils :

• avoir en tête de parler le moins possible, vous êtes là pour écouter
• même si vous êtes deux personnes à suivre l’entretien, essayez de faire en sorte qu’il n’y en ait qu’un qui parle
• proposer le tutoiement dès le début
• suivre la trame d’entretien
• maîtriser le temps
• ramener à une formulation simple des problèmes, reformuler et faire valider la reformulation
• ne pas oublier de faire prioriser les problèmes
• n’oubliez pas de demander des contacts pour mener d’autres entretiens
• garder 5 min après ou en fin d’entretien pour prendre des notes

Views: 30