Those who, like me, have watched Top Chef or Kitchen Nightmares, 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 ” ( ).

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”.

Rule 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.

Rule 2, the intention: to bring out the strategy of your product “organisation”

Organisational policy are the principles that will guide the organisation. The intention of the organisation: what organisational success would look like .

This policy aims to:

  • Reduce complexity / ambiguity
  • Exploit the advantage of focus
  • Give guidance to decide if an organisational problem needs to be resolved or not
  • While allowing the product strategy to be realised

But be honest with yourself: does your culture really allow you to apply these principles? “Culture eats strategy for breakfast.” (Drucker): It is the OS of your organisation . Try to remove the cultural barriers before embarking on principles of autonomy or transparency. Conversely, ask yourself what elements of your culture, unique to your business, can be turned into an advantage. Tip: Use the power of example. Your culture is not what you say, but what you do.

These organisational principles must be summarised in one or a few sentences. Ideally, I advise you to find a metaphor that summaries the approach: it will always be more meaningful.

For example, imagine that your product intent is: “Switch from a 1 star to a 3 star restaurant”. Your organisational intent might be: “As a single team, we take care of the customer and offer them a personalised experience every time they visit, from their first contact with the product, to their departure.”

Rule 3, the focus: determining a small set of coherent and achievable goals to prioritise actions for the organisation

It will then be up to you to decline this intent into coherent objectives, achievable and actionable to approach this target vision (it’s crazy, it looks like OKRs annual objectives), and meet the challenge.

Some examples:

  • Diagnosis: The objectives between departments lead to sometimes antithetic directions in the same team (eg stability vs. innovation, or acquisition vs. retention)

Objective: All members of the same squad share the same objectives, regardless of their department.

  • Diagnosis : No one, today, ensures the coherence of the experiment, each team working on its side.

Objective: The designers ensure the consistency of the experience, regardless of the organisational division.

Ex: The customer is not aware of the number of teams in the kitchen. They only know one person: the product / brand.

These organisational objectives must be shared by all and come to feed your organisational roadmap . They will be broken down into implementation actions (tactical objectives), carried out by the organising team and the teams concerned, as you would do with quarterly OKRs (there is a pattern there, no?). These actions will populate the release plan and the organisational backlog , visible to all.

For example, the first steps to reach “The designers ensure the coherence of the experience, no matter the organisational division”:

  • Each team must be able to count on identified design resources;
  • No design interlocutor should support more than 2 teams;
  • Designers must have dedicated time to exchange at least once per sprint …

Rule 4, the factivism: experiment, measure, communicate and iterate

Each of these actions in your organisational backlog must be measurable (qualitatively or quantitatively). They are the equivalent of a Key Result, and ideally contribute to a metric of the product strategy. As for features:

  • Emit impact hypotheses before (= how to measure success), not after
  • Test first on the most motivated teams, ready to face organisational bugs
  • First, optimise what works, rather than trying to change at all costs
  • Clean what does not seem necessary anymore
  • Finally, document the organisation and its changes, such as the features of a product

Examples of measures:

  • To members of a team: productivity (learning, time to impact), pride / ownership, shared impression of participating in choices, pot frequencies, NPS
  • With end users: increased impact (metrics) of use and business
  • With stakeholders: clarity / understanding, quality of inputs

And the processes?

Processes are a way to align when it does not come naturally. So do not put any new processes unless absolutely necessary . And ask yourself if there are perhaps no other solutions: motivate (to talk to each other), do tests with volunteers, recruit different profiles … 

It’s up to you to develop accountability, culture, understanding why.

Audit your processes regularly. Is the X process still useful? For what benefit? What would happen worse if we removed it? If a process exists to prevent a reversible error, it is a bad process.

You will avoid accumulating organisational debt .

In conclusion : Organisation as a Product = ?

An organisation is produced if it responds to 3 laws:

  • Law of the Client / User
  • Law of the small team
  • Law Network

If you want to evolve your organisation as a product:

  • Establish an honest diagnosis , and express it as a challenge;
  • Bring out an organisational policy , the intention of your organisation;
  • Put the focus on a set of coherent objectives;
  • Establish an organisational backlog and be factivist
  • In short: establish good organisational OKRs !

Of course, do not go alone ! Form an organisational team, with whom you will make regular points. Do you say that the more support comes from “above”, the more effective the change will be.

Finally, remember that culture is the OS of your organisation . No “model”, whether from a large company (Spotify) or an institute (SaFE, LeSS, DAD …), will remove your cultural barriers. But that’s for another article;)

Do you want to go further?

You are a product profile manager and want to know:

  • How to define / evolve your culture?
  • How to set your organisational strategy and change the organisation in practice?
  • How to align teams?
  • How to recruit the right profiles and retain them?

So come follow the Head of Product Management & Organisation training !

You want to find the best way to adapt as an organization, and to work all the departments (HR, Marketing, product, tech …) to achieve the best products ? Thiga can assist you in this process and especially our brand new Head of Product Organisation, Guillaume de Laroque. Contact us !

Want some reading in the meantime? Download our white paper on Product Oriented Organisations 

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!