Construire des produits logiciels que le marché veut vraiment
J'ai commencé ma carrière en construisant un produit que personne n'a acheté à l'échelle. Quatre ans, une Série A, une technologie brevetée, et un enthousiasme sincère de tous ceux qui l'ont vu. Le marché ne priorisait simplement pas le problème qu'on résolvait. Cette expérience a façonné tout ce que j'ai fait en produit depuis.
À quoi sert vraiment le product management
Le product management est la fonction qui se situe entre ce qui peut être construit et ce qui devrait être construit. Ça semble simple. En pratique, ça demande de maintenir une ligne claire entre la conviction interne et les preuves externes, et d'avoir la discipline de ne pas confondre les deux.
Le rôle a beaucoup évolué. Dans beaucoup d'organisations, il reste flou de savoir ce dont un PM est vraiment responsable, comment il se situe par rapport à l'ingénierie, et quelle autonomie il devrait avoir. J'ai travaillé sur ces questions dans plusieurs contextes, et mon point de vue est que la réponse dépend moins des frameworks que de la dynamique spécifique de l'entreprise.
La discovery : la partie où la plupart des équipes sous-investissent
La plupart des échecs produit que j'ai vus n'étaient pas des échecs d'exécution. L'équipe a livré ce qu'elle avait dit livrer. Le problème est que personne n'avait validé si ça valait la peine de livrer.
La discovery est le travail de réduire ce risque avant de mobiliser du temps d'ingénierie. Ça signifie parler aux clients tôt et en continu, pas seulement au début d'un projet. Ça signifie former des hypothèses explicites et concevoir des façons de les tester à moindre coût. Ça signifie être prêt à tuer une idée qui ne résiste pas à l'examen.
À quoi ressemble une bonne discovery en pratique
Ce n'est pas un processus ou un template. C'est une habitude. Les PMs qui sont bons en discovery parlent aux clients chaque semaine, pas chaque trimestre. Ils posent des questions sur les problèmes, pas sur les solutions. Ils écoutent ce que font les clients, pas ce qu'ils disent vouloir.
Le livrable de la discovery n'est pas un document de spécifications. C'est un ensemble de paris bien fondés sur ce qui va créer de la valeur, avec assez de preuves pour justifier l'investissement.
La roadmap : des décisions, pas des listes
Une roadmap est un outil de priorisation, pas un plan de projet. Son travail est de communiquer ce que l'équipe croit qui aura le plus d'impact sur un horizon donné, et pourquoi.
La partie la plus difficile du travail de roadmap n'est pas de décider quoi construire. C'est de décider quoi ne pas construire. Chaque demande de feature qui arrive sur une roadmap chasse quelque chose d'autre. La discipline consiste à maintenir une vision claire de ce qui pilote la rétention, l'activation et l'expansion, et à protéger sans relâche du temps pour ces choses.
Comment j'approche la priorisation de roadmap
Je pars des preuves clients : quels sont les patterns dans les tickets support, les objections commerciales, et les raisons de churn ? Qu'est-ce que vos meilleurs clients utilisent le plus ? Que disent les clients churnnés qu'il leur manquait ?
À partir de là, je travaille avec l'équipe pour séparer la roadmap en trois buckets : ce qui garde les clients actuels satisfaits, ce qui permet d'aller chercher le prochain segment ICP, et ce qui crée une position défendable à long terme. L'équilibre entre ces buckets dépend du stade de l'entreprise.
La relation produit-marché
Produit et marché ne sont pas des préoccupations séparées. Le marché façonne ce que le produit devrait être. Le produit façonne quels marchés sont accessibles. Gérer cette relation est une conversation permanente, pas un exercice d'alignement ponctuel.
J'ai travaillé sur des produits techniquement solides mais commercialement désalignés, et sur des motions GTM qui essayaient de vendre des produits qui n'avaient pas encore tout à fait cloué le use case. Les deux expériences m'ont appris que le gap entre produit et marché est toujours un problème de leadership avant d'être un problème produit.
L'alignement cross-fonctionnel
Le product management c'est grosso modo 50% de travail d'alignement, 30% de réflexion collaborative, 15% de communication, et 5% de décision sur ce qu'on construit. Cette répartition surprend les gens, mais elle reflète la réalité : les meilleures décisions produit ne valent rien si les gens qui doivent agir dessus ne les comprennent pas ou ne leur font pas confiance.
Le travail d'alignement ne consiste pas à chercher le consensus. Il consiste à créer une compréhension partagée entre produit, ingénierie, sales et customer success, pour que chaque fonction puisse prendre de bonnes décisions indépendamment.
On this page