« Mettre la charrue avant les bœufs » est une expression française qui illustre une situation absurde où l’on attend les conséquences d’un événement… qui n’a jamais eu lieu. Par exemple : recevoir un repas chez soi sans jamais l’avoir commandé, ou se projeter déjà au volant d’une nouvelle voiture sans même avoir vérifié sa solvabilité pour l’acheter.

L’évidence n’est pas toujours aussi simple qu’elle en a l’air. Pendant des décennies, l’industrie a fonctionné sur une conviction solide : pour savoir si un produit se vend, il faut d’abord le produire. L’automobile, l’électroménager, la mode — tout reposait sur cette logique linéaire : conception, production, puis mise sur le marché.

Lorsque les méthodologies en Product Management Agile sont apparues, elles ont bousculé cette certitude. Leur message “tester vite pour échouer vite” a souvent été mal compris. Beaucoup y ont vu une simple accélération du cycle industriel, alors qu’il s’agissait d’un changement de paradigme : ne pas produire pour tester, mais tester avant de produire.

Ne plus tomber amoureux de la solution mais se passionner pour le besoin.

Vendre un besoin VS vendre une solution

Le product management agile cherche à identifier ce qui peut être validé avec le minimum d’effort et de coût. C’est là qu’intervient la créativité du growth hacking, qui a ouvert la voie à des approches ingénieuses pour évaluer l’intérêt d’un produit avant même son existence.

Dropbox en est un exemple emblématique. En 2007, avant d’écrire une seule ligne de code, Drew Houston a publié une simple vidéo de démonstration. Elle montrait un prototype fictif capable de synchroniser des fichiers en un clic. En réalité, le produit n’existait pas encore. En quelques jours, des dizaines de milliers de personnes se sont inscrites sur la liste d’attente. Ce signal suffisait : le besoin était bien réel.

Cette stratégie illustre parfaitement la différence entre “mettre la charrue avant les bœufs” et “vérifier qu’il y a bien un champ à labourer”. L’agilité ne consiste pas à aller plus vite, mais à aller plus juste — en construisant seulement ce qui a prouvé sa nécessité.

La priorisation ici ? Valider le besoin à une échelle significative avant de valider l’opportunité.

La chaîne de priorisation

Les approches de priorisation ont souvent été dévoyées. Des outils comme MoSCoW, RICE ou les matrices Impact/Effort se sont imposés partout, parfois sans véritable compréhension de la logique agile qu’ils étaient censés servir.

Dans une approche vraiment agile, la priorité ne se décide pas seulement en fonction de l’effort ou de l’impact supposé, mais de ce qu’il reste à apprendre. Chaque test a son ordre logique :

  • Besoin : existe-t-il réellement un problème à résoudre ? Et comment le mesurer ?

  • Opportunité : ce problème concerne-t-il un marché identifiable ? Quel segment est le plus prometteur ?

  • Désirabilité : la solution envisagée donne-t-elle envie ? Fait-elle bouger l’indicateur du besoin ?

  • Utilisabilité : la solution est-elle compatible avec le client ou l’utilisateur cible et son contexte ? Une fois testée sur le terrain, la solution est-elle réellement adoptée ?

  • Faisabilité : la solution envisagée est-elle réalisable dans le contexte, les coûts et délais à la hauteur de l’opportunité ?

  • Viabilité : le modèle économique tient-il la route à l’échelle du marché ciblé ?

Trop d’entrepreneurs sautent ces étapes. Par peur qu’on leur vole leur idée, ils gardent le silence, construisent en secret, puis découvrent trop tard qu’ils ont développé un produit que personne ne voulait ou qui n’est pas viable. C’est l’erreur classique de celui qui priorise la solution avant l’apprentissage. L’agilité, elle, propose l’inverse : apprendre d’abord, construire ensuite. Tester le besoin avant de tester la solution. Car la seule chose qu’on puisse vraiment échouer à temps, c’est une hypothèse.

La priorisation par l’expérience client et utilisateur

À cela s’ajoute une deuxième clé de lecture : différencier la valeur des vecteurs de valeur.

Pour illustrer cette distinction, j’utilise souvent le célèbre tunnel d’acquisition AARRR, introduit par Dave McClure. Ce modèle décompose le parcours utilisateur en cinq étapes :

  • Acquisition : Comment les utilisateurs découvrent le produit.

  • Activation : Leur première expérience positive.

  • Rétention : Leur envie de revenir naturellement.

  • Revenue (Revenu) : La valeur économique générée. Dans le cadre de cette priorisation, j’évite cet axe car il se joue pour moi en parallèle du reste. On est donc plutôt sur du AARR.

  • Referral (Recommandation) : Le bouche-à-oreille, signe d’une valeur perçue.

Dans une logique d’implémentation immédiate, les équipes se concentrent souvent sur les deux premières étapes, acquisition et revenu, parce qu’elles sont visibles et rassurantes. On veut présenter un produit, le faire connaître, générer du trafic, signer des contrats. Mais une approche agile replace la question dans le bon ordre : avant de chercher à vendre, il faut s’assurer qu’il y a une valeur à servir.

La rétention est le miroir de la valeur réelle : si les utilisateurs reviennent d’eux-mêmes, c’est que le produit leur apporte quelque chose de concret, de répétable, d’utile. Prenons l’exemple d’une application de suivi de sommeil. Si elle investit massivement en publicité avant de prouver qu’elle aide vraiment ses utilisateurs à mieux dormir, elle générera peut-être des téléchargements, mais pas d’usage durable. Chaque euro dépensé pour la promouvoir devient alors un euro jeté par la fenêtre. Ainsi, promouvoir un produit qui n’apporte rien, c’est accélérer sa disparition. Les usines à impact inversent cette logique : elles travaillent d’abord sur la valeur perçue et vécue — celle qui crée naturellement la rétention — avant de déployer les vecteurs de diffusion. L’adoption n’est alors plus une conquête, mais une conséquence. La priorisation se fait alors dans l’ordre suivant :

  • Rétention
  • Activation
  • Referral et Acquisition en parallèle

Prioriser le sondage avant l’implémentation

Mais là encore, le piège de l’implémentation guette : on croit que la valeur ne peut naître qu’à travers le produit lui-même.

Or, le marketing moderne a profondément transformé cette vision. Il ne se limite plus à faire connaître une solution : il sert aussi à sonder le besoin, parfois bien avant qu’un produit n’existe.

C’est ce qu’on appelle le marketing exploratoire. Plutôt que de construire un prototype coûteux, on peut publier une série d’articles, de vidéos ou de publicités ciblées pour tester l’intérêt d’un sujet. En mesurant les taux de clics, les inscriptions à une liste d’attente ou les interactions sur une page d’atterrissage, on obtient une première validation du besoin et de la population réellement concernée.

De nombreuses startups procèdent ainsi : avant de coder la moindre fonctionnalité, elles testent plusieurs messages publicitaires renvoyant vers des pages différentes. La page qui attire le plus d’inscriptions révèle souvent le problème perçu comme le plus douloureux — donc la meilleure opportunité à explorer.

Autrement dit, le marketing n’est plus seulement un amplificateur de valeur, c’est un détecteur de valeur potentielle. Il permet d’apprendre avant d’agir, et d’investir ensuite là où les signaux sont les plus forts.

Faking it before making it

Enfin, l’approche moderne du design ajoute une brique essentielle à la démarche : celle de l’expérimentation incarnée.

Des méthodes comme le Design Sprint, popularisées par Google Ventures, permettent de simuler en quelques jours ce que serait l’expérience utilisateur d’un produit avant même qu’il n’existe. L’objectif n’est pas de “concevoir vite”, mais de rendre visible une idée pour pouvoir la confronter rapidement.

Dans le même esprit, le principe du “Fake it until you make it” ne signifie pas “tromper”, mais tester manuellement ce qu’on automatisera plus tard. Au lieu de coder une plateforme complexe, on reproduit ses mécanismes à la main pour observer si la promesse tient.

C’est exactement ce qu’a fait Airbnb à ses débuts : les fondateurs prenaient eux-mêmes les photos des appartements et géraient les échanges entre hôtes et voyageurs pour vérifier que le modèle fonctionnait avant de le développer.

À l’inverse, de nombreux entrepreneurs lancent des applications communautaires ou des marketplaces sans jamais avoir animé une communauté ni orchestré d’échanges réels. Ils construisent un outil avant de comprendre les dynamiques sociales qu’il doit soutenir. Le résultat est prévisible : une belle interface, mais aucun usage.

Le design moderne, bien compris, nous rappelle une vérité simple : avant de créer une expérience, il faut l’éprouver.

Le product manager agile devient orchestrateur de priorités

À partir de là, le rôle du Product Manager prend une tout autre dimension.
Il devient un stratège de l’apprentissage, à la croisée du marketing, du design et de la technologie. Son objectif n’est plus seulement de piloter la livraison d’un produit, mais d’orchestrer la compréhension progressive de ce qu’il doit être.

Dans cette logique, son backlog ne contient pas des fonctionnalités, mais des hypothèses à tester : des besoins à valider, des messages à confronter, des usages à observer. Chaque test devient une brique de connaissance qui alimente la vision du produit.

Parfois, cela signifie suspendre le développement, même temporairement — non pas pour ralentir, mais pour s’assurer que l’équipe avance dans la bonne direction. Un Product Manager aguerri sait quand il faut dire : “Stop, on n’a pas encore appris assez.”

En ce sens, le produit n’est plus une simple application ou un livrable : c’est un système vivant d’expériences, de feedbacks et d’ajustements.

C’est la raison pour laquelle nous ne pouvons plus considérer l’ancienne définition du produit qui le résumait à un bien ou un service.