Ceux qui, comme moi, ont trop regardé Top Chef ou Cauchemar en cuisine, le savent : ce n’est pas le nom, la carte ou les jolis couteaux qui font un bon restaurant. La clé, c’est l’organisation, dans la cuisine ET dans la salle.
Pourquoi ? Parce que votre produit est le reflet de l’organisation (on remercie Melvin Conway et la loi qui porte son nom). Malheureusement, beaucoup d’organisations “Produit” n’en ont que le nom. Et ce qui en sort en production ne peut, en aucun cas, se qualifier de bon produit.
Être Produit, ou ne pas être
En 2011, Marc Andreessen écrivait son célèbre “Software is eating the world."
En France, à l’époque, on parlait alors encore peu de Produit. Certaines entreprises se mettaient en “mode agile”, souvent de la mauvaise façon : on se dépêchait de nommer des “Product Owners” et de passer tout le monde en Scrum. Faire des daily stand-ups semblait ainsi donner le droit de dire “on est une organisation agile”.
Aujourd’hui - si vous me permettez de reprendre le mot d'Andreessen avec un pas de côté - “Product is feeding the world”. En réconciliant marketing et technique, le Produit a transformé la technologie d’un centre de coûts, en un centre de profits, qui tire la croissance mondiale vers le haut.
Mais le Produit semble être le “nouvel Agile”, et beaucoup d’entreprises, malheureusement, reproduisent les mêmes erreurs. Maintenant, singer Spotify en s’organisant en “feature teams” (qui sont pour la plupart des équipes de delivery), apparaît aux yeux de beaucoup comme un passeport pour affirmer que l’“on est orienté produit”.
Alors, c’est quoi “vraie” organisation Produit ?
Pour savoir si une organisation est Produit, c’est simple : elle doit respecter trois lois.
- La Loi du Client / Utilisateur : l’obsession de l’impact utilisateur est la raison d’être de l’organisation.
- Loi de la Petite équipe : on présume que de petites équipes autonomes doivent porter le travail, travaillant en cycles courts et suivant la loi du Client (Time to Impact).
- Loi du Réseau : l’ensemble de l’organisation fait un effort continu pour faire disparaître la bureaucratie, la hiérarchie et les process inutiles.
Peu importe alors la façon dont vous allez “découper” une “feature team” ou une “impact team” qui ne vivrait pas en accord avec ces trois lois, ne serait simplement pas une équipe produit. End of story.
Appliquer la pensée Produit à l’organisation
Mais respecter ces trois lois n’est que le premier pas vers une bonne organisation produit. Car elle ne libérera réellement son potentiel uniquement si on la considère comme un produit à part entière, dont les utilisateurs seraient les collaborateurs.
En voyant l’organisation comme un ensemble de fonctionnalités, on va donc pouvoir lui appliquer les préceptes du Product Management pour la faire évoluer et livrer plus de valeur, aux utilisateurs comme à l’entreprise.
Une entreprise n’est donc “user-centric” et “data informed”, que si elle bâtit une organisation “user centric” et “data informed”.
Précepte 1, le diagnostic : toujours commencer par le problème
Peter Drucker écrivait en Janvier 1974 (toute ressemblance avec votre dernière réorganisation serait fortuite… ou pas) :
“Les entreprises ont recours à la réorganisation comme à un remède miracle au lieu de diagnostiquer leurs maux.
La chirurgie organisationnelle est utilisée à mauvais escient pour régler un problème procédural relativement mineur ou - plus souvent encore - pour éviter de prendre des décisions liées au personnel
Il est fréquent aussi que l'on utilise la réorganisation à tort comme un substitut à la réflexion profonde sur les objectifs, les stratégies et les priorités”.
C'est donc pour éviter de tomber dans ces travers que l'on établit un diagnostic de l'organisation. Le but est ainsi d'identifier les obstacles et problèmes organisationnels fondamentaux, de façon honnête et exhaustive, qui nous empêchent ou nous ralentissent dans la réalisation de la stratégie Produit elle-même.
En bon Product, débutez par récolter l'information à la source : interviewez des collaborateurs, observez les comportements individuels et collectifs, faites du Shadowing… Puis analysez et creusez : quels sont les “patterns” qui se détachent ? Sont-ce de vrais problèmes organisationnels ? Des perceptions biaisées ? Des problématiques personnelles ? D'où viennent-ils ? Quel est leur impact ? Sur qui ?
Considérez bien tous les personas de l’organisation : équipes produit bien sûr, mais aussi ceux qui collaborent (marketing, sales, support…), le CoMex, le Board… et l’utilisateur final !
Comme un utilisateur, les collaborateurs doivent être convaincus de la réalité des problèmes et de l'importance de les régler. Sinon, ils n'achèteront pas les évolutions de l'organisation. A vous de les convaincre, par les faits, de la réalité des problèmes… et de la proposition de valeur de chaque changement.
Réduisez les problèmes au maximum, jusqu’à la cause racine. Il ne s’agit pas de faire une liste à la Prévert, mais de bien définir le challenge, et d’émettre une politique organisationnelle pour répondre aux obstacles identifiés dans le diagnostic.
Précepte 2, l’intention : faire émerger la stratégie de votre produit “organisation”
La politique organisationnelle se constitue de principes qui vont guider l’organisation. C’est l’intention de l’organisation (le “commander’s intent’ en anglais) : ce à quoi le succès organisationnel ressemblerait.
Ainsi, cette politique a pour but :
- Réduire la complexité / l'ambiguïté
- Exploiter l’avantage du focus
- Donner un guide pour décider si un problème organisationnel mérite d’être résolu ou non
- tout en permettant, évidemment, de rendre possible la réalisation de la stratégie produit.
Mais soyez honnêtes avec vous-mêmes : votre culture vous permet-elle vraiment d'appliquer ces principes ? “Culture eats strategy for breakfast.”(P. Drucker) : elle est l'OS de votre organisation. Tentez donc de lever les barrières culturelles avant de vous lancer dans des principes d'autonomie ou de transparence. Inversement, demandez-vous quels éléments de votre culture, uniques à votre entreprise, peuvent être transformés en avantage. Petit conseil : utilisez la force de l'exemple et de l'exemplarité. Votre culture n’est pas ce que vous dites, mais ce que vous faites.
Ces principes organisationnels doivent alors se résumer à une ou quelques phrases. Idéalement, je vous conseille de trouver une métaphore qui résume l’approche : elle sera toujours plus parlante.
Par exemple, imaginons que votre intent produit soit : “Passer d’un Flunch à un restaurant 3 étoiles”. Votre intention au niveau organisationnel pourrait donc être : “Comme une seule équipe, nous prenons soin du client et lui offrons une expérience personnalisée à chacune de ses visites, depuis son premier contact avec le produit, jusqu’à son départ”.
Précepte 3, le focus : déterminer un ensemble réduit d’objectifs cohérents et atteignables pour prioriser les actions sur l’organisation
Il vous reviendra ensuite de décliner cet intent en objectifs cohérents, atteignables et actionnables pour s’approcher de cette vision cible (c'est fou, on dirait des objectifs annuels d'OKRs), et répondre au challenge.
Quelques exemples :
- Diagnostic : Les objectifs entre départements amènent à des directions parfois antithétiques dans la même équipe (ex : stabilité vs innovation, ou acquisition vs rétention)
Objectif : Tous les membres d’une même squad partagent les mêmes objectifs, quel que soit leur département.
- Diagnostic : Personne, aujourd’hui, n’assure la cohérence de l’expérience, chaque équipe travaillant de son côté.
Objectif : Les designers assurent la cohérence de l’expérience, peu importe le découpage organisationnel.
Ex : Le client n’a pas conscience du nombre d’équipes en cuisine. Il ne connaît qu’une seule personne: le produit / la marque.
Ces objectifs organisationnels doivent être partagé par tous et venir alimenter votre roadmap organisationnelle. Ils se déclineront en actions d’implémentation (des objectifs tactiques), menées par l’équipe d’organisation et par les équipes concernées, comme vous le feriez avec des OKRs trimestriels (il y a un pattern là, non?). Ces actions viendront peupler le release plan et le backlog organisationnel, visible de tous.
Par exemple, les premiers pas pour atteindre “Les designers assurent la cohérence de l’expérience, peu importe le découpage organisationnel” :
- Chaque équipe doit pouvoir compter sur des ressources design identifiées ;
- Aucun interlocuteur design ne doit prendre en charge plus de 2 équipes ;
- Les designers doivent disposer de temps dédié pour échanger au moins une fois par sprint…
Précepte 4, le factivisme : expérimentez, mesurez, communiquez et itérez
Chacune de ces actions de votre backlog organisationnel doit être mesurable (qualitativement ou quantitativement). Elles sont l’équivalent d’un Key Result, et idéalement contribuent à une métrique de la stratégie produit. Comme pour des fonctionnalités :
- Emettez des hypothèses d’impact avant (= comment mesurer le succès), pas après
- Testez d’abord sur les équipes les plus motivées, prêtes à affronter des bugs organisationnels
- Optimisez d’abord ce qui fonctionne, plutôt que de chercher à changer à tout prix
- Nettoyez ce qui ne semble plus nécessaire
- Enfin, documentez l’organisation et ses changements, comme les features d’un produit
Exemples de mesures :
- Auprès des membres d’une équipe : productivité (learning, time to impact), fierté / ownership, impression partagée de participer aux choix, fréquences des pots, NPS
- Auprès des utilisateurs finaux : augmentation de l’impact (métriques) d’usage et business
- Auprès des stakeholders : clarté / compréhension, qualité des inputs
Et les process ?
Les process sont un moyen d’aligner quand ça ne vient pas naturellement. N’introduisez donc de nouveaux process que si c’est absolument nécessaire. Et demandez-vous alors s'il n'y a pas peut-être d’autres solutions : motiver (à se parler), faire des tests avec des volontaires, recruter des profils différents…
A vous de développer la responsabilisation, la culture, la compréhension du pourquoi.
Auditez vos process régulièrement. Le process X est-il toujours utile ? Pour quel bénéfice ? Qu’arriverait-t-il de pire si on le supprimait ? Si un processus existe pour empêcher une erreur réversible, il s’agit d’un mauvais process.
Vous éviterez ainsi d’accumuler de la dette organisationnelle.
En conclusion : Organisation as a Product = ?
Une organisation est Produit si elle répond à 3 lois :
- Loi du Client / utilisateur
- Loi de la petite équipe
- Loi du réseau
Si vous voulez faire évoluer votre organisation comme un produit :
- Etablissez un diagnostic honnête, et exprimez-le sous forme de challenge ;
- Faites aussi émerger une politique organisationnelle, l’intention de votre organisation ;
- Mettez ensuite le focus sur un ensemble d’objectifs cohérents ;
- Etablissez un backlog organisationnel et soyez factiviste ;
- En somme : établissez de bons OKRs organisationnels !
Evidemment, n’y allez pas seul.e ! Formez une équipe organisationnelle, avec qui vous ferez des points réguliers. Dites-vous que, plus le soutien vient “d’en haut”, plus le changement sera efficace.
Enfin, rappelez-vous que la culture est l’OS de votre organisation. Aucun “modèle”, qu’il soit issu d’une grande entreprise (Spotify) ou d’un institut (SaFE, LeSS, DAD…), ne lèvera vos barrières culturelles. Mais ça, c’est pour un autre article ;)
Vous voulez aller plus loin ?
Si cet article vous a plu, les formations "Product Leaders" de Thiga Academy dédiées aux managers des organisations produit vous intéresseront particulièrement : Head of Product Chief Product Officer (CPO)
Vous voulez trouver le meilleur chemin pour vous adapter en tant qu’organisation, et faire travailler l’ensemble des départements (RH, Marketing, produit, tech…) afin de réaliser les meilleurs produits ? Thiga peut vous accompagnent pour passer d'une organisation traditionnelle à une organisation orientée Produit.
Vous voulez un peu de lecture en attendant ? Téléchargez notre livre blanc sur les Organisations orientées produit
