Dans le développement de produits digitaux, la capacité à recueillir, analyser et prioriser les besoins est au cœur de la création de valeur. Cette compétence essentielle dépasse les frontières des métiers et mobilise l'ensemble des acteurs du produit.
Afin de faciliter la collecte et l’analyse des besoins, il faudrait d’abord comprendre qu’est-ce qu’un besoin?
I. Besoin, qu'est-ce que c'est?
“Un vrai besoin utilisateur est un problème non résolu ou une opportunité non exploitée qui, une fois adressée, crée de la valeur pour le client et l’entreprise.”
- Marty Cagan (2018), Inspired : How to Create Tech Products Customers Love
Cette définition met en lumière la création de valeur à tout besoin authentique. Elle part d’une douleur utilisateur (problème non résolu), ou d’une aspiration (opportunité non exploitée) pour se transformer, après traitement, en valeur partagée - à la fois pour le client et pour l’organisation.
Les besoins émergent de différentes sources, comme le détaillent Wiegers & Beatty (2013) dans Soft Requirement, les besoins proviennent principalement de trois sources interdépendantes :
- Les utilisateurs finaux : ils expriment des besoins explicites (demandes directes) et latents (non formulés, mais révélés par l’observation ou l’analyse comportementale).
- Les parties prenantes business : leurs besoins relèvent souvent de contraintes stratégiques (ROI, time-to-market) ou externes (réglementations, conformité).
- Les contraintes techniques et marché : L’évolution technologique (ex. : compatibilité mobile) ou les attentes implicites du marché telles que les standards d'accessibilité WCAG ou les exigences de performance web) génèrent des besoins que le produit doit intégrer pour rester compétitif.
L’art du Product Management consiste à concilier ces sources, parfois contradictoires, en priorisant ce qui crée le plus de valeur à la fois pour l’utilisateur et l’entreprise. Mais très souvent, quand nous avons collectés de nombreux besoins en main, nous trouvons qu’ils ne se valent pas, et une confusion fréquente existe entre le besoin utilisateur (User Need) et le besoin produit (Product Need). Comprendre cette distinction est essentiel pour éviter de construire des fonctionnalités inutiles ou mal adaptées.
II. User Need et Product Need
Le User Need représente la perception qu'a l'utilisateur de son problème, qu'il formule souvent spontanément sous forme de solution concrète. Par exemple, un utilisateur pourrait dire : "Je veux un bouton plus gros sur cette page". Cette demande, bien que légitime, n'est qu'une proposition de solution de sa part.
"Les utilisateurs ne peuvent pas toujours expliquer leurs vrais besoins. Il faut les observer en action."
- Beyer & Holtzblatt (1998), L’observation ethnographique
Le Product Need, quant à lui, émerge après une analyse approfondie menée par l'équipe produit et développement. Cette analyse multi-facettes s'appuie sur :
- L'observation terrain (shadowing, tests utilisateurs) pour comprendre les comportements réels
- Les données quantitatives (analytics, taux de conversion) pour objectiver les problèmes
- Les retours clients (interviews, support) pour saisir les frustrations exprimées
- La vision stratégique pour aligner la solution avec les objectifs business
- Les contraintes techniques (dettes existantes, délais de livraison, capacités du système d'information) qui façonnent la faisabilité et le calendrier
Reprenons notre exemple : derrière la demande "Je veux un bouton plus gros", l'analyse pourrait révéler que les utilisateurs ne parviennent pas à identifier les actions principales dans l'interface. Le product need serait alors : "Assurer une découvrabilité optimale des actions principales".
Cette distinction est cruciale : le Product Need définit le problème business à résoudre, tandis que les solutions peuvent être de différentes natures. Une solution technique, comme la refonte de la hiérarchie visuelle, pourrait adresser le problème à sa racine; une évolution des processus via la formation des utilisateurs aux bonnes pratiques; un changement organisationnel, tel que la révision des rôles et responsabilités; ou une amélioration communicationnelle avec des guides d'utilisation et tutoriels.
Les utilisateurs formulent naturellement leurs besoins sous forme de solutions concrètes ("Je veux un bouton plus visible"), car c'est ainsi qu'ils imaginent résoudre leur problème. Cependant, notre rôle en tant qu’expert produit est de creuser plus profondément pour chercher la problématique de la solution.
Regardons une petite histoire :
Imaginons Marc, un livreur à vélo qui parcourt 50 km par jour. Un matin, il dit à son manager : "J’ai besoin d’un vélo plus léger !"
Besoin utilisateur (User Need) : "Je veux moins me fatiguer en livrant les colis." (Problème réel)
Besoin produit (Product Need) : Un vélo électrique ? Une optimisation du trajet ? Une assistance ergonomique ?
Le manager, en creusant, découvre que Marc passe 30% de son temps à chercher des adresses. Le vrai besoin n’était pas le poids du vélo, mais gagner en efficacité logistique. La solution produit devient alors : une appli de navigation optimisée (au lieu d’un nouveau vélo). L’histoire de Marc le livreur illustre un piège classique en product management : confondre la solution exprimée ("un vélo plus léger") avec le problème réel ("je me fatigue trop").
En résumé :
- User Need = Ce que l'utilisateur ressent comme problème
- Product Need = Ce que le produit doit accomplir comme résultat business
- Solution = Les moyens (techniques, process, organisationnels, formation...) pour y parvenir
Pour récolter les vrais besoins, il est crucial de reconnaître cette différence fondamentale : écouter une demande, c'est entendre une solution proposée, tandis que comprendre un besoin, c'est identifier le problème sous-jacent à résoudre.
III. Comment bien différencier et traiter ces besoins?
L'analyse des besoins est un processus de traduction : à partir des besoins exprimés par l'utilisateur (User Need), identifier les aspirations intimes de l'utilisateur et les transformer en product need. Cette démarche exige une écoute active et une remise en question systématique des demandes apparentes.
Quelques exemples concrets :
Cas 1 : Plateforme e-commerce
Demande utilisateur : "Ajoutez un filtre ‘prix croissant’."
User Need : "Je veux trouver un produit dans mon budget rapidement."
Product Need :
- Redesign de l’UI des filtres (pas juste ajouter un bouton).
- Algorithme de tri optimisé (performance technique).
Cas 2 : SaaS B2B
Demande client : "Nous voulons un export Excel des données."
User Need : "Je dois analyser ces KPIs hors ligne pour mon reporting."
Product Need : Un export Excel ? Peut-être. Mais aussi : une API (Interface de Programmation Applicative) d’export ? Un connecteur BI (Business Intelligence)? (Selon l’usage réel)
Le piège de l'expertise technique :
Comme beaucoup de Product Owners issus du technique, il est tentant de : 1. Prendre les demandes utilisateurs au pied de la lettre ; 2. Se précipiter sur la conception système.
Résultat ? Des solutions techniquement élégantes... mais qui manquent leur cible.
Face à ce défi récurrent - des solutions techniques disproportionnées par rapport aux besoins réels - j'ai trouvé dans la méthode des 5 Pourquoi, un outil puissant pour éviter les biais d'interprétation. Cette approche systématique, issue du Toyota Production System (Ohno, 1988), permet de remonter à la véritable racine des problèmes :
- "Pourquoi voulez-vous cet export ?" - "Pour analyser les ventes mensuelles"
- "Pourquoi analyser ces ventes ?" - "Identifier les produits sous-performants"
- "Pourquoi les identifier ?" - "Adapter nos promotions"
- "Pourquoi cette adaptation ?" - "Maximiser notre marge globale"
- "Pourquoi maintenant ?" - "Nous perdons 15% de chiffre d’affaires sur ces produits"
Besoin réel = "Alertes automatiques sur les produits à marge critique" (bien différent du simple export demandé initialement).
Exercice pratique : La prochaine fois qu'un utilisateur formule une demande, essayez de :
- Reformuler son besoin en termes de problème ("En fait, vous voulez...").
- Identifier 3 solutions alternatives radicalement différentes.
- Tester la plus simple d'abord.
Conclusion
Comme nous l'avons exploré, la distinction entre User Need et Product Need n'est pas qu'une subtilité sémantique - c'est la clé pour créer des produits qui apportent une réelle valeur. Notre rôle en tant que professionnels du produit ne consiste pas à être de simples exécutants des demandes utilisateurs, mais bien à être des traducteurs de besoins et des architectes de solutions.
La méthode des 5 Pourquoi, les observations terrain et le recoupement des sources d'information nous aident à dépasser les solutions superficielles pour atteindre l'essence même des problèmes à résoudre. Rappelons-nous que, comme le soulignait Marty Cagan, "les grands produits ne naissent pas de longues listes de fonctionnalités, mais d'une compréhension profonde des besoins non satisfaits".
Sources bibliographiques
1. Cagan, M. (2018) - Inspired: How to Create Tech Products Customers Love
2. Wiegers, K. & Beatty, J. (2013) - Software Requirements
3. Beyer, H. & Holtzblatt, K. (1998) - Contextual Design: Defining Customer-Centered Systems
4. Méthode des 5 Pourquoi : Toyota Production System. Source pratique : Le Blog du Dirigeant - Les 5 Pourquoi
5. Théorie des Jobs To Be Done : Christensen, C. M. et al. (2016) - Competing Against Luck.
Articles recommandés
1. Nielsen Norman Group - User Need vs. Business Need
2. Harvard Business Review - Knowing Your Customers' "Jobs to Be Done"
