Hypothèses produit : la roadmap qui mène au market fit
Une roadmap de fonctionnalités vous occupe longtemps. Elle ne vous dit pas si vous avancez dans la bonne direction. La roadmap des hypothèses répond à cette question : elle liste ce que vous devez prouver pour atteindre le market fit, dans l’ordre, et en déduit ce qu’il faut construire.
Le problème de la roadmap de fonctionnalités
La plupart des product managers partagent avec leurs équipes une roadmap de fonctionnalités : une liste ordonnée de choses à construire, souvent nourrie de user stories. Elle a un avantage, elle donne du travail pour longtemps. Et un défaut majeur : pendant tout ce temps, la tête dans le guidon, vous ne savez pas si vous pédalez dans la bonne direction.
Une user story dit ce qu’une fonctionnalité apporte dans un monde idéal. Elle ne dit pas si ce monde existe.
Tant que le market fit n’est pas atteint, vous travaillez sur des hypothèses, que vous l’écriviez ou non. La seule question est de savoir si elles sont explicites et testées, ou implicites et coûteuses.
Qu’est-ce qu’une hypothèse produit ?
Une hypothèse produit est une affirmation sur votre marché, vos utilisateurs ou votre capacité à livrer, qui doit être vraie pour que le produit réussisse, et qui peut être vérifiée. Un format simple :
Nous croyons que [cette cible] [fera ceci] parce que [cette raison]. Nous le saurons quand [ce signal mesurable] sera observé.
On distingue classiquement trois familles :
- Désirabilité : les utilisateurs veulent-ils la solution, et changeront-ils leurs habitudes ?
- Viabilité : le modèle économique tient-il, à quel prix, avec quelle marge ?
- Faisabilité : savons-nous le construire et l’opérer, à l’échelle ?
La fiche hypothèse
Une phrase ne suffit pas à piloter un test. Pour chaque hypothèse importante, je tiens une fiche courte, la même pour toutes. Elle tient sur une demi-page et se remplit avant le test, sauf les deux dernières lignes.
| Champ | Ce qu’on y écrit |
|---|---|
| Énoncé | La phrase « Nous croyons que… Nous le saurons quand… » |
| Famille | Désirabilité, viabilité ou faisabilité |
| Ce qui en dépend | Les hypothèses et les initiatives qui tombent si celle-ci est fausse |
| Preuves actuelles | Ce qu’on sait déjà : entretiens, données, précédents. « Aucune » est une réponse acceptable |
| Test | L’expérience la moins chère qui peut la contredire |
| Signal et seuil | La mesure, et la valeur en dessous de laquelle l’hypothèse est invalidée |
| Date de décision | Le jour où l’on tranche, même si les données sont incomplètes |
| Coût du test | En jours de travail et en argent |
| Responsable | Une seule personne, qui présente le résultat |
| Résultat | Ce qui a été observé, chiffres à l’appui |
| Décision | Continuer, ajuster, abandonner, et ce que cela change dans la roadmap |
La ligne « Ce qui en dépend » est celle qu’on oublie le plus. C’est pourtant elle qui permet d’ordonner les hypothèses.
Construire la roadmap des hypothèses
Chez SipScience, j’ai construit ma première roadmap des hypothèses trois mois après avoir rejoint l’équipe, le temps de comprendre la situation. La méthode tient en quatre étapes.
- Partez de l’objectif final. Pas « lancer la V2 », mais un résultat économique : un niveau de revenu, une présence sur un nombre de marchés, une rentabilité.
- Déduisez les conditions nécessaires. Qu’est-ce qui doit être vrai pour que l’objectif soit atteint ?
- Ordonnez-les par phase et par risque. Les hypothèses dont tout le reste dépend passent en premier.
- Pour chacune, définissez le test : une expérience, une mesure, ou une fonctionnalité à construire, avec le signal attendu.
Un exemple
Exemple fictif : une application qui permet de réserver une table au restaurant avec une remise, connectée au logiciel de caisse du restaurant. Objectif : être présent et rentable dans plusieurs grandes villes européennes.
| Phase | Hypothèse | Comment la tester |
|---|---|---|
| 1 | Notre intégration fonctionne avec les logiciels de caisse de nos restaurants pilotes. | Connecter cinq restaurants, mesurer les erreurs de synchronisation. |
| 1 | Les restaurants acceptent d’offrir une remise contre de la prévisibilité. | Démarchage d’un quartier, taux de signature. |
| 1 | Les utilisateurs réservent et reviennent. | Rétention à huit semaines sur le premier quartier. |
| 2 | L’acquisition de restaurants et d’utilisateurs se reproduit dans une seconde ville. | Même méthode, coût d’acquisition comparé. |
| 3 | Les données collectées ont de la valeur pour des partenaires. | Entretiens et lettres d’intention. |
Remarquez que les premières hypothèses portent sur la technique et l’offre, pas sur le marketing. Inutile d’investir dans la croissance tant que l’intégration ne tient pas. De ces hypothèses, vous déduisez les éléments de la roadmap produit : moyens de paiement, compatibilité avec les caisses, onboarding des restaurants. Chaque fonctionnalité a une raison d’être explicite.
Ordonner par risque, sur le même exemple
Dire « les hypothèses dont tout dépend passent en premier » ne suffit pas quand trois hypothèses semblent aussi importantes. Une notation simple aide : pour chacune, notez de 1 à 3 l’impact si elle est fausse, puis de 1 à 3 l’incertitude actuelle. Le produit des deux donne le risque. À risque égal, le test le moins cher passe devant.
| Hypothèse | Impact si fausse | Incertitude | Risque | Coût du test | Ordre |
|---|---|---|---|---|---|
| Intégration aux caisses | 3 : tout le modèle en dépend | 3 : jamais testée | 9 | Moyen | 1 |
| Remise acceptée par les restaurants | 3 : sans offre, pas de produit | 2 : quelques entretiens favorables | 6 | Faible | 2 |
| Réservation et retour des utilisateurs | 3 | 2 : usage connu chez les concurrents | 6 | Élevé : il faut l’offre d’abord | 3 |
| Reproduction dans une seconde ville | 2 : on peut rester local plus longtemps | 2 | 4 | Élevé | 4 |
| Valeur des données pour des partenaires | 1 : revenu complémentaire | 3 | 3 | Faible | 5, en tâche de fond |
Deux remarques. D’abord, la notation n’est pas une science : elle sert à rendre le désaccord visible. Si l’équipe technique note l’incertitude de l’intégration à 1 et le product manager à 3, c’est la discussion à avoir. Ensuite, la dernière hypothèse a un risque faible mais un test très peu coûteux : on peut la tester en parallèle, sans mobiliser l’équipe.
La fiche, remplie
Pour la première hypothèse : énoncé, « nous croyons que notre connecteur synchronise les réservations avec les caisses des restaurants pilotes ; nous le saurons quand moins de 2 % des réservations présenteront une erreur sur quatre semaines ». Ce qui en dépend : toutes les autres. Preuves actuelles : aucune en conditions réelles. Test : cinq restaurants, deux logiciels de caisse différents. Date de décision : fin du deuxième mois. Responsable : le responsable technique. Le seuil de 2 % est un choix de l’équipe, discuté avec les restaurants pilotes, pas une norme.
Les erreurs fréquentes, et comment les repérer
- Des hypothèses impossibles à contredire. « Les utilisateurs aimeront l’application. » Signal : aucun résultat de test ne pourrait vous faire changer d’avis.
- Un seuil fixé après coup. Signal : le seuil apparaît dans la présentation des résultats, pas dans la fiche d’origine.
- Des tests trop longs. Signal : la date de décision recule à chaque revue. Un test qui ne conclut pas en quelques semaines est souvent mal conçu.
- Ne tester que la faisabilité. Signal : toutes les fiches relèvent de la même famille, celle que l’équipe sait le mieux tester.
- Garder une hypothèse invalidée « pour voir ». Signal : des initiatives qui en dépendaient restent dans la roadmap.
Petite équipe ou grande organisation
Dans une startup, la roadmap des hypothèses tient sur une page, et le fondateur ou le product manager tient les fiches. Trois à cinq hypothèses actives suffisent. Dans une grande organisation, elle devient un outil de gouvernance : chaque initiative financée doit pointer vers les hypothèses qu’elle teste, et la revue trimestrielle examine les résultats avant les budgets. C’est aussi le meilleur antidote aux projets qui continuent parce qu’ils ont déjà coûté cher.
Ce que vous y gagnez
La roadmap des hypothèses se situe entre le business model canvas et la roadmap produit. Elle vous permet de :
- rester concentré sur les objectifs stratégiques ;
- faire des choix rationnels, défendables devant l’équipe et la direction ;
- ne construire que ce qui sert à valider quelque chose ;
- savoir quand et pourquoi pivoter, quand une hypothèse importante tombe.
Elle n’est pas immuable. Elle évolue, mais seulement au rythme des validations et des invalidations. C’est ce qui la distingue d’une roadmap qui change au gré des demandes. Elle sert aussi de cadre au MVP : le MVP est simplement le test des hypothèses de la phase 1.
Avec le recul
J’ai écrit cet article en 2022, encore marqué par le travail chez SipScience. C’est sans doute, de cette série, celui que je modifierais le moins sur le fond, et celui que j’utilise le plus aujourd’hui, y compris hors du produit.
Ce que je garde
Le format de l’hypothèse avec un signal mesurable, et l’ordre par risque. J’ai vu depuis des équipes perdre des trimestres entiers parce que l’hypothèse la plus risquée était aussi la plus inconfortable à tester, et qu’on l’avait repoussée.
Ce que je nuance
Je présentais la roadmap des hypothèses comme un outil de recherche du market fit. Elle sert bien au-delà : pour une organisation installée, chaque projet de transformation repose aussi sur des hypothèses, et elles sont rarement écrites. Je l’utilise aujourd’hui en cadrage de projets IA bien plus souvent qu’en startup.
Je nuance aussi la place de la faisabilité. En 2022, je la mettais volontiers en tête, comme dans l’exemple du restaurant. Pour un projet IA, ce n’est plus toujours le cas : un prototype qui fonctionne se construit vite, et le vrai risque se déplace vers l’adoption et le coût à l’échelle.
Ce que les assistants IA ont changé
Le coût des tests a baissé. Une page d’atterrissage, un prototype cliquable, une analyse de cent entretiens se font en quelques heures. On peut donc tester plus d’hypothèses, plus tôt, et c’est une vraie avancée. Pour une entreprise qui hésite entre un outil du marché et un développement, le guide logiciel standard ou application sur mesure applique la même logique de test avant d’engager un budget.
Mais un test rapide reste un test, avec ses biais. Un prototype généré en une heure peut séduire en entretien sans rien prouver sur l’usage réel. Et une synthèse d’entretiens produite par un assistant doit être vérifiée contre les entretiens eux-mêmes, sinon c’est l’assistant qui valide vos hypothèses à votre place. Moins cher ne veut pas dire moins rigoureux.
Questions fréquentes
Combien d’hypothèses faut-il tester en même temps ?
Le moins possible : une ou deux par cycle, celles dont tout le reste dépend. Tester dix hypothèses en parallèle rend les résultats impossibles à interpréter.
Quand considérer qu’une hypothèse est invalidée ?
Quand le signal fixé à l’avance n’est pas atteint dans le délai prévu. Le seuil doit être écrit avant le test, sinon on finit toujours par trouver une raison de continuer.
Quelle différence avec des OKR ?
Les OKR fixent des objectifs et des résultats clés à atteindre. La roadmap des hypothèses explique ce qui doit être vrai pour les atteindre, et dans quel ordre le vérifier. Les deux se complètent.
Comment ordonner des hypothèses qui semblent toutes prioritaires ?
Notez pour chacune l’impact si elle est fausse et l’incertitude actuelle, de 1 à 3, et multipliez. À risque égal, testez d’abord celle dont le test coûte le moins. La notation sert surtout à faire apparaître les désaccords.
Qui décide qu’une hypothèse est validée ?
Le responsable désigné sur la fiche présente le résultat, mais la décision suit le seuil écrit avant le test. Si le seuil est atteint, on continue ; sinon, on ajuste ou on abandonne, et la roadmap en tient compte.
Et l’IA dans tout ça ?
Les projets IA sont, par nature, des paris sur des hypothèses. Le modèle atteindra-t-il une qualité suffisante sur vos données réelles ? Les équipes l’utiliseront-elles ? Le coût par requête tiendra-t-il au volume réel ? La plupart des POC IA ne testent que la première question, et sur un échantillon favorable.
Appliquez la même méthode. Écrivez les hypothèses de désirabilité, de viabilité et de faisabilité de votre projet IA, avec un signal mesurable pour chacune. Les indicateurs que je détaille dans mesurer un assistant IA de support en sont des exemples concrets. Et ordonnez-les par risque : souvent, l’hypothèse la plus risquée n’est pas technique, c’est l’adoption par les équipes. C’est ce que j’appelle les 70 % organisationnels, et c’est le sujet de du POC IA à la production.
Si le système relève d’un domaine sensible, ajoutez une hypothèse de conformité dès la phase 1 : « ce système n’entre pas dans les catégories à haut risque, ou nous savons en remplir les obligations ». Elle se teste par une lecture de l’Annexe III, comme je le décris dans classer ses systèmes IA selon l’AI Act.