Vous avez un problème ?

Dans l'exercice de ses missions quotidiennes, le product manager est quasi systématiquement soumis à des demandes d'évolution prêtes à l'emploi. Et pourtant...

"Il me faut ci pour que ça marche", "le prospect demande ça pour acheter", "cette fonctionnalité est in-dis-pen-sable"… tout Product Manager fait cette expérience de voir des demandes d’évolution supposées matures tenter d’infiltrer son backlog. 

Parfois, elles s’expriment sous la forme d’une simple description orale, parfois les demandeurs prennent soin de faire quelques dessins d’écran pour étayer leur demande et en illustrer la criticité. (Parfois aussi on vous adresse un torchon gras rédigé sur une nappe en papier également tachée de vin rouge qui finit dans son habitat naturel : la poubelle).

Lorsque ce type de situation se produit, j’ai l’habitude de poser une simple question : « quel est le problème ? »

Spontanément, et quasi systématiquement, lorsqu’un problème se présente, l’information est relayée sous forme de solution aux équipes PM et de Développement. Or, cette démarche présente quelques inconvénients non négligeables.

Les inconvénients d'une solution toute trouvée

  • Le plus souvent, la solution envisagée vise à résoudre un problème spécifique et conjoncturel. Or, le rôle du product manager est de s’assurer que l’offre dont il est responsable sert l’ensemble d’un marché et non une organisation en particulier. Il peut donc exister une autre réponse à un problème, plus universelle même si elle n’est pas exactement celle a priori imaginée par l’émetteur. Et le cas échéant, si le problème exprimé s’avère terriblement spécifique et conjoncturel, il faudra savoir dire non…
  • Les demandes d’évolution n’échappent pas aux aléas de la transmission orale. En d’autres termes, du problème ressenti à la solution exprimée, il y a déjà souvent un premier niveau de déformation. Quand la solution est exprimée par le DAF à son chef de projet pour le product manager à destination des équipes de développement, cela accumule le bruit et les risques d’incompréhension. Bref, que la demande émane d’un tiers ou de l’interne (le commerce pour son prospect, un consultant pour son client ou votre direction générale) la démarche doit invariablement consister, pour le PM, à revenir à son émetteur initial - le client / prospect / marché - et à la verbalisation du problème sous-jacent.

Remonter au problème, gage d'efficacité

Le champ des possibles est plus large que ce que l’on imagine. Les solutions brident l’imagination. Or, ll peut exister un équivalent (voire mieux) pour moins cher. Il peut aussi exister une réponse en rupture qui fera de vous un créateur génial (voir le propos d’Henri Ford passé au statut d’aphorisme : "si je n'avais écouté que mes clients, j'aurais inventé un cheval plus rapide"). En fait, revenir au problème implique de le contextualiser : quelle en est la criticité, qui en souffre, avec quel pouvoir d’achat, quelle est sa fréquence etc… Un contournement sera plus facilement "vendable" s’il concerne un point de douleur occasionnel plutôt que quotidien. A l’inverse, un problème constant méritera une réponse plus travaillée et sera peut-être la cause du succès fulgurant de votre offre.

Une bonne pratique ne va pas toujours de soi

La mise en œuvre de cette démarche est question d’éducation et de maïeutique tant la recherche spontanée de solution semble inscrite dans notre ADN. Il faut casser ce réflexe si vertueux en d'autres circonstances et imposer une nouvelle manière. Par exemple, lors de la mise en place de formulaires de demande d’évolution, je prends le soin d’expliquer le fait que la description du besoin doit se focaliser sur le problème et qu’il ne sera creusé qu’à cette condition. Qui sort du cadre se verra demander : "quel est le problème ?" et l’enregistrement du ticket en backlog ne se fera qu’une fois le contenu bien renseigné. Frustrant pour certains, mais efficace pour tous !