Le modèle d’organisation où exerce un PO.

Dans l’organisation agile, on s’imagine que c’est la méthodologie employée (Scrum, kanban, scrumban etc..) qui défini le modèle d’organisation de l’entreprise.

En réalité, il ne faut pas confondre méthodologie et modèle d’organisation.

La méthodologie c’est un ensemble de principes, d’outils et de pratiques qui sont utilisés pour guider les processus de travail.  

Le modèle d’organisation c’est la façon dont les équipes sont organisées et distribuées pour répondre à une mission précise.
Peu importe s’il s’agit d’une startup, d’une PME ou d’un grand groupe.

Pourquoi je vous parle de ça ?

Parce que bien plus que la méthodologie agile employée, c’est le modèle d’organisation qui définit à 100% la mission du product owner.

Démarrez un poste de PO dans une entreprise et ne pas connaître son modèle d’organisation est une grave erreur à ne surtout pas commettre.

Si vous pensez que votre mission de PO est juste de gérer le produit sous l’angle de votre expertise métier, lisez attentivement ce poste.

Je vous partage les 4 modèles d’organisation à connaître :

• L’organisation en business Unit
• L’organisation agencée en pôle technologique
• Le modèle d’organisation produit / fonctionnalité
• Le modèle d’organisation agencé en marché / persona

Apprendre à cerner le modèle d’organisation est clé pour comprendre vos objectifs et connaître les moyens à votre disposition pour les atteindre.

AVANT PROPOS

Le produit en arrière plan 

Il est courant de dire que la mission du PO est d’être responsable du produit.

Pourtant, au risque d’en surprendre certains, je veux rétablir une vérité.

Le produit n’est jamais la mission principale.

Le produit est simplement la plateforme sur laquelle le product owner opère et influe.

Le PO n’améliore pas un produit juste pour la beauté du geste.
Sa mission doit servir un objectif précis.

En général, sa mission est défini tout en haut de l’organisation.

C’est au niveau du directeur, VP ou Head of product (appelé le comme vous voulez) ou même du CEO que se définissent les objectifs produit et business.

Une fois ceux-ci définis pour l’année en cours, le product owner a le champs libre pour définir sa roadmap produit et démarrer sa mission.

Seulement voilà, il y a toujours un truc que l’on oublie quand on parle de mission et d’objectifs du product owner.

Ce “TRUC”, c’est le modèle d’organisation.  A l’échelle du PO, le modèle d’organisation c’est

• À quoi ressemble son équipe ? 
• Quelles compétences englobent elle ?
• Quelle est l’objectif de l’équipe ?
• Quelles sont les autres équipes dans l’organisation avec lesquelles vous collaborez ?

Votre mission dépend du modèle d’organisation

Comme pour les objectifs, c’est également le top management qui défini le modèle d’organisation. 

En modelant l’organisation en différentes divisions ou équipes, le management limite plus ou moins, sans le savoir, le périmètre du product owner.

Je dis “sans le savoir” car j’ai rencontré beaucoup d’entreprises qui ont un modèle d’organisation non réfléchi.

Dans beaucoup de cas, le modèle s’établit de façon organique au fur et à mesure que la boite grandit.

Les équipes sont distribuées en fonction des négociations continues entre certains membres du middle management et le top management.

Parfois le modèle d’organisation est simplement un copier coller du modèle d’une autre entreprise.
Il suffit qu’un VP soit familier avec un modèle pour qu’il en touche un mot au CEO afin de le convaincre de l’adopter.
Parfois, l’entreprise copie simplement le modèle de la concurrence.

Néanmoins, je pense qu’il y a quand même un petit pourcentage d’entreprises qui réfléchissent à leur modèle.

Mais même en y réfléchissant sérieusement, le modèle penche toujours d’un côté.

Ce côté est variable en fonction des affinités du top management avec une expertise.

• Par exemple, si le CEO est un ancien ingénieur. Vous avez toutes les chances que le modèle d’organisation donnera plus de pouvoir au pôle technique.

• Si à l’inverse, le CEO est obsédé par la rentabilité, le modèle d’organisation sera tourné vers les données analytiques et le cost-killing à tous les étages (pour les cas extrêmes).

Sachez vous repérer

Bref, mon but n’est pas de juger quel modèle est le mieux.
Pour être honnête, il n’existe pas un modèle idéal qui fonctionne pour tout le monde.

Le modèle se définit en fonction du type d’entreprise, du service/produit, du marché, des objectifs à long termes etc…

L’idée ici est que vous réalisiez à quel point le modèle d’organisation de votre entreprise impacte sur votre job de product owner au quotidien.
Ce modèle peut parfois vous permettre d’exercer en toute liberté alors que pour d’autres ce modèle vous limite.

En vous exposant les 4 modèles qui vont suivre, mon objectif est que vous puissiez analyser quel modèle vous convient le mieux.

C’est parti.

1. MODÈLE D’ORGANISATION EN BUSINESS UNIT

C’est quoi ?

Ce que j’appelle business unit, c’est un modèle où chaque équipe est tournée vers un objectif mesurable précis et toujours identique.

En général, il s’agit d’une des KPIs de l’entreprise.

Par exemple, une équipe est en charge de l’acquisition clients, une autre de la rétention et encore une autre de l’optimisation des revenus.

Ce modèle se calque en général sur le framework AARRR.

AARRR est l’acronyme anglais de Acquisition, Activation, Retention, Referral et Revenu.

Si vous ne connaissez pas, je vous conseille d’aller jeter un oeil sur le lien que je vous ai mis en référence. C’est passionnant.

Set up de l’équipe :

Que le modèle se base sur le framework AARRR ou d’autres KPIs, ici l’équipe du product owner n’est pas tournée sur une fonctionnalité ou un produit précis.

L’idée est de faire grimper ou chuter (selon la KPIs) une métrique au fil des mois.

Tous les moyens sont bons et cela demande une équipe aux compétences 360.

• Un UX designer :  Pour des retouches, des optimisations ou carrément un redesign complet
• Un UX researcher : Pour sonder le marché et tester des idées.
• Un copywriter : En particulier si vous êtes centré sur l’activation, il vous faudra quelqu’un qui puisse raconter une histoire utilisateur.
• Un product analyst : Vous devez surveiller constamment les métriques et connaître quels sont les points de levier.
• Un frontend (1 minimum) : Pour implémenter les modifications UX
• Un backend (1 minimum) : Pour implémenter des fonctionnalités plus lourdes qui font appel à de la base de données ou des APIs.

Bonus:

• 1 développeur mobile (Android, iOS ou les 2), si vous opérez sur des produits mobiles natifs.
• 1 data scientist : Pour fouiller dans les données et établir des nouveaux business cases

Mon avis : 

Ce genre de modèle convient certainement plus à des product owners qui ont un background business ou analytiques.
Vous travaillerez en étroite collaboration avec le support, le département marketing et le(s) product manager(s)

Tout est centré sur un objectif business (beaucoup plus que sur un objectif produit).
A moins que vous couriez après l’optimisation du NPS, la qualité du produit n’est pas la priorité numéro 1.

Si l’entreprise dispose de plusieurs produits, vous ne serez pas assigner à un seul produit.

Il y a fort à parier que vous touchiez à tous les produits afin de multiplier vos chances d’atteindre votre objectif.

2. MODÈLE D’ORGANISATION EN PRODUIT / FONCTIONNALITÉ

C’est quoi ?

Ce modèle c’est un peu le modèle auquel s’attendent tous les product owners quand ils débutent leur carrière.

En résumé, il s’agit d’un modèle où l’équipe a la responsabilité entière d’un produit.

Le product owner et son équipe sont en charge de concevoir, optimiser et assurer la maintenance d’un seul produit.

Parfois quand un produit est très dense, le focus peut être centré sur une seule fonctionnalité plutôt que le produit entier.

Par exemple:

• L’équipe dédiée à la fonction recherche et catalogue sur un site e-commerce
• L’équipe dédiée à la fonction tchat et commentaires sur un réseau social
• etc…

Dans ce modèle, l’équipe est transverse au niveau de la plateforme.

En effet, imaginons que le PO à la responsabilité d’une seule fonctionnalité, il devra s’assurer que cette fonctionnalité soit implémentée sur le site web, les applications iOS, Android etc…

Au niveau performance business, le PO sera en charge de contrôler toutes les KPIs importantes pour la santé du produit ou fonctionnalité qu’il a en charge.

Set up de l’équipe :

Dans ce modèle, il n’y a pas vraiment de setup équipe prédéfini.

Vous devez avoir toutes expertises techniques requises pour opérer sur les technologies sur lesquelles reposent le produit.

En général, vous avez une équipe plus grande que la normale (Au minimum 6 voir 7 membres).

Pour ne pas avoir une usine à gaz à gérer, les expertises design, marketing et data sont souvent détachées de votre équipe.

Ces expertises travaillent à vos cotés à la demande quand vous avez un besoin.

Mon avis : 

Ce modèle d’organisation requiert une certaine expérience de la part du PO.  En général, seuls les POs déjà senior ont la main sur ce genre de modèle.
Encore plus, s’il s’agit de gérer un produit entier car cela nécessite un contrôle 360.
Si le produit est multi-plateforme, il faut avoir un minimum de background technique pour gérer les différentes technologies.

Au niveau marché et KPIs, une expertise business est nécessaire pour analyser et prendre les bonnes décisions.

Dans ce modèle, vous êtes le CEO du produit. 

3. MODÈLE D’ORGANISATION EN POLE TECHNOLOGIQUE 

C’est quoi ?

C’est clairement le modèle old school.
Il est souvent adopté par des entreprises moins agiles où le pouvoir penche du côté ingénierie.

Dans ce modèle, les équipes ne sont pas transverses, elles sont réunies en expertise technologique.

• La team backend
• La team frontend
• Les développeurs serveur
• L’équipe Android
• L’équipe iOS
• Etc…
  

Set up de l’équipe :

En tant que product owner, vous pouvez être dans 2 situations :

Cas 1 :

Votre équipe est entièrement backend par exemple. Vous n’avez pas de frontend, pas de UX designers etc…

Du coup votre mission est clairement limitée à des projets uniquement backend.
Dans ce modèle vous êtes un peu un responsable technique (Technical lead) :

• Par exemple, imaginez qu’il faille une nouvelle fonctionnalité produit qui requiert une expertise backend et une expertise frontend.
• Vous ne travaillez que sur la partie backend. Le reste n’est pas entre vos mains et sera géré par l’équipe qui est en charge du frontend.

Cas 2 : 

Vous n’avez pas vraiment d’équipe fixe. Peut être juste un UX designer et un copywriter.
Le reste quand vous définissez un projet ou une user story qui requiert différentes expertises techniques, vous serez à la merci des disponibilités des ressources disponibles.

Mon avis : 

C’est juste mon avis personnel, mais je trouve ce modèle trop cloisonné.

Peu importe le cas dans lequel vous vous trouvez, votre autonomie et marge de manoeuvre sont très limitées.
En effet, le manque de transversalité vous pénalise dans l’avancement de vos projets.
Vous êtes toujours dépendant de quelqu’un d’autre. Cela crée des goulots d’étranglements un peu partout.

A moins que vous vous épanouissez dans des missions ciblées uniquement sur la résolution de problèmes techniques, ce genre de modèle n’est pas fait pour vous.

Au passage, pas besoin de vous rappeler que votre background doit être technique.

4. MODÈLE D’ORGANISATION AGENCÉ EN MARCHÉ / PERSONA

C’est quoi ?

On retrouve ce modèle dans des entreprises qui s’adressent à différents clients en même temps comme les places de marché par exemple.

Pensez AirBnB.
Dans le même produit. il y a 

• Une expérience dédiée aux voyageurs qui veulent réserver une chambre, un appart, une maison
• Une expérience dédiée aux propriétaires qui mettent en location leurs biens.

Ou plus simplement, les acheteur et les vendeurs.

Ce modèle est un peu un hybride entre le modèle d’organisation en business unit et celui produit / fonctionnalité.

Vous devez êtes concentré sur un groupe de fonctionnalités bien spécifiques qui sont liées à un marché ou une démographie utilisateurs.

Par essence, en vous focalisant sur une démographie spécifique, vous êtes en charge de KPIs bien spécifiques.

Set up de l’équipe :

Comme pour le modèle produit, il n’y a pas vraiment de setup équipe prédéfini.

Vous devez avoir une équipe aux compétences transverses qui répondent au besoin produit et marché. 
Si vous travaillez sur un produit multi-plateforme, vous devez gérer toutes les technologies pour répondre au besoin utilisateur cross platforms.

Mon avis : 

C’est l’un des modèles en vogue depuis quelques années.
Cela fait sens dans plus en plus de business et apporte un cadre et un objectif bien défini à votre mission.

Pour ma part, j’opère actuellement dans ce modèle et je trouve qu’il requiert d’avoir beaucoup d’expertises différentes.
C’est le modèle idéal pour ceux qui aiment développer des nouvelles fonctionnalités produit et créer de l’impact à court terme.

A chacun son modèle

J’espère que ce post vous a permis de prendre conscience de l’importance des modèles d’organisation.

En cherchant un nouveau job, beaucoup de product owners se réfèrent à des paramètres qu’ils croient importants tels que :

• La taille de l’entreprise (Startups, Grands groupes…)
• La méthodologie agile utilisée (Scrum, Safe…)
• L’industrie (Fintech, E-commerce…)
• Le marché (BtoB, BtoC…)
• L’expertise métier (Design, Business…)

Ces paramètres sont évidemment importants pour comprendre votre mission et savoir si vous êtes apte. 

Malheureusement, sans connaître le modèle d’organisation, vous ne pouvez pas comprendre la réalité du rôle.

La cause du problème est que beaucoup d’entreprises ou de recruteurs n’abordent pas leur modèle d’organisation car il n’ont pas conscience de son impact sur le quotidien du PO.

C’est à vous de poser les questions :

• Intéressez vous à la structure de votre future équipe.
• Sachez comment vous allez collaborer avec les autres équipes.
• Connaissez les conséquences de chaque modèle.

En répondant à ces questions vous éviterez de mauvaises surprises.