The Product Operating Model: The Key to Innovation and Agility

Comment des entreprises comme Amazon, Apple ou Tesla réussissent-elles à bouleverser régulièrement le marché avec des innovations révolutionnaires ? Et ce, à une vitesse qui laisse les autres entreprises bouche bée ? Dans son livre "TRANSFORMED", l'expert en gestion de produits de la Silicon Valley Marty Cagan apporte une réponse : le secret réside dans ce qu'on appelle le "Product Operating Model".

Le Product Operating Model est un framework qui aide les entreprises à rendre leur développement produit plus stratégique, plus orienté client et plus agile. Il se compose de trois éléments clés : Delivery, Discovery et Direction. Chacun de ces éléments répond à un défi central auquel les entreprises sont confrontées aujourd'hui.

Mais que se cache-t-il exactement derrière ces termes ? Sohrab Salimi, consultant et coach expérimenté en développement produit agile, collabore étroitement avec Marty Cagan depuis des années et met en œuvre avec succès son Product Operating Model dans la pratique. Un moment fort a également été les Agile Insights Conversations avec Marty, qui ont offert des aperçus précieux sur ses méthodes et approches.

Voici les liens vers les Agile Insights Conversations avec Marty et Sohrab :

https://youtu.be/RPHZO-ckDWA?si=zpeKxzPM-d9GINlG

https://youtu.be/k1JMyN3X5yw?feature=shared

Lors de sa présentation dans le cadre du Product Owner Day 2024, il explique les éléments clés et montre comment les entreprises peuvent les mettre en pratique.

Les éléments clés du Product Operating Model

Comme l'explique Sohrab, le Product Operating Model se compose essentiellement de trois éléments : Delivery, Discovery et Direction. Chacun d'entre eux répond à une question centrale que les entreprises doivent se poser pour rester innovantes et agiles.

Delivery : Comment nous assurer que nos produits sont développés et livrés de manière efficace et efficiente ?

Le premier élément "Delivery" concerne la capacité à délivrer continuellement de la valeur au client - et ce, dans des cycles aussi courts que possible. Comme le souligne Sohrab, c'est le prérequis fondamental pour la capacité d'innovation et d'adaptation. Pourtant, de nombreuses entreprises peinent à raccourcir leurs cycles de release souvent longs.

Ce n'est pourtant pas si difficile : il faut principalement de petites équipes cross-fonctionnelles et auto-organisées qui, dans leur chaîne de valeur de l'idée à la livraison, ont le moins de dépendances et de points de transfert possible. De plus, elles ont besoin de la confiance et de l'autorité pour prendre des décisions de manière autonome. Mais c'est précisément là que ça coince souvent, comme Sohrab le sait par son expérience de conseil.

Un modèle à suivre est certainement Amazon avec ses "Two Pizza Teams" - c'est-à-dire des équipes si petites que deux pizzas américaines suffisent à les nourrir. Ces équipes sont capables d'amener des produits ou des fonctionnalités de l'idée à la livraison en quelques semaines. Mais cela n'est possible que si les équipes ont aussi la liberté et la confiance pour décider et agir de manière autonome.

Si tu veux en savoir plus sur Amazon, nous te recommandons l'article suivant : https://www.agile-academy.com/de/agile-leader/die-10-wichtigsten-insights-aus-working-backwards-von-colin-bryar/

Un autre exemple de Delivery efficace est le framework Scrum, explicitement conçu pour délivrer de la valeur en cycles courts. Grâce aux Sprints, qui durent généralement de deux à quatre semaines, du logiciel fonctionnel est livré régulièrement. Cela permet aux équipes de réagir rapidement aux retours et d'apporter des améliorations continues. Scrum favorise les petites équipes cross-fonctionnelles qui sont en échange étroit avec les parties prenantes et ont l'autorité de prendre des décisions de manière autonome. Cela minimise les dépendances et augmente l'efficience et l'efficacité du développement produit.

Discovery : Comment identifions-nous et validons-nous de nouvelles idées de produits et solutions qui répondent aux besoins de nos clients ?

Tout aussi important que des cycles de livraison rapides est le fait de résoudre d'abord les bons problèmes. C'est exactement ce dont traite le deuxième élément du Product Operating Model : Discovery.

L'objectif est de comprendre les besoins et les problèmes des utilisateurs par une interaction continue avec eux, et d'en déduire les bonnes solutions.

Mais comment se déroule concrètement ce processus de validation des problèmes et de recherche de solutions ? Sohrab explique qu'il existe différentes méthodes qui ont fait leurs preuves dans la pratique :

1. Entretiens clients : Par des conversations structurées avec les utilisateurs, leurs besoins, défis et points de douleur peuvent être identifiés. L'important est de ne pas poser des questions superficielles, mais de creuser plus profondément pour comprendre aussi les motivations sous-jacentes.
2. Observations : Souvent, les utilisateurs disent une chose mais font autre chose. C'est pourquoi il est important de les observer aussi dans leur environnement naturel. Comment utilisent-ils les solutions existantes ? Où ça coince dans le processus ? Quels contournements ont-ils développés ?
3. Analyse de données : L'analyse des données d'utilisation peut aussi fournir des informations précieuses. Où les utilisateurs abandonnent-ils ? Quelles fonctionnalités sont utilisées intensivement, lesquelles pas du tout ? Les patterns et anomalies dans les données donnent souvent des indices sur des besoins non satisfaits.
4. Prototypage : Au lieu d'investir beaucoup de temps dans le développement d'une solution parfaite, les entreprises qui réussissent misent sur le prototypage rapide. Cela leur permet de recueillir tôt dans le processus les retours de vrais utilisateurs et de valider ou invalider leurs hypothèses.

Un exemple de travail de Discovery excellent est le processus de développement du Kindle d'Amazon. Au lieu de simplement lancer une liseuse sur le marché, l'équipe Kindle s'est intensément penchée sur les besoins et frustrations des lecteurs. Par d'innombrables entretiens clients et observations, ils ont compris que les utilisateurs voulaient avant tout une expérience de lecture fluide, similaire au papier. De là sont nées des fonctionnalités comme l'écran E-Ink spécial, le rétroéclairage et l'intégration directe du Kindle Store.

Mais Discovery n'est pas un processus ponctuel, c'est une tâche continue. Comme le souligne Sohrab, les Product Managers des meilleures entreprises sont en échange presque quotidien avec les clients - que ce soit par des entretiens, des observations ou d'autres formats. Certaines entreprises mesurent même le nombre de contacts clients par semaine pour s'assurer que cette interaction a vraiment lieu. De plus : même quand on connaît les problèmes des utilisateurs, trouver les bonnes solutions est un art. Pour cela, il faut le courage d'essayer quelque chose de nouveau et d'être créatif.

Selon Sohrab, des entreprises comme Amazon, Apple ou Google repoussent constamment les limites du possible. Elles sont prêtes à cannibaliser leurs propres vaches à lait s'il s'agit d'offrir une nouvelle valeur aux clients. Un bon exemple est le remplacement de l'iPod par l'iPhone chez Apple. Pour cela, il faut une culture qui encourage l'expérimentation et la prise de risques.

Direction : Comment définissons-nous et communiquons-nous la direction stratégique et les priorités pour notre développement produit ?

Mais comment les équipes savent-elles dans quelle direction elles doivent évoluer ? C'est là qu'intervient le troisième composant du Product Operating Model : Direction.

Comme l'explique Sohrab, l'une des tâches les plus importantes des dirigeants est de donner la direction stratégique et d'établir le contexte global. C'est la seule façon de s'assurer que les différentes équipes et initiatives ne travaillent pas les unes à côté des autres, mais dans la même direction.

Mais comment exactement les dirigeants donnent-ils cette direction stratégique ? Sohrab mentionne différents formats et processus qui ont fait leurs preuves dans la pratique :

1. Vision et stratégie produit : Tout commence par le développement d'une vision produit claire et inspirante. Elle décrit où l'on veut aller et quelle valeur le produit doit apporter aux clients et à l'entreprise. De là découle une stratégie produit qui esquisse le chemin vers la réalisation de la vision.
2. Objectives and Key Results (OKRs) : De nombreuses entreprises utilisent les OKRs pour traduire la stratégie produit en objectifs concrets et mesurables. Des Objectives (objectifs) sont définis au niveau de l'entreprise et des équipes, rendus mesurables par des Key Results (résultats). Les OKRs servent de cadre d'orientation et garantissent que tout le monde travaille dans la même direction.
3. Roadmaps : Les roadmaps produit sont un instrument important pour communiquer la stratégie produit et coordonner les activités de développement. Contrairement à avant, les roadmaps ne sont plus aujourd'hui des plans rigides sur plusieurs années. Au lieu de cela, elles sont régulièrement ajustées et servent principalement à visualiser les prochaines étapes et priorités.
4. Réunions d'alignement régulières : Pour s'assurer que les équipes restent continuellement alignées sur les objectifs stratégiques, des réunions d'alignement régulières ont fait leurs preuves. Les dirigeants et les équipes produit s'y retrouvent pour échanger sur les progrès, les obstacles et les prochaines étapes.

Mais tout aussi important que de donner la direction stratégique est de décentraliser les décisions et de les déplacer là où le savoir et la proximité avec le client sont les plus grands. Car l'époque où la direction décidait dans sa tour d'ivoire ce que les clients veulent est révolue depuis longtemps. Au lieu de cela, les équipes doivent être habilitées à décider elles-mêmes comment atteindre au mieux les objectifs de l'entreprise.

Un exemple est le développement produit chez Amazon. L'entreprise travaille avec le concept de décisions Type 1 et Type 2. Les décisions Type 1 sont de grandes décisions stratégiques, difficilement réversibles et donc prises par la direction. Les décisions Type 2, en revanche, sont des décisions tactiques plus petites, facilement révisables et donc prises de manière décentralisée.

Mais la décentralisation des décisions suppose que les collaborateurs apportent le contexte nécessaire et les bonnes compétences. "La mise à l'échelle ne se fait pas par les processus, mais par les personnes", résume Sohrab. C'est pourquoi les dirigeants doivent avant tout faire une chose : habiliter les collaborateurs en leur donnant le contexte, en leur transmettant les compétences et en leur donnant le courage d'assumer des responsabilités.

Conclusion : Le Product Operating Model n'est pas un sprint, mais un marathon

L'implémentation d'un Product Operating Model est tout sauf triviale. Comme le montrent les études de cas dans le livre "TRANSFORMED" de Marty Cagan, il s'agit d'une transformation qui peut prendre des années. Car il ne s'agit pas seulement d'introduire quelques nouveaux rôles et processus. Cela nécessite plutôt un changement profond dans la culture, la mentalité et les compétences d'une organisation.

Mais l'effort en vaut la peine, car c'est la seule façon pour les entreprises de rester innovantes et centrées sur le client à long terme. Comme le souligne Sohrab, il n'y a pas d'alternative : "Qui ne se transforme pas sera disrupté." C'est pourquoi les entreprises devraient commencer maintenant à évoluer pas à pas vers un Product Operating Model.

La première étape est de créer une prise de conscience de la nécessité du changement. Mais ensuite, il s'agit de passer à l'action. Car comme pour le fitness, ce qui compte ici n'est pas le savoir, mais la mise en œuvre conséquente.

Si tu veux approfondir ce sujet, une keynote de 30 minutes ne peut offrir qu'un premier aperçu, n'hésite pas à contacter notre équipe. Nous sommes prêts à te fournir plus d'informations et un accompagnement sur ce sujet.