On a confondu la rigueur avec la cérémonie.
STRUCT | LAB — Adeline Bruni
Pendant des années, le produit s'est emballé dans des frameworks, des workshops, des certifications, des rituels qui ritualisent d'autres rituels.
On a oublié que le métier, c'est de mettre des choses entre les mains des gens, de regarder ce qui se passe, puis de décider quoi faire ensuite.
Pas de produire des slides.
Pas de remplir des templates Notion.
Pas de jouer au théâtre de la discovery devant un board qui veut surtout savoir pourquoi la roadmap n'avance pas.
Le bordel, ce n'est pas le terrain.
Le bordel, c'est ce qu'on met entre soi et le terrain.
Voilà le bordel.
Et il a un coût.
Il rend les bons PM malheureux.
Il rend les fondateurs nerveux.
Il rend les bonnes boîtes lentes.
À toi si ta boîte a passé le product-market fit, levé une série A ou B, recruté tes premiers PM — mais que la fonction Product ne tient pas encore debout toute seule.
À toi si la roadmap déborde, si les arbitrages reviennent toujours dans ton bureau, si tes PM font de leur mieux mais manquent de cadre, et si chaque sujet produit finit en négociation interne.
À toi si tu ne veux ni empiler des rituels, ni recruter trop vite un VP Product, ni laisser l'équipe se débrouiller avec des frameworks copiés-collés.
Struct Lab existe pour ce moment-là — pour les scale-ups B2B SaaS, marketplace, e-commerce/DTC, fintech et HR-tech.
Une marketplace internationale. Un back-office interne utilisé par toute la boîte : tech, commerce, finance, juridique. Chacun pour des raisons différentes, chacun avec ses urgences, chacun avec ses contournements.
Le symptôme. L'équipe dev croulait sous le run. Des tickets ouverts pour des informations déjà affichées à l'écran. Des suppressions faites à la main en base de données. Des équipes business qui ne cherchaient plus, parce qu'elles avaient appris que demander à la tech allait plus vite.
La réponse classique. Trois mois d'audit, un benchmark d'outils, un comité de pilotage, puis une restitution très propre que personne n'aurait relue deux semaines plus tard.
La réponse Quick Win to Scale.
Un atelier de trois heures. Chaque rôle — tech lead, dev back, dev front, designer, intégrateur, PM — a posé son usage réel de l'outil, ses contraintes, ses irritants, ce qui lui manquait vraiment. On s'est mis dans les chaussures d'un bizdev pour comprendre pourquoi il ouvrait un ticket au lieu de lire l'écran — pas pour le juger, pour comprendre ce qui, dans le système, l'avait entraîné à fonctionner comme ça. Une seule grille pour arbitrer : impact utilisateur contre effort de développement. Une carte de frictions, pas un audit.
Premier test ciblé sur la friction la plus coûteuse : une alerte visible quand le wallet d'un partenaire n'était pas ouvert. Livré en quelques jours, pas en fin de trimestre.
Les tickets sur ce sujet précis se sont taris. Les équipes business ont recommencé à utiliser l'outil au lieu de solliciter la tech. Le signal confirme qu'on a touché le bon nœud du problème — on continue.
On généralise la logique aux autres frictions de la carte : un contrôle des doublons à la création d'une boutique, la suppression et la fusion de comptes directement accessibles depuis l'outil, sans plus jamais toucher à la base de données.
Quatre-vingt-dix jours plus tard : des équipes business autonomes, des développeurs qu'on n'arrache plus à la roadmap pour réparer le run, un back-office redevenu un levier au lieu d'un trou noir. Les nouveaux réflexes tiennent seuls.
Trois heures d'atelier. Une carte de frictions impact/effort. Cinq étapes. 90 jours d'exécution — et un outil interne qui a rendu toute l'entreprise plus rapide.
Voilà ce que j'appelle faire du Product.
C'est particulièrement vrai dans les scale-ups post-PMF.
À 20 personnes, le produit tient encore dans la tête du fondateur.
À 50, ça commence à grincer.
À 100, tout le monde a un avis.
À 200, si rien n'a été structuré, la roadmap devient un champ de bataille poli.
Le fondateur sait qu'il doit déléguer le produit. Mais il a peur de perdre la main.
Et franchement, cette peur est légitime.
Parce qu'on lui a souvent vendu deux mauvaises options.
Première option : recruter un VP Product hors de prix, difficile à trouver, parfois trop corporate, souvent trop loin du terrain.
Deuxième option : faire appel à un freelance product très opérationnel, utile pour livrer, mais rarement capable de faire le pont entre stratégie, organisation, priorisation, exécution et montée en compétence de l'équipe interne.
Entre les deux, il y a un trou. Struct Lab existe pour ce trou-là.
Struct Lab aide les scale-ups à structurer leur fonction Product sans s'enliser. Pas en ajoutant une couche de process sur une organisation déjà saturée. Pas en important les rituels d'une boîte qui a 1 000 salariés dans une équipe qui en a 80.
Trois choses, simplement :
Identifier le vrai problème en une semaine.
Livrer un premier résultat mesurable en quelques semaines.
Industrialiser ce qui marche, avec les équipes internes.
Cette méthode s'appelle Quick Win to Scale — Scope, Spike, Signal, Scale, System. On part d'un irritant réel, on le transforme en résultat concret, puis on utilise ce résultat pour créer de la confiance, clarifier les décisions, faire monter les PM en compétence et installer les bons réflexes.
Les fondations se posent en construisant.
Le reste, on le débarrasse.
Un quick win livré bat un slide visionnaire. Toujours. On commence par ce qui peut être mis entre les mains de quelqu'un dans les quatre prochaines semaines, pas par ce qui peut être mis dans une roadmap à douze mois. La stratégie qui ne touche jamais le réel finit en fiction. Et les fictions, en scale-up, coûtent très cher.
Si un rituel ne change pas une décision, on le supprime. Si un livrable n'est pas lu, on arrête de l'écrire. Si une réunion n'a pas produit une décision claire en 30 minutes, elle n'aurait probablement pas dû exister. La maturité Product ne se mesure pas au nombre de frameworks utilisés — elle se mesure à la qualité des décisions et à la vitesse d'apprentissage.
C'est souvent la grande peur du fondateur : sortir du quotidien produit sans devenir spectateur de sa propre boîte. Le sujet n'est pas de sortir le fondateur du produit. Le sujet est de lui redonner la bonne place. Moins d'arbitrages permanents. Plus de décisions structurantes. Une bonne fonction Product ne remplace pas l'intuition du fondateur — elle l'équipe.
Le PM qui ne touche pas le produit perd son intuition. Le stratège qui ne sait pas ce que vit l'utilisateur fabrique des fictions. Struct Lab refuse cette séparation confortable entre ceux qui pensent et ceux qui exécutent. Une roadmap n'est pas un document politique — c'est une suite d'arbitrages assumés. Un backlog n'est pas une décharge à idées — c'est un système de décision.
Une équipe avec de bons outils livre dix fois plus qu'une équipe avec de bonnes intentions. Le client ressent toujours, tôt ou tard, le chaos interne. Le produit externe et les outils internes ne sont pas deux sujets séparés — c'est le même métier d'expérience.
Itérer, c'est s'engager, mesurer, apprendre, ajuster. Hésiter, c'est attendre que l'incertitude se dissipe avant de bouger. Mauvaise nouvelle : l'incertitude ne se dissipe que dans l'action.
Les scale-ups n'ont pas besoin de plus de bruit. Elles ont besoin de décisions plus claires, de PM mieux accompagnés, de fondateurs mieux positionnés, d'une organisation qui retrouve de la vitesse.
Bienvenue.
On débarrasse.
Ton équipe Product croule sous les rituels, les tickets et les priorités floues ?
On en parle →