Une idée n'est pas encore un produit
Une idée est une hypothèse de solution. Elle devient un produit lorsqu'elle répond à un problème suffisamment important pour un groupe d'utilisateurs identifiable. Les cinq questions à répondre avant d'écrire une ligne de code.
Beaucoup de projets commencent par une phrase comme :
« Et si nous développions une application qui permet de… »
Le problème, c’est qu’à ce moment-là, nous parlons déjà de la solution.
Nous ne savons pas encore :
- qui rencontre réellement le problème ;
- dans quelle situation il apparaît ;
- comment il est résolu aujourd’hui ;
- pourquoi les solutions actuelles sont insuffisantes ;
- ce qui pourrait pousser l’utilisateur à changer.
Une idée est une hypothèse de solution. Elle devient progressivement un produit lorsqu’elle répond à un problème suffisamment important pour un groupe d’utilisateurs identifiable, délivre une valeur compréhensible et provoque un comportement que nous pouvons observer.
Avant d’écrire la première ligne de code, je cherche donc à répondre à cinq questions.
1. Qui rencontre précisément ce problème ?
Pas « les entreprises », « les étudiants » ou « les restaurants ».
Ces catégories sont trop larges pour orienter une décision produit. Elles regroupent des personnes aux besoins opposés, aux contraintes différentes, aux priorités incompatibles. Un restaurant étoilé et une pizzeria de quartier n’ont pas les mêmes besoins produit — les décrire ensemble revient à ne décrire aucun des deux.
Il faut identifier un groupe suffisamment précis pour comprendre son contexte, ses contraintes et ses priorités. Par exemple : les gérants de restaurants indépendants qui gèrent seuls la saisie de leur caisse chaque soir, entre 20 h et 22 h, sur un téléphone Android d’entrée de gamme. Cette description-là suggère immédiatement des décisions produit : ergonomie mobile, session courte, tolérance aux erreurs de saisie, mode hors ligne. La description « les restaurants » n’en suggère aucune.
2. Quel problème essayons-nous de résoudre ?
La fonctionnalité n’est pas le problème.
« Nous avons besoin de notifications » est une solution.
Le problème pourrait être que les utilisateurs commencent une action importante, l’interrompent et ne reviennent jamais la terminer. Si c’est le vrai problème, plusieurs solutions deviennent possibles : notification, oui, mais aussi rappel dans l’application, e-mail, simplification du parcours, sauvegarde automatique de l’état, reprise en un tap. La première idée n’est plus automatiquement la meilleure.
Cette manière de reformuler une demande n’est pas du chipotage sémantique. Elle change la question que l’équipe pose. Une équipe qui reçoit « ajoute des notifications » construit des notifications, même si ce n’est pas le meilleur levier. Une équipe qui reçoit « fais revenir les utilisateurs qui interrompent une action » cherche le meilleur levier — souvent, celui qui coûte le moins cher à construire et qui rapporte le plus.
3. Comment ce problème est-il résolu aujourd’hui ?
Un produit n’est jamais uniquement en concurrence avec d’autres applications. Il est aussi en concurrence avec Excel, WhatsApp, le papier, un collaborateur, une habitude ou la décision de ne rien faire.
Un gérant de restaurant qui saisit ses ventes du jour sur un cahier ne fait pas rien : il a une solution, elle est imparfaite mais elle fonctionne, elle est gratuite et elle ne demande aucun apprentissage. Un produit qui prétend le remplacer devra être meilleur que ce cahier — pas meilleur en absolu, meilleur pour lui, dans sa situation, avec ses contraintes.
Cette comparaison change souvent la conception du produit. On découvre que la vraie concurrence n’est pas l’application dont on voulait s’inspirer — c’est un tableur, un carnet, ou simplement la mémoire du gérant. À partir de là, la promesse du produit n’est plus « une meilleure application » mais « une solution qui remplace ce que vous faites déjà, avec moins d’effort et moins d’erreurs ».
4. Quel changement attendons-nous chez l’utilisateur ?
Doit-il terminer une action plus rapidement ? Revenir plus régulièrement ? Faire moins d’erreurs ? Prendre une meilleure décision ? Acheter, apprendre ou collaborer plus facilement ?
Si le comportement attendu n’est pas défini, il sera difficile de savoir si la solution fonctionne. Le produit peut être livré, utilisé, apprécié, et pourtant ne rien changer au problème qu’il était censé résoudre. Sans définition explicite du comportement attendu, aucun feedback ne peut être interprété correctement : « les utilisateurs disent qu’ils aiment le produit » n’est pas la même chose que « les utilisateurs terminent leur saisie en cinq minutes au lieu de trente ».
Le comportement attendu doit être formulé avec un verbe et un contexte précis. « Utilise l’application régulièrement » est trop général pour être vérifiable. « Ouvre l’application chaque soir entre 20 h et 22 h et termine la saisie en moins de cinq minutes, cinq jours sur sept » est vérifiable — et l’échec devient un diagnostic exploitable, pas une frustration vague.
5. Comment mesurerons-nous cette valeur ?
Le nombre de téléchargements ou d’inscriptions ne suffit pas toujours.
Il faut identifier l’action qui montre que l’utilisateur a réellement obtenu le résultat promis. Cette action est celle qui, si on la voit se produire, prouve que le produit fait ce qu’il devait faire. Elle n’est pas forcément la plus fréquente ni la plus visible — elle est celle qui matérialise la promesse.
Pour un produit d’apprentissage, cette action peut être terminer un chapitre et obtenir un résultat au quiz. Pour un produit de facturation, ce peut être émettre une facture et recevoir le paiement dans le délai attendu. Pour un produit d’organisation d’équipe, ce peut être déclencher une décision documentée à partir d’une conversation initiée dans l’outil. Aucune de ces actions n’est identique à une inscription. Toutes matérialisent la valeur promise.
Trois cadres théoriques qui structurent ce raisonnement
Cette manière de réfléchir rejoint la théorie des Jobs to Be Done (Clayton Christensen — Know Your Customers' Jobs to Be Done (HBR)) : les utilisateurs choisissent une solution parce qu’ils cherchent à progresser dans une situation particulière, pas simplement parce qu’elle possède davantage de fonctionnalités. Cette perspective change ce qu’on considère comme un concurrent, ce qu’on considère comme une amélioration produit, et ce qu’on considère comme une réussite.
Le Value Proposition Canvas (Strategyzer — Value Proposition Canvas) propose également d’étudier les objectifs des utilisateurs, leurs difficultés et les bénéfices recherchés avant de définir précisément la solution. C’est un outil de cadrage utile quand plusieurs personnes doivent aligner leur compréhension du produit à concevoir, avant que le désaccord se traduise en discussions techniques stériles.
L’approche Lean Startup (Eric Ries — The Lean Startup Principles) considère que le véritable progrès d’une startup repose sur l’apprentissage validé : construire pour tester une hypothèse, mesurer le comportement réel et apprendre avant d’investir davantage. Cette discipline change la nature de chaque livraison : chaque itération est une expérimentation, pas seulement un jalon dans une roadmap.
C’est aussi pour cette raison qu’il faut parler aux utilisateurs avant et après le lancement, en s’intéressant à leurs expériences réelles plutôt qu’en essayant uniquement de leur vendre l’idée (Y Combinator — How to Talk to Users). Les entretiens utilisateur produisent des insights exploitables uniquement quand ils portent sur des comportements passés et récents, pas sur des intentions futures ou des jugements hypothétiques.
Le rôle d’un Product Engineer
Le rôle d’un Product Engineer n’est donc pas simplement de transformer l’idée d’un founder en code.
C’est de relier :
- le problème utilisateur,
- la vision du founder,
- la décision produit,
- l’exécution technique,
- et les résultats mesurables.
Avant de demander : « Comment allons-nous construire ce produit ? »
Il faut d’abord demander : « Quel problème voulons-nous résoudre, pour qui, et comment saurons-nous que nous avons réussi ? »
C’est cette question qui différencie un founder qui construit un produit d’un founder qui construit une démonstration technique. Elle ne coûte rien. Elle change tout.
Sources principales
- Clayton Christensen — Know Your Customers’ Jobs to Be Done, Harvard Business Review, septembre 2016
- Strategyzer — Value Proposition Canvas, outil de cadrage produit
- Eric Ries — The Lean Startup — Principles, méthodologie d’apprentissage validé
- Y Combinator — How to Talk to Users, guide d’entretien utilisateur
- Jour 1 — Les cinq questions avant de développer une fonctionnalité mobile — grille en 45 minutes qui applique ces principes à une feature spécifique
- Jour 3 — 3 tests avant de recruter votre premier dev mobile — méthodes concrètes pour valider avant d’investir
Cet article a résonné ?
Cet article vous a-t-il été utile ?
Cliquez une étoile pour laisser un mot
Delano Toungsi
Freelance CTO mobile · Missions, fractional & co-founder · Yaoundé full-remote