En deux ans de sessions à Thiga Academy, Alexandre Dury a appris à repérer, dès les premières questions des participant·e·s, les organisations Produit qui font du projet sans se l'avouer. Jours-homme, studios, Run séparé du Build, équipe Produit managée par le Business, mises en production rares : Alexandre passe en revue cinq signaux qui ne trompent pas. Une fois le constat posé, deux chemins s'ouvrent, tous deux légitimes : assumer l'approche projet, ou engager une vraie bascule.
Depuis 2 ans, j'ai eu l'occasion avec Thiga Academy d'animer des dizaines de sessions de formation de 2 jours, avec jusqu'à 12 personnes par session, venues d'entreprises, secteurs et contextes très différents.
Et au fil des sessions, j'ai appris à repérer des patterns, des mots qui reviennent et qui trahissent une orga "Produit" qui fait du projet sans se l'avouer. Pas besoin d'organigramme, pas besoin d'immersion : les questions qui émergent quand je présente ce qu'est une roadmap Produit, à quoi ressemble le process Produit… sont très révélatrices !
Le problème : la personne en face fait du projet, et visiblement, personne ne l'a prévenue.
Et je te le dis tout de suite : faire du projet n'a rien de grave. Ce qui coince, c'est de croire qu'on fait du Produit, puis de s'épuiser à appliquer des méthodes qui ne peuvent pas marcher dans son contexte.
Les signaux qui ne trompent pas
Signal n°1 : la mention des "jours-homme"
Dès qu'une organisation Produit raisonne en jours-homme pour dimensionner un travail, elle a basculé dans une logique de production où le temps consommé compte davantage que la valeur produite. Chaque projet est "sizé", validé par plusieurs instances décisionnelles, puis doté d'un budget et d'une équipe en fonction d'un cahier des charges déjà cadré. Cohérent en mode projet, ce fonctionnement devient coûteux quand on prétend faire du Produit : des process chronophages qui épuisent les équipes, et des équipes techniques qui changent à chaque projet et qu'il faut refaire monter en compétence. Attention, je ne dis pas qu'il faut ignorer les coûts et le ROI : je dis qu'en Produit, ils ne doivent pas être le seul facteur pour piloter les décisions stratégiques et que la valeur et l'impact comptent au moins autant.
Signal n°2 : l'organisation en "studios"
Mutualiser les expertises dans des studios se défend dans une logique projet, ou lorsqu'on a un besoin de renforts opérationnels ponctuels. Mais quand le Design ou la Data vivent dans une structure à part, mobilisés uniquement à la demande plutôt qu'intégrés aux équipes Produit, la décision se prend sans les personnes qui devraient la nourrir au quotidien. Un·e Designer sollicité·e une fois par sprint ne façonne pas un produit : son rôle se réduit à livrer des écrans, souvent sans vision de l'historique de ce produit, de ses objectifs ou de ses profils utilisateurs. Et une équipe qui doit passer par l'équipe Data à la moindre question finit par mal connaître ses utilisateurs, voire par ne plus y avoir accès du tout.
Signal n°3 : la distinction entre "Run" et "Build"
Traiter la maintenance du produit et son évolution comme deux mondes séparés, parfois avec deux équipes distinctes, revient à considérer que le Run ne sert qu'à résoudre des bugs et le Build à construire de nouvelles fonctionnalités. C'est aussi déresponsabiliser l'équipe qui construit et la couper de tout ce qui remonte par le Run : les bugs, les irritants, les usages imprévus sont autant de signaux sur ce qu'il faudrait améliorer, et ils atterrissent chez une équipe qui n'a pas la main pour décider. Un produit vivant se retravaille en continu, et la question à se poser est plutôt : comment, à l'instant T, je crée le plus de valeur ? En améliorant l'existant, en construisant de nouvelles fonctionnalités, ou en supprimant des fonctionnalités (décision clairement sous-cotée) ? Je recommande donc de confier le Run et le Build à la même équipe, et d'arrêter de distinguer les deux.
Signal n°4 : une équipe Produit managée par le Business/le Marketing
Le travail d'un·e Product Manager, c'est de construire un produit ayant le maximum d'impact pour l'entreprise comme pour ses utilisateurs, en s'appuyant sur ses parties prenantes mais aussi sur sa vision, sa stratégie et ses propres objectifs. Quand le produit est managé par des équipes Business, la décision Produit passe mécaniquement sous la pression du trimestre commercial, avec un chiffre à honorer avant même d'avoir pu faire une Discovery sérieuse. Un rapport de force s'installe : le/la PM n'a plus de marge de manœuvre, exécute ce qui est demandé, et la Discovery devient quasi inutile puisque la solution attendue est déjà définie. Souvent, on construit alors des produits selon la demande des clients et on oublie d'avoir une démarche orientée "problèmes". Se connecter régulièrement et efficacement aux équipes Business oui, en dépendre au niveau managérial, non !
Signal n°5 : des MEP rares, des fonctionnalités qui se construisent en plusieurs mois
Le principe d'une approche Produit est de livrer rapidement pour apprendre de ses utilisateurs et itérer. Avec Scrum par exemple, les fonctionnalités doivent être terminées et livrées à l'issue de sprints de 2 à 3 semaines. Si une fonctionnalité met plusieurs mois à sortir, c'est qu'elle a été pensée trop complexe ou qu'on a trop de dépendances, et toute démarche itérative devient impossible. Quand une équipe Produit en arrive là, c'est que la structure dans laquelle elle évolue lui met trop de bâtons dans les roues, et que cette structure est, dans les faits, une structure projet.
Si tu coches plusieurs de ces cases, tu as sans doute reconnu ton quotidien !
Lors de mes formations, le premier jour, la plupart des participant·e·s se présentent encore comme Product Manager ou Product Owner, convaincu·e·s de faire du Produit. Le deuxième jour, après les cas pratiques, la prise de conscience arrive : c'est du projet qu'on fait, sous un habillage Produit qu'on ne leur a jamais permis de vérifier.
Projet ou Produit : le diagnostic commence souvent en formation. La formation Product Manager de Thiga Academy donne des outils directement actionnables pour mener la Discovery, de la stratégie Produit jusqu'au dashboard.
L'approche projet n'a rien de honteux
Rien de tout ça ne fait du mode projet une mauvaise méthode : le cycle en V, le waterfall, une gouvernance par jalons, tout ça reste parfaitement légitime en 2026 dans beaucoup de contextes, c'est même parfois le choix le plus sain. Un chantier d'infrastructure, une migration réglementaire, un déploiement matériel, un décommissionnement… il n'est pas toujours pertinent, utile ou possible d'adopter une démarche itérative ou de faire de la vraie Discovery.
Le problème surgit quand une entreprise se convainc de faire du Produit parce que c'est le mot à la mode, sans jamais transformer l'organisation qui va avec : ni l'autonomie de décision, ni la composition des équipes.
Ça crée deux dégâts :
- Le premier touche l'organisation, coincée entre deux mondes, incapable de tirer les bénéfices du mode projet parce qu'elle joue à autre chose, et incapable d'obtenir ceux du mode Produit parce qu'elle n'a rien mis en place pour ça.
- Le second touche les gens, tiraillés entre une théorie qu'on leur enseigne en formation et un quotidien qui ne leur ressemble pas, au point de finir par douter de leurs compétences, alors que le problème ne vient pas d'eux.
Et une fois qu'on a posé le constat ?
Deux chemins s'ouvrent, et les deux sont légitimes.
Le premier, c'est d'assumer l'approche projet. Concrètement, ça veut dire arrêter de simuler une Discovery dont les conclusions ne changeront rien au cahier des charges, et appeler les rôles par leur nom : énormément d'entreprises mélangent les rôles de PO, de PM, de chef de projet IT, de PMO, de MOA… et ça n'aide personne. Ça veut aussi dire poser des attentes honnêtes avec sa hiérarchie sur ce que l'équipe peut réellement décider ou non. Rien n'empêche de garder au passage les pratiques Produit qui ont du sens dans ce cadre, comme parler à ses utilisateurs ou mesurer l'usage de ce qu'on livre. Une équipe qui sait qu'elle fait du projet travaille mieux qu'une équipe qui essaie de faire du Produit sans avoir le contexte pour le faire.
Le second, c'est de vouloir vraiment basculer. La phrase que j'entends le plus souvent, en fin de formation, résume tout : "en fait, c'est mes chefs qu'il faudrait envoyer ici". Les PM sont convaincu·e·s par l'approche Produit, en comprennent l'intérêt et la valeur ajoutée, mais savent bien qu'il leur sera impossible de tout appliquer sans vraie transformation à tous les niveaux de l'organisation. Et pour ça, il va falloir utiliser une autre corde de leur arc : les soft skills ! Évangéliser, communiquer, convaincre… c'est au moins 50% du travail de PM.
Le vrai problème
Ce qui fait le plus de mal aux équipes Produit & Tech en 2026, c'est de coller une étiquette Produit par effet de mode sur une structure qu'on n'a en fait jamais eu l'intention de transformer. Assumée, l'approche projet fait très bien son travail.
Alors, avant de douter de tes compétences de PM, demande-toi si on t'a vraiment donné un job de PM 😉
Rôles, objectifs, découpage des équipes : l'organisation Produit en pratique. Les organisations orientées Produit s'appuie sur les retours d'une trentaine de Heads of Product pour aider à structurer une organisation réellement orientée Produit.
