Product operating model : définition et principes

Le product operating model, ou modèle opérationnel produit, parfois abrégé POM et souvent appelé simplement product model ou modèle produit, désigne la manière dont une entreprise décide quoi construire, à qui elle confie ces décisions et comment elle mesure le résultat. Ce n’est ni une méthode, ni un organigramme : c’est un régime de décision.

Cette distinction paraît théorique et elle est en réalité toute la difficulté du sujet. Le terme est arrivé en France par la traduction de la littérature produit américaine, et il s’y est immédiatement mélangé avec deux choses qu’il n’est pas : une réorganisation d’équipes et une démarche d’agilité. Cet article sépare les trois, décrit les composantes réelles du modèle, et donne les signes qui permettent de savoir si une entreprise y est passée ou si elle en a seulement adopté le vocabulaire.

Product operating model : ce que le terme désigne vraiment

Deux lectures du terme circulent, et elles n’ont pas du tout les mêmes conséquences. La première en fait une organisation : des équipes pluridisciplinaires, un nouveau schéma, des rôles renommés. La seconde en fait un régime de décision : ce qu’on demande à une équipe, qui a le droit de trancher, et à quoi l’on reconnaît que le travail a servi. Seule la seconde correspond à ce que décrivent les auteurs du modèle.

Une façon de décider, pas un organigramme

Marty Cagan, fondateur du Silicon Valley Product Group, a posé la définition qui sert aujourd’hui de référence dans son introduction au product operating model : un modèle conceptuel reposant sur un ensemble de principes premiers — first principles — que les entreprises technologiques les plus solides tiennent pour vrais au sujet de la fabrication de produits. Sa formulation la plus utile tient en une opposition : il s’agit d’obtenir des résultats plutôt que de produire des livrables. Rien, dans cette définition, ne prescrit une taille d’équipe, un rituel ou une ligne hiérarchique.

L’écart entre les deux lectures est très concret. Un organigramme se décrète : il suffit d’un document et d’une date d’effet. Un régime de décision, lui, engage des personnes qui devront renoncer à quelque chose — un directeur qui n’arbitrera plus le détail d’un périmètre, un comité qui ne validera plus chaque fonctionnalité, un contrôle de gestion qui suivra autre chose qu’un pourcentage d’avancement. Le modèle produit se reconnaît donc moins à ses schémas qu’à la nature des questions posées en comité de direction.

Les trois questions auxquelles le modèle répond

Le modèle se déplie en trois questions, et l’ordre dans lequel on les traite compte autant que les réponses :

• Comment les solutions sont-elles construites ? Par livraisons petites, fréquentes et fiables. Cagan cite un rythme minimal d’une mise en production toutes les deux semaines, l’idéal étant le déploiement continu. La fréquence n’est pas un objectif de performance en soi : c’est ce qui rend l’apprentissage possible.
• Comment les problèmes sont-ils résolus ? L’équipe reçoit un problème à résoudre et un résultat attendu, non une liste de fonctionnalités. Elle doit trouver une solution à la fois désirable pour l’utilisateur, utilisable, techniquement réalisable et viable pour l’entreprise.
• Quels problèmes vaut-il la peine de résoudre ? Cette réponse appartient aux dirigeants : une vision, puis une stratégie produit nourrie par des insights, c’est-à-dire par ce que l’entreprise a réellement compris de ses utilisateurs, de ses données et de son marché.

Ces trois niveaux se tiennent comme les branches d’un mobile : déplacer l’un fait bouger les autres. Une stratégie produit impeccable confiée à une organisation incapable de livrer par petits incréments reste un document, et une équipe autonome sans direction claire produit des solutions élégantes à des problèmes secondaires.

Les composantes du modèle produit

Le product operating model se décompose en cinq domaines. Aucun ne fonctionne isolément, et c’est le constat qui coûte le plus cher à découvrir en cours de route : renforcer la discovery sans changer la façon de mesurer le succès produit un travail de recherche que personne n’utilise.

• La culture produit — des principes plutôt que des procédures, la confiance plutôt que le contrôle, l’apprentissage plutôt que la sanction de l’erreur.
• La stratégie produit — un petit nombre de paris assumés, dérivés d’insights et rendus transparents, au lieu d’un empilement de demandes internes.
• Les équipes produit — durables, pluridisciplinaires, responsables d’un résultat et non d’un lot de tickets.
• Le product discovery — vérifier vite et à faible coût qu’une idée mérite d’être construite.
• Le product delivery — livrer petit, souvent, de façon fiable, avec l’instrumentation qui permet de constater l’effet réel de ce qui a été mis en ligne.

Les équipes produit : des problèmes, pas une liste de fonctionnalités

C’est le déplacement le plus visible pour les personnes concernées. Dans le modèle projet, une équipe reçoit un périmètre et une date ; dans le modèle produit, elle reçoit un problème et un indicateur. Cela suppose qu’elle ait accès aux utilisateurs, aux données d’usage et aux contraintes de l’entreprise, sans quoi l’autonomie annoncée se réduit à une injonction. Un cadre comme les jobs to be done aide précisément à formuler un problème sous une forme que l’équipe peut instruire, et le product discovery lui donne les moyens d’y répondre autrement qu’à l’intuition.

La question des rôles vient après, et non avant. Le modèle ne prescrit pas d’intitulés de poste : il décrit des responsabilités à couvrir — la valeur et la viabilité, l’expérience, la faisabilité technique. Selon la taille de l’entreprise, elles se répartissent différemment, ce qui explique une bonne partie de la confusion française entre Product Manager et Product Owner. Renommer les postes sans redistribuer les décisions est l’erreur la plus fréquente, et la plus facile à commettre de bonne foi.

La mesure : des résultats plutôt que des livraisons

Une organisation obtient ce qu’elle mesure. Tant qu’un comité suit un nombre de fonctionnalités livrées et un taux d’avancement, les équipes optimiseront la sortie de fonctionnalités, y compris lorsque tout indique qu’elles ne servent à rien. Le modèle produit demande de formuler l’attendu comme un outcome, c’est-à-dire un changement observable de comportement ou de performance : un délai réduit, un taux de réussite de parcours amélioré, un volume de réclamations en baisse. C’est la logique des OKR, à condition de ne pas les remplir de livrables déguisés en résultats.

Le contrôle est simple à faire : regardez les indicateurs qui remontent au plus haut niveau. S’ils comptent des choses produites plutôt que des effets constatés, ce sont des vanity metrics à l’échelle de l’entreprise — d’autant plus rassurantes qu’elles ne descendent jamais.

Modèle produit ou modèle projet : ce qui change

Le modèle que le product operating model remplace a un nom : le modèle projet. Il fonctionne comme une chaîne de montage. Une instance décide d’un contenu, le découpe en lots, les confie à des équipes constituées pour l’occasion, puis mesure le respect du plan. Ce dispositif n’est pas absurde — il est très efficace quand la solution est connue d’avance, ce qui est le cas d’une migration technique ou d’une mise en conformité réglementaire. Il devient contre-productif dès que la bonne solution reste à trouver.

Dimension	Modèle projet	Product operating model
Unité de travail	Un projet daté, à périmètre annoncé	Une équipe durable rattachée à un produit
Ce qu’on confie à l’équipe	Une liste de fonctionnalités à livrer	Un problème à résoudre et un résultat à atteindre
Définition du succès	Livré dans les délais et le budget	Effet mesuré sur l’utilisateur et sur l’activité
Financement	Enveloppe votée par projet, une fois par an	Capacité financée en continu, révisée à intervalles courts
Qui décide du contenu	Une instance d’arbitrage, en amont	L’équipe, dans le cadre d’une stratégie explicite

La dernière ligne du tableau est celle qui coince. Les quatre premières se négocient ; la cinquième transfère un pouvoir. C’est pour cette raison que beaucoup d’entreprises adoptent les quatre premières colonnes de gauche en changeant seulement le vocabulaire, et s’étonnent que rien n’aille plus vite.

Product operating model, agile, Scrum et SAFe : où se situe chacun ?

Ces termes ne décrivent pas la même chose et ne se substituent pas l’un à l’autre. Le manifeste Agile énonce quatre valeurs et douze principes portant sur la manière de développer un logiciel : c’est une philosophie de travail, muette sur la façon de choisir les problèmes ou d’allouer un budget. Un framework agile comme Scrum en tire des pratiques d’équipe : des itérations, des rôles, des rituels. Le product operating model, lui, se situe un cran au-dessus : il décrit ce que l’entreprise demande à ces équipes et ce qu’elle accepte de leur déléguer.

Les cadres d’agilité à l’échelle occupent une position intermédiaire, et c’est là que naissent la plupart des malentendus. Un dispositif de synchronisation comme l’agile release train organise la coordination de plusieurs équipes autour d’un calendrier commun ; il ne dit rien de la question de savoir si ces équipes reçoivent des problèmes ou des fonctionnalités. On peut donc dérouler SAFe à la lettre en restant intégralement dans un modèle projet — et c’est le cas le plus fréquent lorsque la planification à l’échelle sert à figer un périmètre plusieurs trimestres à l’avance.

On peut appliquer Scrum sans être dans le modèle produit, et être dans le modèle produit sans faire de Scrum. Les deux répondent à des questions différentes.

Pourquoi une réorganisation ne suffit pas

Une réorganisation déplace des cases. Le modèle produit, lui, tient sur une clé de voûte : le droit de décider de ce qui sera construit. Retirez cette pierre et l’ensemble se comporte exactement comme avant, quel que soit le soin apporté au nouveau schéma d’équipes. C’est ce qui rend le sujet difficile à traiter par une direction seule : la pierre en question appartient souvent à la direction financière et au comité exécutif, pas à la direction produit ni à la direction des systèmes d’information.

Les trois décisions qui doivent réellement bouger

• Le financement — passer d’enveloppes votées par projet, à périmètre annoncé, à une capacité attachée à des équipes durables et révisée à intervalles courts. Sans cela, une équipe peut itérer autant qu’elle veut, elle ne peut pas changer d’avis.
• La définition du succès — remplacer la liste de livrables datés par un résultat attendu assorti de son indicateur. Le signe que c’est fait : une équipe peut livrer moins que prévu et être jugée en réussite.
• Le droit de renoncer — accepter qu’une fonctionnalité inscrite au plan soit abandonnée parce que l’équipe a appris qu’elle était inutile, sans dossier de justification. C’est la décision la plus inconfortable et la plus révélatrice.

Ces trois décisions relèvent d’un même niveau de responsabilité, celui du Chief Product Officer et de ses pairs au comité exécutif. Le product leadership — l’encadrement des équipes produit — en dépend directement : un responsable produit sommé de tenir un périmètre annoncé ne pourra pas donner à ses équipes l’autonomie que le modèle suppose, quelle que soit sa conviction personnelle.

Les signes d’un modèle produit de façade

Quatre symptômes reviennent avec une régularité frappante, et ils sont tous observables sans audit :

• La roadmap est restée une liste de fonctionnalités datées, simplement renommée. Le mot « produit » a remplacé le mot « projet » dans le titre du document.
• Les équipes sont pluridisciplinaires mais reçoivent des solutions déjà arbitrées ailleurs. Elles sont autonomes sur le comment, jamais sur le quoi.
• Le budget se vote toujours une fois par an, par périmètre. Toute réorientation en cours d’année suppose de rouvrir un dossier d’engagement.
• Aucune fonctionnalité n’a été abandonnée depuis douze mois. Dans un modèle qui apprend, une part des idées ne survit pas à la vérification ; un taux d’abandon nul signale qu’on ne vérifie rien.

Reste la question du chemin. Elle mérite un traitement à part, et je l’ai traitée séparément dans un article consacré à la transformation agile, ses étapes et ses causes réelles d’échec — la mécanique y est la même : ce qui bloque se situe presque toujours au-dessus des équipes. Deux repères, en attendant. Le premier vient de Teresa Torres, qui décrit dans son analyse du product operating model une progression par équipes pilotes plutôt qu’un basculement global : on commence là où un responsable peut réellement modifier l’enveloppe et les objectifs. Le second est l’ouvrage collectif TRANSFORMED, écrit par Marty Cagan avec Lea Hickman, Christian Idiodi, Chris Jones et Jon Moore, entièrement consacré à ce passage et adressé aux dirigeants autant qu’aux équipes.

Une remarque personnelle pour finir. Après plus de dix ans passés dans des organisations produit de tailles très différentes, la ligne de partage que j’observe ne passe ni par le vocabulaire employé, ni par la qualité des schémas d’organisation. Elle passe par une question beaucoup plus banale : lorsqu’une équipe apporte la preuve qu’une fonctionnalité prévue ne sert à rien, que se passe-t-il ? Si elle est retirée, l’entreprise est dans le modèle produit, même imparfaitement. Si elle est livrée quand même parce qu’elle figurait au plan, tout le reste est de la décoration.

FAQ — Tout savoir sur le product operating model

Qu’est-ce qu’un product operating model ?

C’est la manière dont une entreprise décide quoi construire, à qui elle confie ces décisions et comment elle mesure le résultat obtenu. Le modèle repose sur un principe simple : les équipes reçoivent des problèmes à résoudre et des résultats à atteindre, plutôt qu’une liste de fonctionnalités à livrer.

Que signifie l’abréviation POM ?

POM est l’abréviation courante de product operating model. On rencontre aussi « product model », « modèle produit » et « modèle opérationnel produit » : ces expressions désignent la même chose. Les traductions françaises varient encore selon les cabinets et les éditeurs, sans différence de fond.

Quelle est la différence entre product operating model et agile ?

L’agilité décrit une manière de travailler au niveau de l’équipe : itérations, boucles de retour, adaptation. Le product operating model décrit ce que l’entreprise demande à ces équipes et ce qu’elle leur délègue : le choix des problèmes, la définition du succès, le mode de financement. Une entreprise peut être agile dans ses pratiques et rester dans un modèle projet.

Quels sont les principes du product operating model ?

Cinq domaines structurent le modèle : la culture produit, la stratégie produit, les équipes produit, le product discovery et le product delivery. Le principe qui les relie est la primauté du résultat sur le livrable, avec des mises en production petites et fréquentes pour rendre l’apprentissage possible.

Faut-il adopter SAFe ou le modèle Spotify pour définir son product operating model ?

Non, et l’ordre inverse est plus sûr. Ces cadres répondent à la question de la coordination entre équipes, pas à celle de la répartition des décisions. Les copier sans avoir tranché qui choisit les problèmes et qui définit le succès ajoute des instances de synchronisation à un modèle projet inchangé.

Qui a créé le concept de product operating model ?

Le terme a été popularisé par Marty Cagan et le Silicon Valley Product Group, qui l’ont formalisé sur leur blog puis dans l’ouvrage collectif TRANSFORMED, coécrit avec Lea Hickman, Christian Idiodi, Chris Jones et Jon Moore. Les pratiques décrites, elles, préexistaient chez les entreprises technologiques qui les nommaient simplement « leur façon de travailler ».

Le product operating model est-il réservé aux grandes entreprises ?

Non. Une petite structure y est même souvent plus proche par nécessité : peu d’échelons, des décisions rapides, un contact direct avec les utilisateurs. La difficulté croît avec la taille, parce que le nombre d’instances à convaincre pour déplacer une décision augmente plus vite que le nombre d’équipes.