Mon besoin est … Non, revenons plutôt à ton problème

Silvere Duval
5 min readFeb 12, 2024

--

“Alors Métier, explique-moi. Quel est ton besoin ?” — Un Product Owner.

“Ca tombe bien que tu m’en parles ! J’ai besoin que tu me crées un écran avec 3 boutons pour que l’utilisateur puisse choisir le type de validation qu’il souhaite.” — Son Métier.

🛑 S T O P !

⏮ Rembobinons tout !

Pourquoi rembobiner ce qui vient d’être dit ?

Source : Pixabay

Sachez qu’en entendant le mot “besoin”, votre interlocuteur va spontanément vous parler de sa “solution” qui :

  • N’est — pas forcément — la bonne,
  • Risque de vous conditionner dans vos futures réflexions.

De plus, vous devrez alors choisir entre 2 postures :

  • La posture d’exécutant (vous savez le fameux “client/fournisseur”). Vous allez faire exactement ce que demande votre Métier,
  • La posture “owner” de votre Produit. Vous réorienterez la discussion en indiquant à votre interlocuteur qu’il est en train de vous donner une solution alors que vous souhaiteriez qu’il vous explique le problème qu’il souhaite résoudre avec vous.

Evidemment, en tant que Product Owner, vous choisirez la 2ème posture !

Bon, revenons au “problème” ?

“Problème : Difficulté mettant dans une situation pénible, contraignante, contrariante” — Le Larousse.

Pour éviter cette ambiguïté entre “besoin” et “solution”, parlez plutôt de “problème” à votre Métier. Même si ce mot peut avoir une connotation négative, n’ayez pas peur de le dire car si votre interlocuteur vient vous voir, c’est bien parce que son client ou son utilisateur final a un problème qu’il ne sait pas résoudre … Si c’est trop “violent”, parlez plutôt de “problématique” pour que ce soit plus “soft”.

Quelques exemples de problème :

“Le client n’a plus de logement suite à un sinistre et ne sait pas quand il pourra faire des travaux pour retourner chez lui car le service client n’est pas joignable”.

“Le client a envoyé un courrier extrêmement important vers l’étranger, mais il ne sait pas s’il a été réceptionné et ne sait pas qui contacter”.

Comprendre pour prioriser

Source : Unsplash

C’est sur cette base que vous allez récupérer des informations qui vous permettront de prioriser :

  • Pour qui allez-vous travailler ? Quelle est la population touchée par ce problème ?
  • Combien de personnes sont touchées ? Une minorité ? Une majorité?
  • Est-ce une population sensible ?
  • Comprendre le problème et en mesurer la nature et son ampleur pour avoir une solution adaptée. N’hésitez pas à reformuler pour vérifier que vous l’avez bien compris.

Une fois ces éléments recueillis, vous pourrez prioriser ce sujet en fonction de son degré d’importance.

Mais, est-ce vraiment un problème ?

« Si j’avais demandé aux gens ce qu’ils voulaient, ils auraient répondu des chevaux plus rapides. » — Henry Ford.

Ne vous contentez pas de ce que vous dit votre Métier car le problème exprimé n’est — peut-être — pas celui a résoudre. Vous devrez chercher à connaître et à comprendre l’utilisateur final pour découvrir ses attentes qu’il n’arrive pas toujours à exprimer.

Vous connaissez le “Biais de cadrage” ?

“Il y a quand même 7% des utilisateurs qui rencontrent ce problème. Il faut faire quelque chose au plus vite !” — Un Métier

Restez bien vigilant.e durant le recueil des informations. Sachez qu’il existe un “biais de cadrage” qui désigne l’influence que peut avoir la formulation d’un problème sur la réponse qui y est apportée.

Dans notre exemple, vous constaterez qu’il faudra relativiser le problème car 93% des utilisateurs ne rencontrent aucun soucis.

La collecte d’information et leurs analyses

Sources : Unsplash

On ne dit plus “je pense”, mais “je mesure”.

Vous pouvez vous faire aider de vos UX Designers pour rassembler toutes les informations pertinentes, mener une analyse approfondie et évaluer plusieurs facteurs.

  • La data : Les données quantitatives et qualitatives peuvent vous aider à déterminer si le problème est réel ou basé sur des suppositions,
  • Le feedback utilisateur,
  • L’observation sur le terrain.

Vous découvrirez peut-être qu’il existe déjà des solutions de contournement qui répondent totalement ou partiellement au problème. Peut-être qu’il suffira de les déployer à plus grande échelle ?

Une solution veut dire abandonner ses habitudes

Le coût du changement peut être plus élevé que le problème !

Source : Decouvrir la courbe du changement de Kubler Ross avec Julie Dupuis — Extrait Café Virtuel #002 — YouTube

N’oubliez pas la résistance au changement. Aussi, il faut se demander si le problème vaut la peine d’être résolu, c’est à dire si la solution va créer suffisamment de valeur pour l’utilisateur pour qu’il décide de changer ses habitudes.

Un moyen très simple de le savoir. Demandez-lui ce qu’il fait actuellement pour contourner le problème. S’il ne fait rien, c’est que le problème ne vaut pas la peine d’être résolu !

En conclusion

Analysez bien le problème avant de vous lancer tête baissée dans une solution car vous pourrez rencontrer des différence entre ce que le Métier vous dit et la réalité de la situation.

“Si j’avais une heure pour résoudre un problème, je passerais cinquante-cinq minutes à définir le problème et seulement cinq minutes à trouver la solution.” — Albert Einstein.

💡Un Tip : Engagez-vous plutôt sur la résolution d’une problématique et pas sur une solution et des fonctionnalités.

--

--

Silvere Duval

Product & Agile Transformation Consultant /Product Owner at AXA France— “From a Project culture to a Product culture”