Those who, like me, have watched Top Chef or Nightmare in the kitchen, know it: it’s not the name, the menu or the pretty knives that make a good restaurant. The key is the organization, in the kitchen AND in the room.

Why? Because your product is a reflection of the organization (we thank Melvin Conway and the law that bears his name). Unfortunately, many “Product” organisations only have the name. And what comes out in production, is described as a good product.

To be produced, or not to be

In 2011, Marc Andreessen wrote his famous ” Software is eating the world ” ( https://www.wsj.com/articles/SB10001424053111903480904576512250915629460 ).

In France, at the time, there was still little talk of product. Some companies were putting themselves in “agile mode”, often in the wrong way: we hurried to name “Product Owners” and to pass everyone in Scrum. Doing daily stand-ups seemed to give the right to say “we are an agile organisation”.

Today – if you will allow me to take Andreessen’s word with one step back – ” Product is feeding the world “. By reconciling marketing and technology, the Product has turned technology from a cost center into a profit center that is driving global growth up.

But the Product seems to be the “new Agile”, and many companies, unfortunately, reproduce the same mistakes. Now, Spotify singer by organizing themselves into ” feature teams ” (which are mostly delivery teams), appears to many as a passport to affirm that “we are product oriented”.

So, what is “true” product organisation?

To know if an organization is produced, it’s simple: it must respect three laws.

  • The Law of the Client / User : the obsession of the user impact is the raison d’être of the organisation.
  • Law of the Small Team: it is presumed that the work must be carried by small, autonomous teams working in short cycles and following the Customer’s law (Time to Impact).
  • Law of the Network: the whole organisation makes a continuous effort to eliminate bureaucracy, hierarchy and useless processes.

No matter how you’re going to “cut out” a “feature team” or an “impact team” that would not live up to these three laws, it just would not be a product team. End of story.

Apply product thinking to the organisation

But respecting these three laws is only the first step towards a good organisation. Because it will really unlock its potential only if it is considered a product in its own right, whose users would be the collaborator.

Seeing the organisation as a set of features, we will be able to apply the precepts of Product Management to make it evolve and deliver more value to users and the company.

A company is therefore “user-centric” and “data informed”, only if it builds an organisation “user centric” and “data informed”.

Precept 1, diagnosis: always start with the problem

Peter Drucker wrote in January 1974 (any resemblance to your last reorganisation would be fortuitous … or not ):

“Companies are resorting to reorganisation as a miracle cure instead of diagnosing their ailments.


The organisational surgery is misused to resolve a relatively minor procedural problem or – more often – to avoid taking decisions related to staff.


It is also common for reorganisation to be misused as a substitute for deep reflection on goals, strategies and priorities. ”

It is to avoid falling into these gaps that a diagnosis of the organisation is made. The goal is to identify fundamental organisational and hurdles, honestly and comprehensively, that prevent or slow us in achieving the Product Strategy itself.

As a good product, start by collecting information at the source: interview collaborators, observe individual and collective behavior, do Shadowing … Then analyze and dig: what are the “patterns” that stand out? Are these real organizational problems? Biased perceptions? Personal issues? Where do they come from ? What is their impact? On which ?

Consider all the personas of the organisation: product teams of course, but also those who collaborate (marketing, sales, support …), the CoMex, the Board … and the end user!

As a user, employees must be convinced of the reality of the problems and the importance of resolving them. Otherwise, they will not buy the changes in the organisation. It’s up to you to convince them, by the facts, of the reality of the problems … and the value proposition of each change.

Minimise problems to the root cause. It is not a question of making a random list, but of defining the challenge well, and of issuing an organisational policy to answer the obstacles identified in the diagnosis.

Precept 2, the intention: to emerge the strategy of your product “organisation”

La politique organisationnelle est constituée des 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

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. A l’inverse, 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 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 ê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 seront déclinés 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 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 émerger une politique organisationnelle, l’intention de votre organisation ;
  • Mettez 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 ?

Vous êtes manager de profils Product et voulez savoir :

  • Comment définir / faire évoluer votre culture ?
  • Comment fixer votre stratégie organisationnelle et faire évoluer l’organisation dans la pratique ?
  • Comment aligner les équipes ?
  • Comment recruter les bons profils et les retenir ?

Alors venez suivre la formation Head of Product Management & Organisation !

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 accompagner dans cette démarche et particulièrement notre tout nouvel Head of Product Organisation,  Guillaume de Laroque. Contactez-nous !

Vous voulez un peu de lecture en attendant ? Téléchargez notre livre blanc sur les Organisations orientées produit 

Ces articles pourraient vous intéresser

Leave a Reply

Your email address will not be published. Required fields are marked *

La Newsletter des Product Managers

Recevez nos articles 2 fois par mois et devenez un top gun du Product Management!