Ne donnez pas à votre utilisateur ce qu’il veut, mais plutôt ce dont il a besoin.

Comme j’aime le répéter, un produit est créé au travers d’un, ou plusieurs projets, pour résoudre un problème.

Mais la question à se poser c’est : le problème de qui ?

Évidemment, c’est le problème de vos utilisateurs, et, ou, de votre client.

Un projet est toujours déclenché pour résoudre ce fameux problème, et cela permet d’apporter un bénéfice pour votre client, un bénéfice financier principalement, mais un bénéfice, aussi aux utilisateurs qui, eux, auront plutôt un bénéfice orienté usage ou utilité.

Mais pour le résoudre, il faut le comprendre.

On a coutume de dire que pour comprendre l’origine d’un problème, il faut échanger avec les utilisateurs pour avoir des informations.

Ce qui est vrai : il faut récupérer un maximum d’information pour comprendre :

• La localisation du problème
• Les conséquences du problème
• Les racines de la cause du problème
• Ce qui le déclenche et ce qui permet, actuellement, de diminuer son impact.

Et tout un tas d’autre information permettant de comprendre le problème dans sa globalité.

En échangeant avec votre utilisateur, vous n’allez pas trouver la solution.

Vous allez juste comprendre ce qui ne va pas, ce qui doit être changé, réparé, améliorer, ou bien ce qui doit être installé ou mis en place pour résoudre ce fameux problème.

Et le risque, c’est de beaucoup trop écouter son client, ou son utilisateur, au point qu’il nous dise ce qu’il faudrait mettre en place pour le résoudre.

« Il faut changer les équipements informatiques, car ils sont lents, ils rament, on ne peut pas envoyer de fichier rapidement, et je ne peux pas brancher ma clé USB perso. Je voudrais bien qu’on change le PC pour régler ce problème. »

Bon. En écoutant ce genre de discours, on imagine facilement que son problème ne vient pas de son PC. Il faudra faire un audit du réseau interne et externe, également des infrastructures comme les serveurs, car le problème peut potentiellement venir, aussi, d’un de ces points.

Et c’est ici qu’il faut faire attention. Car même si cet exemple est grossier, les utilisateurs sont souvent persuasifs, voire même malins. Et il est facile de céder à tout leur caprice pour acheter une « paix sociale ».

Si vous devez lancer un projet, vous allez forcément commencer par une analyse de l’existant, comprendre d’où vient le problème, puis analyser le besoin réel afin de lancer le projet.

Et l’objectif, c’est d’éviter, comme j’aime l’appeler, le syndrome de la liste de cadeaux de Noël.

Une analyse du besoin n’est pas une liste d’exigences ou de caprices de l’utilisateur ou du client.

Lorsqu’on doit lancer un projet, la seule chose qui doit nous rester en tête, c’est d’être concentré sur la résolution du problème.

Pour cela, cette phase d’analyse du besoin est extrêmement longue, pour comprendre l’ensemble des causes du dysfonctionnement du système, des process, de l’organisation, etc.

Cette analyse doit amener à une conclusion logique de la raison du problème, et de la solution qui sera mise en place pour le résoudre.

Cette analyse n’est donc pas une checklist des souhaits ou des volontés des utilisateurs finaux ou de votre client.

En tant que chef de produit, Product Owner, ou même chef de projet MOA, votre responsabilité est de faire comprendre à vos parties prenantes que comprendre le besoin est une longue phase d’investigation, de réflexion, de test, d’analyse, et c’est un travail de groupe.

Tout le monde doit participer à cette analyse. Pour avoir une analyse la plus précise possible, grâce aux informations de chacun, et l’intelligence collective.

Même celle des techniciens de l’équipe projet qui va réaliser techniquement le produit, si cette équipe est déjà constituée.

L’objectif d’un projet n’est donc pas de donner aux gens ce qu’ils veulent, mais plutôt de comprendre la raison profonde de leur « douleur », du problème constaté, et de les aider à sortir la tête du guidon pour éviter la fameuse liste de Noël.

L’utilisateur n’a pas besoin du dernier téléphone ou ordinateur dernier cri. Il a besoin de communiquer, d’échanger des informations, des fichiers, ou bien d’utiliser les process de l’entreprise pour produire, en fonction de ses responsabilités qui lui sont propres.

Gardez en tête que, lorsqu’on fait un projet, le premier objectif, c’est de résoudre le problème avec une solution efficace. Mais c’est aussi, et surtout, de dégager de la valeur.

La valeur pour un produit se traduit par sa capacité à résoudre efficacement le problème, mais aussi de pouvoir le créer et le mettre en place en dépensant le moins possible. En temps, en argent, en ressource.

En fonction de ce qu’on dépense pour obtenir notre produit, son efficacité pour résoudre le problème, et les bénéfices que nous obtenons (bénéfices financiers principalement, mais pas seulement.), nous obtiendrons plus ou moins de valeur.

Et pour cela, vous devez comprendre le besoin de vos utilisateurs pour avoir une vue objective et pragmatique du problème à résoudre en écartant les solutions qu’ils vous suggèrent. Car généralement, ces solutions sont surtout des solutions de conforts qui coutent cher, plus que de réelles solutions, qui, en plus, ne résoudront jamais le problème constaté.

Afin d’éviter ce genre de situation, c’est votre capacité à communiquer, et à faire la part des choses qui fera la différence.

Éviter de tomber dans la condescendance envers votre interlocuteur, et essayer de retirer un maximum d’information, même celles qui vous semblent les moins utiles. Notez-les, car parfois, l’utilisateur peut aussi avoir raison. Mais dans la très grande majorité des cas, cela servira surtout à faire un peu de politique, en promettant que les options suggérées seront analysées, mais qu’il faudra creuser le sujet pour confirmer cette affirmation.

L’utilisateur se sentira entendu, et vous pourrez revenir pour expliquer la réelle cause du problème quand elle sera détectée, pour, en plus, leur demander de participer à la mise en place d’une solution qui leur sera utile.

Par la suite, il faudra que vous déterminiez les fonctions de service de votre produit.

Généralement, on mène une phase d’analyse fonctionnelle externe du produit pour cadrer l’ensemble des fonctions de services, car tous les produits ont ce genre de fonctions.

Ces fonctions décrivent le service que va rendre le produit à son utilisateur et qui permettra de résoudre le problème.

Ma solution va permettre à mon utilisateur d’envoyer des fichiers de 1 Go en moins de 1 minute, de sauvegarder l’ensemble des documents de la direction 1 fois par jour, de partager et de stocker des fichiers sur un espace de stockage de 500 go sécurisé et protégé, etc.

Ces fonctions de services seront les fondations de votre produit, qui vous permettra, à vous, chef de produit, ou équipe projet, de concevoir une solution sur mesure, adaptée au problème de vos utilisateurs, qui dégagera un maximum de valeur possible.

La partie délicate sera d’inclure l’ensemble des parties prenantes dans cette phase de résolution de problème, sans devoir jouer au père Noël et leur apporter tout ce qu’ils veulent, à l’exception d’un produit pertinent et efficace.

Pour cela, il vous faut faire preuve d’un détachement complet des solutions techniques, comprendre le besoin réel en étant focalisé sur la partie fonctionnelle, et cela, que ce soit pour un projet en prédictif, ou bien en Agile.

Toute votre conception produit, et votre gestion de projet, dépendra du besoin, et non pas d’une liste d’exigence déconnectée de la situation.

Vous devez vous placer dans une posture d’expert, de leader, mais aussi de négociateur, en prenant bien conscience que vous allez devoir convaincre, avec tact, que votre utilisateur/client à tort de demander ou de proposer une solution dès le départ. Que de comprendre la réelle cause de cette situation prend du temps, que trouver LA solution prend du temps également, et que, souvent, nous sommes très loin de l’identifier dès le début.

Un chef de projet ou de produit doit aider les parties prenantes, mais il doit savoir dire non, avec des arguments forts, lorsqu’il estime que les gens font fausse route.

Pour finir, ne tombez pas, vous aussi, dans LA solution qui vous semble la plus pertinente de prime abord.

Et oui, ce qui est valable pour votre utilisateur vaut pour vous aussi. Restez détacher des solutions, et restez concentré sur le résultat à atteindre. Donc, sur la phase fonctionnelle de votre produit.

N’hésitez pas à vous entourer de personne de confiance, expérimentez, pour vous permettre à vous aussi de rester sur le bon chemin.

Également, apprenez les outils qui vous permettront de définir un produit fonctionnel, avant de définir un produit technique.

Intéressez-vous sur la conception produit, et les outils logiques.
L’analyse fonctionnelle externe est un excellent outil autant sur le volet pratique que sur le volet pédagogique pour construire cette logique. Et vous extirper de la solution. Ou certaines techniques de Design Thinking.
Agile a cette vocation également, avec la création du product backlog, et les techniques associées comme les user stories. Les users stories ne sont que des fonctions de services orientées utilisateur.

Mais afin de ne pas partir vers la mauvaise direction, comprenez l’origine du problème, écartez toute solution, surtout celles de vous utilisateurs, tant que vous n’aurez pas compris concrètement ce que le produit doit rendre comme service.