Discovery, comment dérisquer sans gaspiller ?

Référence : https://www.meetup.com/fr-FR/think-tak/events/286031784/

Product Discovery

Le double diamant :

• diverger, puis converger autour du problème du client, pour bien en comprendre la nature;
• diverger, puis converger autour de la solution pour en réduire le risque.

C’est un peu être un christophe Colomb du produit : on part en cherchant une solution, et on va potentiellement revenir avec une autre : celle qui correspond réellement au besoin du client.

Prendre le temps du discovery ?

L’analyse poussée du discovery peut être appréhendée à cause du risque de revenir avec une solution totalement différente qu’envisagée initialement, le fait de partir dans l’inconnu.

Il faut donc donner un bon cadre, pour que l’expédition du discovery ne soit pas sans fin, et permettre d’expliquer la démarche aux parties prenantes.

Le risque est de confondre une activité exploratoire avec une activité sans cadre : partir à la recherche de la solution ne veut pas dire partir dans toutes les directions, mais de suivre une démarche bien définie (analyse du besoin, analyse des utlisateurs, etc.).

“Discovery” signifie bien “découverte”, et pas “inventer” une solution.

Il est important de communiquer justement sur la discipline et le cadre nécessaire à la démarche de discovery, pour rassurer les parties prenantes.

Qui doit être embarqué dans la discovery ?

Cela dépend du problème, du besoin à étudier. Quoi qu’il en soit, il vaut mieux inclure une partie significative des personnes suceptibles d’être ensuite concerné par le produit, pour éviter cette impression que le Product Manager fait son travail tout seul dans son coin.

Maintenant, il faut être prudent et éviter de se retrouver avec 40 personnes dans le discovery.

Il faut prendre en compte les risques potentiels du produit dans le choix des personnes à impliquer. Il faut donc prendre le temps d’une analyse du risque en amont. Par exemple, on peut avoir besoin d’une personne du juridique, s’il y a implication de questions légales.

Cadrer le travail de discovery

Le groupe doit ensuite trouver “le” cas d’usage sur lequel va se faire la suite du travail. Il peut y avoir en effet plusieurs cas d’usages, mais il vaut mieux se centrer sur un cas bien précis, avec une cible bien identifiée, et un besoin bien particulier.

C’est après avoir identifié ce cas d’usage qu’on peut réfléchir à comment on va le traiter (collecte d’infos, etc.), et ensuite réfléchir aux différentes solutions potentielles. Le cadre défini au début permettra ensuite de sélectionner la solution adéquate. Le cadre peut être vu comme la carte de l’explorateur, grâce à laquelle on va orienter l’exploration des solutions.

Remarque : autant le choix du cas d’usage à traiter, que le choix de la solution devrait déjà correspondre à la stratégie de l’entreprise (marché, valeur, etc.).

Cadrer le discovery implique également de faire un compromis entre temps passé à explorer et la prise de risque sur le choix d’une solution finale. Trancher cette question dépend de l’enjeu du besoin à l’étude. Il faut donc penser à l’enjeu avant de se lancer à corps perdu dans la démarche de discovery (cf. RICE: Reach * Impact * Confidence / Effort).

Le discovery pourra également être cadré à l’aide de livrables dont le rôle sera d’orienter la démarche vers “la” solution que l’on souhaite mettre en œuvre. Ils devront par exemple assurer qu’on ne cherche pas une solution à tout les problèmes, mais centré sur notre cible.

Quelques idées de livrable pour le discovery :

• la définition claire du besoin à traiter;
• l’idée de tweet, évoquée plus bas, peut faire office de livrable permettant de montrer qu’on est sur la bonne voie, dans le choix de la solution;
• etc.

Savoir confirmer le problème

Attention également à ne pas chercher absolument à trouver une solution à un problème se trouvant, pour une raison ou une autre, hors de notre portée (solution trop complexe à mettre en œuvre, solution dégradée, apportant plus de problèmes que de solution, etc.).

Savoir recadrer

Le Product Manager doit être constamment à l’affût des dérives, et s’assurer que la démarche suit le plan défini initialement.

Une idée pour savoir si on est sur une bonne piste de solution, c’est de tenter de rédiger une réponse au client (format tweet, par exemple) lui assurant d’avoir une solution (pas juste dire “j’ai la solution”, mais indiquer plus d’éléments). Si on est pas capable de renseigner sur le livrable, si une réponse ne vient pas naturellement, c’est que la solution n’est pas satisfaisante.

Continuité après discovery

Le Product Manager doit resté impliqué dans la réalisation de la solution après que celle-ci ait été sélectionnée. Cette implication permet au Product Manager d’être plus à même d’identifier une solution réaliste, lors de la démarche de discovery.

Il est également possible de faire du “continuous discovery” pour être capable de conduire la démarche de réalisation de la solution par des échanges réguliers avec les utilisateurs finaux.

Au final, le temps investi en discovery doit permettre de maîtriser le risque que la solution retenue pour le delivery sera une solution viable, pas forcément parfaite, mais apportant une bonne réponse au problème identifié.

D’où l’importance de bien cadrer le delivery et de bien maîtriser le contexte du besoin.