‍C’est quoi une organisation orientée produit ?

La mise en place d’une organisation produit est un processus clé dans la gestion efficace d’une entreprise qui souhaite créer de la valeur en continu pour ses clients finaux. Cela implique la structuration de produit, la planification et la coordination du développement d’un produit. Une organisation produit solide permet d'optimiser les processus, de minimiser les erreurs et d'atteindre les résultats attendus. Pour réussir l'organisation produit, il est essentiel de mettre en place des outils de suivi, des méthodologies adaptées et une communication claire entre les différentes parties prenantes. 

On parle de cette organisation pour les entreprises qui travaillent sur un produit tech/digital. De plus en plus d’entreprises cherchent à mettre en place une organisation produit. Les startup-scale up ont dès le départ adopté ces modes de travail tandis que certains grands groupes ou corporates sont en train de faire leur transition.

Au coeur de l’organisation produit, il y a plusieurs idées : 

• Mettre les utilisateurs (clients finaux)  au coeur de la stratégie 
• Donner aux équipes des objectifs clairs, orientés business 
• Travailler sur des cycles rapides avec des itérations
• Utiliser les méthodes agiles et travailler sur un modèle de “squad” 
• Communiquer au mieux entre les différentes parties prenantes pour éviter l’effet cycle en V. Cette organisation s’oppose à l’organisation orientée projet (cycle en V, “waterfall”). 

Le rôle de Product Manager est au cœur de cette organisation produit. Il/elle : 

• met en place les différentes méthodologies 
• s'assure que les équipes travaillent en cycle itératifs
• communique avec les parties prenantes 
• dirige la "squad" - équipe composée de dev, designer, data analyst- qui va développer les fonctionnalités de la roadmap. Attention : le ou la PM ne va pas être le manager des développeurs : les devs sont managés par le/la Lead dev ou CTO, le ou la PM est managé par le/la CPO ou Lead PM. 
• drive la stratégie et la roadmap produit

‍

Quels sont les objectifs d’une organisation produit ?

Dans un environnement incertain et évolutif, une organisation centrée produit aura plusieurs avantages comparée à une organisation projet :

• Itérations courtes et successives 
• Impact orienté business
• Priorisation des projets 
• Organisation bottom-up vs top down 
• Prises de décision factuelles 

‍

Rentrons dans le détail sur chacun des points précédents : 

• Itérations courtes et successives - l’organisation produit permet de confronter au plus vite les fonctionnalités aux utilisateurs, d’avoir du feedback plus rapidement et potentiellement une meilleure satisfaction client 

• Impact orienté business - les équipes travaillent généralement sur une “north star metric” et cherchent donc à impacter une métrique business

• Priorisation des projets - ce qui permet d’améliorer le ratio impact/effort

• Organisation bottom-up vs top down - rendant les équipes autonomes et efficaces. L’organisation matricielle de la squad permet également plus d’efficacité et de productivité

• Prises de décision factuelles - elles sont basées sur la recherche utilisateur et la data

‍

Comment mettre en place une organisation produit efficace?

Établir une stratégie produit claire

La stratégie produit découle de la vision produit, il est donc primordial de bien la définir. Pour cela, en tant que PM, il faut répondre à 4 questions : 

• Qui est notre utilisateur ? 

Impossible de s’adresser à tous les utilisateurs, il faut donc prioriser les utilisateurs visés en répondant à ces questions : quel est notre marché ? Comment segmenter les utilisateurs potentiels ? Quels utilisateurs de ce marché va-t-on viser ? Par exemple, si votre produit est un SaaS B2B, segmenter ses utilisateurs par tailles d’entreprises ou par cas d’usage peut être une première piste. S’il s’agit d’une marketplace dans la santé, les critères peuvent être les pays ou les types de praticiens (spécialité, généraliste, hôpital, cabinet…). 

• De quoi l’utilisateur a-t-il besoin ? 

Quels sont les problèmes que l’on souhaite résoudre pour nos utilisateurs ? Quel est le “job-to-be-done”, l’utilité du produit pour eux ? Quel bénéfice majeur notre utilisateur espère-t-il obtenir avec ce produit ? Pour répondre à cette question deux ateliers peuvent être utiles : 

- Un atelier ‘Product Solution Fit’

- Une story map qui va représenter l’expérience des utilisateurs tout au long du parcours, pour identifier les problèmes rencontrées

• Que fait notre produit ? 

Quelle est la catégorie de notre produit ? Par exemple, où se situe-t-il parmi les app mobiles, les plateformes, les marketplaces, etc …

• En quoi est-il unique ? 

Quels sont les éléments qui différencient notre produit du marché ? Pour cela il faut avoir une vision de la concurrence, on utilisera un benchmark. Il doit être structuré selon certains critères de différenciation entre les acteurs du marché. On se demande quels sont les bons axes pour segmenter les acteurs, puis sur lequel on souhaite axer sa différenciation sur son secteur. 

‍

La vision produit et la stratégie globale de l’entreprise doivent être liées - la vision produit ne peut pas être construite de manière indépendante :

• La mission globale de l’entreprise va généralement être définie pour une période de temps plus longue - il s’agit de la raison d’être de l’entreprise à très long terme. 
• La vision produit se décline sur 3-5 ans : l’objectif est donc de prioriser, et choisir quelle étape on veut atteindre en premier. C’est tout l’état d’esprit du Product Management : la priorisation. 

Élaborer une stratégie produit requiert de donner une vision à votre équipe. Cela contribuera à les aligner et à prioriser les décisions. Pour en savoir plus, lisez notre article sur la Vision Produit.

La vision produit établie, le/la PM et son équipe peuvent mettre en place une stratégie produit résultant d’un équilibre entre les objectifs business et la compréhension des besoins de vos (futurs) utilisateurs.

Parmi les outils et méthodes de recherche utilisés à l’élaboration de la stratégie, l’analyse de données et la user research seront vos alliés.

L’analyse de données

En tant que PM dans une organisation produit, vous vous servirez de la data dans 4 situations :

- au moment de la roadmap, pour prioriser entre des projets

- pour mieux comprendre les problèmes utilisateurs que vous voulez résoudre

- pour tester des solutions (AB test)

- pour mesurer le succès de vos fonctionnalités après lancement

Exemples : 

1. Si vous travaillez pour un ecommerce, et que votre objectif est d'améliorer le taux de conversion de la search au paiement, vous analyserez tout le funnel pour comprendre où vous "perdez" le plus d'utilisateurs. 
2. Si vous travaillez pour Doctolib et que votre objectif est d'améliorer la satisfaction des médecins, vous irez analyser les raisons de plainte au Service Client (% catégories, fréquence...)

La data  peut être récupérée de différentes manières et c’est souvent le/la PM qui devra s’en charger -sinon, c’est que vous avez un data analyst dans votre équipe et c’est super ! Si vous vous trouvez dans le premier cas, voici quelques outils indispensables :

1. Amplitude, MixPanel, Excel/Google Sheets
2. Extraire un set de données via le SQL
3. AB testing

‍

La User Research 

La User research permet de cerner les besoins des utilisateurs, leurs comportements et les freins qu’ils ont. Cette démarche permet de comprendre le problème qu’on essaie de résoudre et évite de construire des solutions basées sur des hypothèses. Dans une organisation orientée Produit, plusieurs stakeholders peuvent participer à la user research - PM, Product Designer ou encore User Researcher. Pour approfondir ce sujet, lisez notre article sur la user research⁽¹⁾.

Il n’existe pas une unique méthodologie pour analyser la donnée ou faire de la user research. Elle dépend du produit, cas d’usage ou du business model de votre entreprise. De plus, travailler par personae utilisateurs vous permettra de prioriser au mieux les problématiques de vos clients. 

Concernant la user research, voici les principales méthodologies et outils qu’on vous recommande : 

Tests et entretiens utilisateurs 

Outils : Google Doc, Confluence, Notion ou n’importe quel outil de prise de note, pour documenter vos entretiens et garder une trace des réactions des utilisateurs.

Sondages : Essayez de les rendre courts. Après avoir recueilli les réponses, segmentez vos réponses en catégories et creusez chaque catégorie en menant des entretiens utilisateurs (plus poussés qu’un sondage).

Outil : Typeform. Ils ont réussi l'impossible : Rendre le remplissage d’un survey agréable !

User journey Mapping : Pour vous permettre d'examiner de plus près toutes les étapes du parcours de l'utilisateur et essayer d'identifier les points de blocage, les frustrations ou les questionnements. 

Outil : Hotjar ou Fullstory. 

NPS : Pour poser à votre utilisateur une question standard à laquelle il donnera une note. Exemple :  "Quelle est la probabilité que vous recommandiez ce produit à un ami ou un collègue ?" . L’utilisateur donne une note entre 1 et 10. A la fin, cela vous donne une note globale sur l’état de satisfaction de vos utilisateurs. 

Outil : Satismeter

‍

Structurer et hiérarchiser les initiatives dans une organisation produit

Afin d’obtenir une idée précise des différentes phases du projet et des tâches qui y sont associées, le PM structure les besoins recueillis et analysés en amont. Pour ce faire, il utilise des frameworks de priorisation, notamment via la roadmap ou le backlog.

‍

La Product Roadmap

Issue de l’organisation produit, la product roadmap est un outil permettant de planifier les initiatives prioritaires sur le trimestre.

Pourquoi c’est important ?

Ce n’est pas un planning par semaine de votre trimestre mais un outil permettant d’aligner les équipes sur les priorités de l’entreprise et la bande passante de développement associée à chaque projet -ou EPIC.

Comment construire une roadmap produit ? 

• Récupérer les inputs (data, user feedback, feedback en interne)
• Filtrer les demandes qui ne sont pas alignées avec la vision de l’entreprise 
• Estimer l’impact des initiatives en se demandant bien quels objectifs/KPI on souhaite impacter 
• Estimer le temps de développement avec le Lead dev en vous aidant de la technique du T-shirt sizing 
• Prioriser les initiatives (on vous explique en dessous comment faire) 

Quels outils pour gérer votre Roadmap Produit ?

Il existe des outils classiques qui peuvent vous permettre de bien gérer votre organisation produit si celle-ci n’est pas très grande : Google Slides, Google spreadshit, Trello. Cependant, des outils exclusivement dédiés sont apparus sur le marché : Aha, Product Board et ProdPad.

‍

‍

Comment prioriser les fonctionnalités d'un produit : le RICE

La méthode RICE est une méthodologie de priorisation qui permet de prioriser entre des projets pour la roadmap, ou au sein d’un projet planifié pendant le trimestre. Concrètement, on va calculer un score (le RICE) pour chacun des projets potentiels, qui dépend de quatre facteurs :

• Reach : qui/combien d’utilisateurs impactés - on peut y mettre un ratio
• Impact : l’impact dépend des objectifs ou métriques de votre équipe. Quel sera l’impact sur les objectifs fixés ? On utilisera une échelle de 0.25 (minime) à 3 (énorme).
• Confidence : dans quelle mesure êtes-vous sûr des mesures que vous venez de faire ? On indiquera un pourcentage
• Effort : quelle quantité de temps cela représente pour toute votre équipe ?

‍

MoSCoW

On utilise ce modèle pour prioriser les user stories et les tâches déjà intégrées à la Roadmap.

Les lettres signifient : 

Must : ce sont les besoins non négociables pour le projet,

Should : ce qui est important mais pas vital à la réalisation du projet, 

Could : pas nécessaire au bon fonctionnement du produit, impact faible sur le produit et les objectifs

Won’t : ce qui n’apparaitra pas pour le moment dans le développement du produit 

‍

Le Product Backlog

Le Product Backlog est l'ensemble des tâches, tickets, fonctionnalités, prévues pour les prochains sprints de développement. Il est : 

• Un dérivé de la roadmap
• Une liste de toutes les fonctionnalités, tâches, ou bugs à planifier
• Géré par le/la PO mais aussi le/la PM

A la fin de chaque sprint, on organise un sprint review lors duquel on fait le point sur les tickets de dev qui ont été terminés, et ceux à replanifier pour le prochain sprint. 

Gérer les données de votre produit 

Il est nécessaire d’utiliser des outils de gestion des données pour organiser les informations, les spécifications et les documents liés à votre produit. 

Les spécifications ou specs, sont des documents qui contiennent toutes les informations dont un.e dev aura besoin pour coder une fonctionnalité. Une bonne spec doit contenir des informations pertinentes pour que le.la dev puisse comprendre de quoi il s’agit et ne soit pas un simple exécutant. 

Voici une liste d’éléments à prendre en compte pour la rédaction de vos specs : 

• Décrire quels sont les objectifs business, les metrics, les utilisateurs impactés et comment on mesure le succès de cette feature 
• Découper les specs en une liste de user stories afin de déployer rapidement et éviter des bugs
• Rédiger les ‘edge cases’ ou cas extrêmes, c’est-à-dire les cas qui font que votre utilisateurs pourrait mal utiliser votre produit et qui gâcherait son expérience. Par exemple : quel écran souhaite-t-on afficher lorsque l’utilisateur est hors ligne ?
• Etablir un plan de tracking pour clarifier ce qu’on veut tracker en priorité
• Rédiger des plans de test pour chaque feature et notamment celles qui sont critiques du point de vue business - vous pouvez vous demander “si cette fonctionnalité casse, est-ce que cela impacte la conversion de leads ?”

Vous pouvez rédiger vos specs sur différents supports tels que Confluence, Notion ou Google Doc. 

Il est crucial de mettre en place un système de suivi et de documentation liés à votre produit pour plusieurs raisons :

1. Faciliter la collaboration
2. Assurer une accessibilité et une traçabilité optimale
3. Prendre des décisions éclairées
4. Transmettre les connaissances

En organisant de manière efficace votre documentation vous améliorez l’efficacité opérationnelle et la réussite de vos projets.

‍

Savoir communiquer avec son équipe produit

Au sein d’une organisation produit idéale, vous êtes amené à collaborer en continu avec plusieurs parties prenantes de l’entreprise, ce qui implique de savoir communiquer efficacement, c’est-à-dire régulièrement, clairement et de façon impactante.

1. Communiquer en continu : Par exemple, en faisant des points hebdomadaires avec les parties prenantes clés, ou en communiquant par écrit sur Slack ou par mail
2. Comprendre les objectifs et métriques de vos collaborateurs : Il est important de connaître les METRICS de chacun pour leur communiquer des informations pertinentes. Par exemple, l’équipe support a pour métrique principale d’augmenter le NPS ou le CSAT
3. Rester humble et prendre en compte les commentaires des parties prenantes : Il ne faut pas penser à tort que vous savez tout. Bien que vos décisions se basent sur des faits, gardez en tête que tous les retours sont intéressants.
4. Construire une vraie relation avec les parties prenantes : Prenez le temps de discuter avec les parties prenantes et de leur poser des questions
5. Adapter son approche en fonction de son interlocuteur : Mettez vous à la place de votre collaborateur, connaissez-le, lui et son métier pour lui communiquer ce qu’il doit savoir (ex : pour l’équipe marketing ou avec le/la PMM - Product marketing manager, demandez-vous comment votre fonctionnalité impacte positivement l’image de marque)

‍

Pour assurer la gestion de produit projet, les PMs utilisent généralement des outils type “Kanban”. L’outil le plus répandu est JIRA, mais de plus en plus de PMs utilisent aussi Notion ou Trello. 

‍

Mesurer la performance de son produit

Il existe des indicateurs à suivre à chaque étape du cycle de vie du produit. Les Key performance Indicator (KPI) ou indicateurs de performance en français, sont des éléments chiffrés qui permettent de mesurer l’efficacité d’une action prise par une entreprise. Ils sont de précieux éléments qui orientent les décisions stratégiques. Ils sont également indispensables aux Product Managers et à leur équipe puisqu’ils permettent de mesurer le succès d’un produit. Attention toutefois à bien définir ses métriques et à ne pas en sélectionner trop.

‍

Il est capital de suivre deux types de metrics :

1. Les KPIs Business. Le framework AARRR peut ici être utile. Il reprend les métriques suivantes :

Acquisition : comment les utilisateurs vous trouvent-ils ? Le CAC (coût d’acquisition client) en est une métrique significative.

Activation : la décision de l’utilisateur d’utiliser le produit. Le taux de conversion en donne une bonne idée.

Rétention : la propension des utilisateurs à revenir vers le produit. Le churn est la métrique souvent utilisée pour mesurer la rétention.

Referral : la propension des utilisateurs à parler du produit autour d’eux. Vous pouvez ici tracker le nombre de referrals par utilisateur.

Revenu : combien de cash rentre. Le nombre d’euros engrangés est la métrique à suivre. 

2. Les métriques d’usage : à quel point les utilisateurs utilisent les fonctionnalités du produit. En effet, si une fonctionnalité n’est pas ou très peu utilisée, on peut se poser la question de la supprimer car elle nécessite de la maintenance pour rien. Par exemple, tracker la proportion d’utilisateurs qui utilisent certaines fonctionnalités au moins une fois par semaine (ou par jour) peut être une bonne piste (WAU “Weekly Active Users” ou DAU “Daily Active Users”).

Pour suivre la performance de leurs produits, les PMs utilisent des outils comme Amplitude, Mixpanel, ou Looker qui permettent de créer des tableaux de bord et rapports sur les KPI produit

Témoignages clients

Nina, Product Manager, partage son expérience

Nina a fait la promotion 3 de Noé. Après une école de commerce, elle a travaillé sur le développement commercial de start-up à l’étranger, notamment en tant que Business Analyst. Pour donner un nouveau souffle à sa carrière, elle s’est orientée vers le Produit. Nina a fait Noé puis a été embauchée en startup comme Product Manager. 

Elle témoigne sur sa reconversion : 

“Avant de commencer, je m’étais défini mes propres objectifs par paliers pour monter en compétence. Avec mon manager, on a fixé des objectifs, notamment sur la delivery qui est le b-a-ba du PM. Il y a un volet data important chez nous car nous n’avons pas data analysts. La discovery et la communication faisaient également partie de mes goals.

L’objectif le plus intéressant pour moi était celui sur la discovery. J’ai dû préparer la stratégie à l’échelle d’un trimestre. C’est un beau challenge car il demande une bonne connaissance du Produit, de bien prioriser et collaborer avec la tech ainsi qu’aligner tout le monde sur la stratégie.

Sur la partie Data, l’enjeu est de bien tracker l’impact des features qu’on met en production. Pour l’application Color Pop sur laquelle je travaille, il y avait beaucoup d’analyses à faire sur mes thématiques alors qu’il n’y avait pas de data analysts. C’est un bon objectif personnel car ça me permet de monter en compétences sur ces sujets.

Le conseil que je donnerais à un ou une Product Manager qui débute : Savoir pourquoi ! En tant que PM, il faut poser des questions, notamment "pourquoi". On se rend compte que les équipes peuvent vite l'oublier, alors que c’est clé dans notre métier. Étant responsable de certaines décisions, il faut bien garder en tête la raison pour laquelle nous prenons telle décision.” 

‍

Thomas, PM chez Qonto partage son expérience 

Thomas est diplômé d’HEC et du MIT. Il a commencé sa carrière dans les banques d’investissements puis a choisi de travailler dans la tech. Il est devenu Product Manager chez Qonto à la suite de sa formation chez Noé. Thomas témoigne sur l’organisation produit de son entreprise inspirée du lean à la Toyota : 

“Qonto a une culture et une organisation produit particulière, inspirées du lean à la Toyota. Néanmoins, je retiens deux grandes leçons de mon passage chez Noé, que je garde en tête chaque fois que je débute un nouveau projet.

La première, c’est revenir aux sources : pourquoi décide-t-on de travailler sur ce problème maintenant ? Quels sont nos objectifs et comment va-t-on les mesurer ? C’est quelque chose qui était extrêmement clair chez Noé.

La seconde, c’est la grande importance de la Discovery. On peut avoir beaucoup de ressources à disposition mais on ne peut pas se passer de revenir aux utilisateurs. Sans entretiens utilisateurs bien préparés, un Product Manager n’a que des opinions et risque de “shipper des features”. C’est aussi quelque chose de très bien fait chez Noé, grâce à l’application du problème sponsor sur lequel j’avais travaillé avec Stuart.”

‍

‍

FAQ

Quelles différences entre organisation mode projet mode produit ?

L’organisation mode produit se concentre sur le développement, la maintenance et l'amélioration continue d'un produit spécifique, avec des équipes et des responsabilités dédiées à ce produit sur le long terme. L’organisation mode projet, quant à elle, est temporaire et vise à réaliser un objectif spécifique en regroupant des ressources et des compétences pour mener à bien un projet avec un début et une fin clairement définie.

‍

Quel est le rôle du Product Owner dans une organisation produit ?

Le rôle du Product Owner est de collaborer avec les développeurs pour délivrer les features d’un produit. En s’appuyant sur la méthodologie agile, et notamment le framework scrum, les PO gèrent le backlog produit, rédigent les User Stories, font les tests.

‍

Dans quelle typologie d’entreprise la culture produit est-elle la plus forte ?

Généralement, les start up ont plus une culture orientée produit, ce qui tend à changer car les grandes entreprises s’inspirent des méthodes de travail dites agiles.

‍

CPO, CTO: quelles différences ?

Le ou la CPO est en charge de l'équipe Produit : il/elle va 

- définir la stratégie produit, 

- manager l'équipe de Product Managers, 

- s'assurer de la bonne exécution de la roadmap

Le ou la CTO dirige l'équipe technique. Son rôle est notamment de définir la vision technique pour le produit : quels langages / frameworks utiliser ? Quelle infrastructure adopter ? Il/elle va également manager les développeurs, et s'assurer de la vélocité des équipes Tech.

‍

Le Product Marketing Manager fait-il partie de l’équipe Produit ?

Cela dépend des entreprises. Le rôle de PMM peut-être rattaché aux équipes Produit ou Marketing.

‍

Conclusion 

Finalement, peu importe les méthodes d’organisation et les outils que vous utilisez, le tout est de les connaître et de savoir les adapter à votre organisation produit. Tout d’abord, il convient d’établir une stratégie claire qui passe par l’identification des besoins clients en croisant les méthodes de recherche et d’analyse de la data. Puis, le/la PM doit structurer et hiérarchiser ses initiatives dans une Roadmap Produit en s’aidant par exemple de la méthode de priorisation RICE. Ensuite, il est crucial de bien documenter les insight et toute documentation liée au produit afin d’améliorer l’efficacité opérationnelle des équipes. De plus, un.e PM, au sein de son organisation doit savoir communiquer et instaurer des rituels destinés à aligner les parties prenantes. Enfin, une bonne organisation produit sait comment mesurer le succès de son produit en se basant sur des KPI.

‍

^{(1) https://www.noe.pm/post/organisation-produit-pour-product-manager-methodes-strategies-et-outils-pour-une-gestion-efficace}