Maxime Nahon Les Organisations Innovantes Orientees Produit

Maxime Nahon
LES ORGANISATIONS
INNOVANTES
ORIENTÉES PRODUIT
Comment les organisations mettent l'utilisateur au cœur
de leur développement produit
MBA Marketing Digital et Commerce sur Internet
Code NSF 312 - 326, certification professionnelle de niveau I

(Fr) et de niveau 7 (Eu) enregistrée au RNCP par arrêté du
7/07/2017 publié au JO le 19/07/2017.
Promotion 2019- 2020
Thèse Professionnelle de :
Maxime Nahon
Les organisations innovantes

orientées produit
Comment les organisations mettent l’utilisateur au coeur de leur
développement produit
Date de remise : 09 octobre 2020
INSTITUT LÉONARD DE VINCI

12 avenue Léonard de Vinci
92 400 Courbevoie
/
Les organisations innovantes orientées produit Maxime Nahon
Introduction
L’auteur
Je suis Maxime Nahon, je suis product manager et j’ai suivi le MBA
MCI, formation en marketing digital à l’Institut Léonard de Vinci
(ILV) en 2019-2020.
Le présent document est la thèse (légèrement remaniée) que j’ai

soutenue dans le cadre de cette formation, après de longs mois à
me documenter sur le product management en France.
N’hésitez pas à me contacter sur les réseaux sociaux ou par e-mail :
@maximenahon
/in/maximenahon
maxime.nahon@gmail.com
maximenahon.com
Cette thèse est distribuée sous licence CC BY-NC 4.0
1
Thèse #MBAMCI - octobre 2020
/
Introduction
Sommaire
Introduction 11
Partie I - Qu’est-ce que le product management ? 17
1 - Pourquoi le Product Management ? 18
1.1 - Ce qui ne fonctionne pas dans le modèle traditionnel 18
1.2 - Le product management moderne : un modèle centré sur la production de

valeur business et client 21
2 - Une histoire du product management 25
2.1 - Naissance de la stratégie de marque… et du product management 25
2.2 - Divisions produit chez HP, optimisation de la production chez Toyota 25
2.3 - Le chef de produit marketing dans les années 60 25
2.4 - L’approche produit centrée utilisateur dans la tech 26
2.5 - Le produit au coeur des méthodes agiles 26
2.6 - L’avènement des directions produit 27
3 - L’équipe produit 28
3.1 - Quelle taille idéale pour une équipe produit ? 29
3.2 - Les caractéristiques d’une équipe produit qui réussit 29
Partie II - Les rôles au sein d’une organisation produit 34
1 - Le Product manager, leader du produit 35
1.1 - Les compétences du PM au travers du framework CORE 36
1.2 - Lead product manager 39
1.3 - Associate product manager 39
1.4 - Product Manager et Product Owner 40
1.5 - PM et chef de projet 43
2 - Le product design, leader de l’expérience utilisateurs 45
2.1 - Product designer 47
2.2 - Les autres rôles du design 48
2
/
Introduction
2.3 - Une organisation sans design ? 50
3 - L’équipe de réalisation, de l’idée à la réalité 52
3.1 - Les développeurs 53
3.2 - Tech Lead 54
3.3 - Quality Assurance (QA) 54
4 - Les experts et fonctions transverses 56
4.1 - Product researcher 56
4.2 - ProductOps 56
4.3 - Product Data Analyst 58
4.4 - Product Growth 59
5 - Le management produit 60
5.1 - Head of product 60
5.2 - Chief Product Officer 61
5.3 - Head of Design, leader de l’équipe design 62
5.4 - Le leadership technique 63
6 - Le marketing dans une organisation produit 65
6.1 - Product marketing manager 65
6.2 - L’intégration du marketing aux squads 74
Partie III - La stratégie produit 76
1 - La vision produit 78
1.1 - Construire sa vision produit 79
1.2 - L’énoncé de mission 83
2 - Les objectifs stratégiques 85
2.1 - Les OKR - Objectives and Key Results 86
3 - La roadmap produit 90
3.1 - Pourquoi les roadmaps traditionnelles ne fonctionnent pas ? 90
3.2 - Une roadmap orientée outcomes 91
3.3 - Trouver les idées, définir les initiatives 96
3.4 - Prioriser les initiatives 104
3.5 - Prendre compte les imprévus 110
3
/
Introduction
4 - Le cycle de vie du produit 112
4.1 - La recherche du bon problème à résoudre : le problem/solution fit 112
4.2 - La recherche du Product/Market fit 114
4.3 - La phase de croissance : le growth 118
4.4 - La maturité du produit 121
Partie IV - Product Discovery : identifier quel produit développer 122
1 - Le cadre conceptuel du discovery : Design Thinking et Lean 125
1.1 - Une approche Design Thinking 125
1.2 - Lean Startup 128
2 - Product Research : comprendre les problèmes des utilisateurs 137
2.1 - Connaître les utilisateurs 137
2.2 - Synthétiser la recherche utilisateur 140
3 - Trouver la bonne solution 143
3.1 - L’idéation : formuler des hypothèses sur la solution au problème de vos

utilisateurs 143
3.2 - Créer des prototypes pour tester vos idées 144
3.3 - Valider les hypothèses 146
3.4 - Le Design Sprint : trouver une idée et valider un prototype en 5 jours 148
3.5 - Regrouper et affiner les résultats 157
Partie V - Le Delivery : développement et déploiement du produit 159
1 - Prioriser le backlog 161
1.1 - Qu’est-ce qu’un backlog ? 161
1.2 - Quels outils pour prioriser le backlog ? 165
2 - L’agilité et les frameworks agiles 172
2.1 - Agilité et product management 173
2.2 - Zoom sur Scrum 174
2.3 - Kanban, ou le développement produit par le flux 178
2.4 - Et les autres… 182
3 - Mettre le produit en production 185
3.1 - La culture DevOps 185
4
/
Introduction
3.2 - Déployer les nouvelles versions en continu 187
Partie VI - Le produit à l’échelle 193
1 - Comment découper le produit entre différentes équipes 194
1.1 - L’organisation en component team 195
1.2 - L’organisation en feature teams 197
1.3 - L’organisation en impact teams 199
1.4 - L’organisation en persona teams 201
1.5 - La place des équipes transverses 202
2 - Les interactions entre équipes 204
2.1 - Le “modèle” Spotify 204
2.2 - Organiser la collaboration entre les équipes : Team Topologies 208
Partie VII - Mettre en place le Produit dans votre organisation 211
1 - Comment convaincre le top management ? 212
1.1 - Identifiez un projet pilote 213
1.2 - Passez à l’intrapreneuriat 216
1.3 - Et le product management au sein d’une startup ? 218
2 - Mettez en place une organisation produit 219
2.1 - Un changement culturel 219
2.2 - Un changement organisationnel : cassez les silos 222
2.3 - Un changement humain : des équipes avec les bonnes personnes 225
2.4 - Une nécessaire refonte technologique 230
2.5 - Une redéfinition des processus 230
2.6 - Communiquez sur votre démarche 234
2.7 - Comment travailler avec des partenaires et des agences ? 235
En guise de conclusion … 240
5
/
Introduction
Annexes - Bibliographie et interviews 241
1 - Livres 242
2 - Ressources générales sur le product management 244
3 - Ressources web sur le product design et le discovery 250
4 - Ressources web sur l’entrepreneuriat et les startups 253
5 - Ressources sur l’agilité et delivery 255
6 - Interviews 257
6
/
Introduction
Introduction
Le product management est une discipline relativement récente en France, mais déjà
ancienne aux USA même dans sa forme moderne. En 1997, Ben Horowitz, alors VP chez
Netscape, écrit un article sur le rôle du Product Manager en tant que CEO de son
produit1. Marty Cagan, qui était également VP chez Netscape en même temps que
Horowitz, publie en 2008 Inspired, depuis considéré comme beaucoup comme la bible
du product management.
En France, en 2013, l’association “We Do Product Management” (WDPM) est créée2 par
Sébastien Sacard, un ancien de Yahoo!, et quelques partenaires afin d’organiser des
meet-ups événements autour du produit et diffuser les bonnes pratiques,
essentiellement autour des startups françaises de l’époque (Viadeo, Blablacar, Leetchi,
Deezer, Molotov…). Un an plus tard, une première agence de conseil spécialisée en
product management est créée, Thiga, qui lance son blog et un premier livre blanc.
Depuis la communauté a grandi, la plupart des startups et scale-ups tech qui ont du
succès ont mis en place une organisation produit. Les entreprises réalisent que
l’innovation et la transformation digitale doivent maintenant mettre le client au cœur de
leurs préoccupations, et de plus en plus d’entre elles mettent en place une direction
produit, avec plus ou moins de succès.
Mais qu’est-ce qu’un produit ? En product management, il est défini comme étant le
moyen par lequel une organisation crée de valeur pour le client ou l’utilisateur. Un
produit délivre de la valeur au client de façon continue et répétée, sans que
l’organisation qui crée le produit n’ait à construire quelque chose de nouveau à chaque
fois. Les théories du product management concernent en premier lieu des produits
incluant une composante tech forte : un objet tangible, hardware, comme un
smartphone, un drone ou une station météo connectée, un produit virtuel, software,
comme Microsoft Word, Candy Crush, ContentSquare ou Slack, ou encore un service
“productisé”, comme Veepee, Deliveroo, Blablacar, Alan, Doctolib, OVH, Deezer ou
OuiSNCF, les services e-commerce de Carrefour, les services en ligne du Crédit Agricole
ou le service en-ligne des impôts.
1
HOROWITZ, Ben. Good Product Manager/Bad Product Manager. Andreessen Horowitz.
https://a16z.com/2012/06/15/good-product-managerbad-product-manager/
2
SACARD, Sébastien. L'avénement du Product Management en France. LinkedIn : 9 avril 2015.
https://www.linkedin.com/pulse/bye-wdpm-s%C3%A9bastien-sacard/
7
/
Introduction
Une organisation produit est une entreprise, une association ou une administration, qui
organise tout ou partie de son activité autour de la création de produits numériques en
mettant le client au cœur des préoccupations. Une organisation produit définit une
vision à long terme pour ses produits et une stratégie pour atteindre cette vision, et
priorise les initiatives les plus efficaces pour atteindre ces objectifs en délivrant cette
valeur client. La plupart de ces organisations ont mis en place une direction produit à
part entière, généralement dirigée par un CPO ou un VP Product.
Le product management est une discipline importée des USA par les startups
françaises. Le terme “product management” ne se traduit pas par “gestion produit”. Le
product manager n’est que très rarement appelé responsable produit. Le jargon propre
au product management est très largement anglais, et j’utiliserai donc de nombreux
termes anglais difficilement traduisibles en français pour représenter le même concept.
J’essaierai d’expliquer tout au long de cette thèse ces anglicismes.
Alors, pourquoi une thèse sur le product management ? Je vais vous raconter mon
expérience, vous pouvez passer cette partie si elle ne vous intéresse pas !
Depuis 10 ans je travaille sur des applications de communication et de marketing au

sein du département IT d’un grand groupe français. Je suis arrivé au milieu d’un projet
de refonte d’une plateforme de sites web. Le projet était mené en cycle en V
traditionnel, et le prestataire venait de livrer une première version du produit, après de
longs mois de rédaction de spécifications détaillées et de développement. Cette version
était largement dysfonctionnelle, pleine de bugs, de fonctions manquantes ou non
conformes aux spécifications. S’en sont suivis plusieurs mois intenses de tests, de
livraisons multiples, de crises avec le business et de pressions intenses du management
sur la cheffe de projet pour finalement délivrer avec plusieurs mois de retard sur le
planning prévu initialement (et défini arbitrairement) un produit conforme aux
spécifications. Bilan de l’opération : un business était mécontent du livrable et du retard
pris dans sa livraison, un prestataire qui livre un projet au forfait déficitaire et une
cheffe de projet à la limite du burn-out. Après le lancement, les équipes se sont
efforcées de corriger un maximum de bug pour être conforme aux spécifications, peu
importe la pertinence des efforts déployés au regard du bénéfice rapporté.
Quelques années plus tard, le management nous a imposé une migration technique du
projet vers une nouvelle version majeure du logiciel utilisé pour notre plateforme avec
un nouveau prestataire. L’objectif était de migrer iso-fonctionnalités, simplement en
adaptant certaines d’entre elles aux évolutions du logiciel. La faute à de nombreux
développements spécifiques lors du projet initial, la migration a duré 9 mois, et a
nécessité un budget démentiel pour une valeur business proche du néant. Le
management IT était probablement content de pouvoir cocher la case “version logicielle
à jour”.
Un peu plus tard, nous avons expérimenté une première approche agile de la gestion
de projet, avec un périmètre fonctionnel peu détaillé au départ et la possibilité de
changer d’options, tant que la charge de travail pour les développeurs était la même.
Projet, business et développeurs avons travaillé main dans la main pendant plusieurs
8
/
Introduction
mois, pour au final livrer une nouvelle fonctionnalité assez éloignée, et améliorée de
notre point de vue, par rapport à ce qui était prévu au départ. Nous étions contents de
ce succès. Sauf qu’après quelques mois, nous avons dû constater que la fonctionnalité
avait été utilisée par moins d’une dizaine de personnes…
Encore quelques années, et à nouveau projet de refonte de nos sites web, parce que les
performances techniques du système en place sont déplorables et que nous sommes
incapables de les résoudre : nouveau prestataire, nouvelles interfaces, toujours le
même business et les mêmes “besoins”. J’ai obtenu de réaliser ce projet en utilisant la
“méthode agile”, en l'occurrence Scrum, pratiquement une première dans notre
organisation. Au départ tout allait bien : user stories créées et estimées en impliquant le
business, développement en sprints… et puis catastrophe : la qualité des
développements n’est pas là, l’équipe prend du retard par rapport à un planning très
serré validé en début de projet… Au final, le projet met 15 mois à être livré au lieu de 6,
et le budget est multiplié par trois (on parle de budget à 7 chiffres). Au cours du projet,
je suis nommé product owner, mais j’ai l’impression de ne rien “owner” du tout.
J’exécute le même périmètre fonctionnel que 7 ans auparavant, avec des interfaces et
des options différentes sur lesquelles j’ai la main, mais toujours avec l’impression
d’avancer à l’aveugle.
Année suivante, nouveau projet : une agence UX pilotée par le marketing est engagée
pour refondre l’expérience client sur une partie vue comme critique de nos sites web.
Après un benchmark concurrentiel et quelques interviews de stakeholders en interne,
l’agence propose un nouveau design pour cette section, discuté, amendé et validé par
ces mêmes stakeholders. Charge à l’équipe projet, donc l’agence de développement et
moi-même, de mettre en place cette nouvelle expérience. Problème, une bonne partie
de cette expérience nécessite de diffuser en ligne des données internes indisponibles.
Les systèmes data étant très peu flexibles, impossible de les obtenir rapidement. Nous
créons donc un “MVP”, en fait un produit final débarrassé de tout ce qui était impossible
techniquement, déconnecté de l’expérience proposée initialement, et des besoins
utilisateurs que personne ne connaît. Nouveau projet en scrum, avec un périmètre
défini dès le départ. Lors d’un atelier de deux jours, les développeurs fournissent une
estimation de la charge de travail et du temps nécessaire pour livrer le projet sur la
base de maquettes InVision non finalisées et de user stories tenant sur un post-it.
Estimation qui devient dans l’esprit des dirigeants une date ferme sur une roadmap.
Bien sûr, en précisant les user stories et en finalisant les design, l’estimation est
devenue incorrecte, et des conflits ont rapidement éclaté entre le business, le
management IT et le prestataire. Les développeurs ont dû travailler soir et weekend
pour parvenir à livrer dans les temps une roadmap renégociée… pour qu’au final le
business décide qu’il fallait améliorer certaines fonctionnalités, et que le livrable ne soit
finalement mis en production que 5 mois plus tard.
Je passe rapidement sur le projet de créer un espace dédié pour certains clients grands
comptes, fonctionnalité dont l’expérience a été totalement remaniée après la livraison
du projet, pour ne finalement jamais être utilisée. Le projet a depuis été reconduit sur
une autre plateforme.
9
/
Introduction
Pendant toutes ces années, plusieurs facteurs communs ont été responsables, selon
moi, de ce que je considère comme des échecs d’un point de vue résultat pour
l’entreprise. J’ai personnellement toujours reçu de très bons feedbacks de mon
management, considérant mon travail comme un succès chaque année, mais je ne
peux m’empêcher de penser que mon travail ne servait pas à grand-chose.
D’abord une pression constante du management et du business sur les délais. A chaque
début de projet il fallait estimer assez précisément quand les livrables attendus allaient
pouvoir être mis en production, et à pratiquement à chaque fois ces délais n’étaient pas
tenus. Pourtant, il n’y a jamais eu de contraintes externes justifiant ces dates : pas
d'événement extérieur pour lequel le projet devait être livré, pas de contrainte
réglementaire, pas d’opportunité business particulière…
Ensuite, une bureaucratie et des processus lourds pour que le management contrôle le
respect du budget et la qualité technique des livrables. Par exemple, chaque été nous
devions saisir des prévisions budgétaires précises dans un outil inepte de gestion de
projet, afin que le management ait une vision d’ensemble de la consommation du
budget et puisse procéder à des arbitrages et des réallocations. Ces prévisions sont le
plus souvent faites au “doigt mouillé”, et les équipes se retrouvent généralement en fin
d’année à dépenser inutilement du budget prévu en trop, ou à “bidouiller” entre les
projets pour affecter des dépenses d’un projet sur la ligne budgétaire d’un autre. Ou
des bugs urgents corrigés en quelques heures mais livrés en production après plusieurs
jours parce qu’un comité doit valider toutes les mises en production à l’avance.
Enfin et surtout, l’absence totale d’objectifs business dans tous ces projets. Les projets
ont toujours été “refondre la plateforme de sites web”, “faire une migration technique”,
“lancer un extranet”, “améliorer l’expérience client des fiches produit”, et toujours
justifiés par des problèmes internes (la solution précédente est trop coûteuse, pas
maintenable, son UX est vieillissante). Jamais “augmenter le nombre de leads générés
par nos canaux digitaux” ou ‘augmenter la notoriété de notre marque sur telle cible”. Et
encore moins des KPI permettant de mesurer le succès de ces objectifs business. Après
10 ans passés à travailler sur nos sites web, je n’ai toujours pas vraiment compris quelle
est leur raison d’être pour l’entreprise, ou en tout cas je suis sûr que ce que je
comprends n’est pas aligné avec ce que pensent les différentes parties-prenantes. Pas
une seule fois non plus de vrais clients ont été consultés pour vraiment déterminer
quelles étaient leurs attentes vis-à-vis de notre produit. Au mieux, des parties-prenantes
en contact avec le business ont été consultées pour exprimer ce qu’elles pensent que
les clients veulent. Je n’ai jamais eu l’opportunité de rencontrer un client.
Au hasard de mes recherches sur mon nouveau métier de product owner, j’ai eu
l’opportunité d’assister à la Product Conf de 20183. Cette expérience a été une
révélation. J’ai été passionné par l’explication de Christopher Parola sur le pilotage par
l’impact de MeilleursAgents, celle de Léa Mendes sur l’expérience produit chez Everoad,
l’intervention de Yaroslav Stepanenko sur les métriques north star et l’utilisation du
framework AARRR ou encore la création d’un playbook produit chez Blablacar. J’ai
compris comment les entreprises innovantes faisaient pour délivrer et créer des
3
La Product Conf - LPC & LPCx. La Product Conf Paris 2018. Youtube : 2 juin 2018.
https://www.youtube.com/playlist?list=PLBaIQg089w72LX0O5jJ-r8OeEHR6ZIvHR
10
/
Introduction
produits efficaces, créant une valeur certaine pour le business et pour leurs clients, avec
des budgets souvent bien moins importants que ceux que mon entreprise pouvaient
engager.
Si vous êtes déjà un expert du produit, vous n’apprendrez probablement pas

grand-chose de cette thèse. Elle s’adresse avant tout à toute personne intéressée par le
product management et les organisations produit, que ce soit en startup ou dans un
grand groupe. Je l’ai conçue au fur et à mesure de mon apprentissage et de mes
discussions, très riches, tout au long de cette année 2020. Si vous ne connaissez que
peu le sujet et que vous souhaitez en savoir plus sur les processus, les rôles, le delivery
et le discovery, j’espère que vous trouverez des informations et des recommandations
utiles.
11
/
Introduction
Résumé
Le product management est une fonction omniprésente dans les organisations aux
USA, mais encore récente en France. C’est une discipline à l’intersection entre le
business, le design et la tech, qui met l’utilisateur au centre du développement de
produits digitaux. Une organisation produit met la création de valeur pour le client et
pour le business au cœur des préoccupations, les outcomes, à l’inverse des processus
traditionnels qui visent à délivrer des logiciels et des fonctionnalités, les outputs. La
démarche produit vise à atténuer quatre types de risque le plus tôt possible dans le
processus de développement du produit :
● Risque de valeur : le produit crée-t-il de la valeur pour le client ?

● Risque d’utilisabilité : le client comprend-il comment utiliser le produit ?
● Risque de faisabilité : l’équipe est-elle capable de réaliser le produit avec les
ressources dont elle dispose ?
● Risque de viabilité business : le produit génère-t-il de la valeur pour le business
en accord avec son business model ?
Les organisations produit sont basées sur la création d’équipes autonomes et

pluridisciplinaires réunissant entre autres un product manager, un product designer,
des développeurs et des testeurs. Ces équipes sont responsables d’un produit à part
entière ou d’une partie cohérente du produit, incluant à la fois les interfaces frontend et
les systèmes backends sous-jacents. Le département produit est généralement dirigé
par des Heads of Product et un Chief Product Officer.
Dans ce type d’organisation, le management exécutif définit la vision produit à long

terme et les objectifs stratégiques pour atteindre cette vision produit, par exemple sous
la forme d’OKR. Le rôle du product manager est de trouver le meilleur chemin pour
atteindre ces objectifs.
Le développement d’un produit digital peut être divisé en deux phases : le discovery et le
delivery. Ces deux phases sont en réalité entremêlées et itératives.
Le discovery est une démarche inspirée des démarches Design Thinking et Lean Startup.
Pendant le discovery, le product manager et son équipe cherchent à connaître
l’utilisateur et à identifier ses problèmes. Ils trouvent des idées pour résoudre ces
problèmes et formulent des hypothèses qu’ils testent auprès des utilisateurs grâce à la
création de prototypes, pour recueillir de la connaissance client et trouver des solutions
qui fonctionnent avant de commencer des développements lourds et coûteux.
Une fois les hypothèses validées, la phase de création du produit proprement dite
commence : le delivery. Le product manager travaille à la réalisation du produit avec son
équipe de développement grâce à des pratiques agiles. Le produit est livré au client
grâce à une démarche DevOps de déploiement continu.
Le product management est une des clés du succès des startups qui délivrent de la
valeur grâce à des produits digitaux, et une étape obligatoire pour toutes les
12
/
Introduction
entreprises traditionnelles qui ont compris que l’innovation et la transformation digitale

passe par une démarche centrée sur leurs clients.
Vidéo de présentation de ma thèse professionnelle

https://www.youtube.com/watch?v=UAvZ31KMhrs
13
/
Introduction
Summary
Product management department is present in almost every large organization in the
USA, but still pretty recent in France. This function is the intersection between Business,
Design and Tech and puts the user at the centre of digital product development
processes. Unlike traditional companies who focus on delivering outputs, software and
features, product management organizations focus on delivery outcomes, business and
customer value. Product management aims at mitigating four types of risk as early as
possible in the product development process:
● Value risk: will the product create value for our customer?
● Usability risk: will the client understand the product?
● Feasibility risk: will the team be able to develop the product with available
resources?
● Business viability risk: will the product create some business value in line with
the organization’s business model?
Product organizations are based on autonomous and cross-skilled teams, gathering

among others a product manager, a product designer, software engineers and QA
engineers. These teams are responsible for delivering value on an entire product or a
consistent part of the product, including frontend and backend systems. Product
department is usually led by Heads of Product and a Chief Product Officer.
In this kind of organization, executive management defines the long-term product vision
as well as strategic objectives to reach the vision, using OKRs for instance. Product
manager’s duty is to find the best way to achieve those objectives.
The development of a product can be split in two phases: discovery and delivery. Both
phases are actually intertwined and iteratives.
Discovery is based on Design Thinking and Lean Startup mindsets. During the discovery
phase, the product manager and their team learn about users and their problems. They
make assumptions on what could create value for the customer, and test those
assumptions using prototypes, in order to gather validated learnings. The aim is to find
solutions that work before starting heaving and costly software developments.
Once assumptions have been validated starts the delivery phase. The product manager
works with the engineers to create the actual product with agile software development
practices. The product is eventually delivered to clients using DevOps and continuous
deployment approaches.
Product Management is a key success factor for innovative startups that deliver value
using digital products. It is also a mandatory step for corporate companies that realize
innovation and digital transformation must be customer-centric.
14
/
Introduction
Remerciements
Merci à Alexandre Jubien, pour son cours inspirant, ses conseils et toutes les
suggestions de personnes product-oriented à contacter dans le cadre de ma thèse.
Merci à Alix Boulnois Lombard, Alexia Boulot, Marion Darnet, Silvère Duval, Kathleen
Marie-Joseph, Clarisse Moussie, Matthieu Pecheul, Marie Petit, Gabriel Soares,
Alexandre Takacs et Aurélie Vallée pour le temps qu’ils ont bien voulu m’accorder, pour
ces partages qui n’ont ouvert de nouvelles perspectives pour rédiger ma thèse.
A l’équipe pédagogique du MBA MCI, en particulier Alexandre Stopnicki et Christophe

Dané, merci pour cette année très riche, et le challenge que représente cette thèse.
Un énorme merci à la promo #MBAMCI part time 2020. Vous me manquez les cousins !
Vivement que nous fêtions ça.
Un gros merci à Alban Jarry, qui m’a motivé et donné les moyens de suivre cette année
de cours au MBAMCI, et qui a accepté que je m’échappe une semaine par mois du
bureau ! J’espère que ton prochain challenge professionnel sera à la hauteur de tes
ambitions.
Plein de bisous à ma petite Juliette, qui chaque jour me donne le sourire.
Enfin et surtout, un énorme merci à Sabine, pour m’avoir supporté pendant ces 12 mois
(et surtout ces dernières semaines !), pour m’avoir aidé, relu, corrigé, soutenu,
encouragé, dégagé du temps, permis de souffler et donné du bonheur. Je t’aime !
15
/
Introduction
Recommandations synthétisées
16
/
Les organisations product dans la transformation des entreprises Maxime Nahon
I - Qu’est-ce que le product management ?
Partie I
Qu’est-ce que le
product
management ?
Quels sont les principes de cette discipline ? Qu’est-ce qu’elle change par rapport à la
façon traditionnelle de gérer des projets logiciels ? D’où vient-elle ?
17
/
1 - Pourquoi le Product
Management ?
1.1 - Ce qui ne fonctionne pas dans le modèle traditionnel
Lorsque les entreprises veulent développer ou faire évoluer un produit, qu’il soit
externe ou interne, elles suivent toutes plus ou moins le même modèle, que Marty
Cagan4 schématise ainsi :
Les causes profondes de l'échec du développement produit
1. Le management exécutif ou les départements business ont une idée. Cette idée
peut venir de leur propre inventivité, d’études de marché, d’une demande de
client spécifique, de la préconisation d’un cabinet de conseil… Il s’agit
généralement de la création ou de la modification d’un produit ou d’un process
de l’entreprise, par exemple “mise en place d’un CRM”, “refonte du site web”,
“ajout de la fonctionnalité X au produit”, “automatisation du process Y”...
2. Ils matérialisent cette idée sous forme d’un business case, en déterminant son
coût de mise en place estimé, et les bénéfices (financiers ou autres) attendus. Ce
business case permet de définir une valeur business.
3. Ils planifient ensuite cette idée sous forme de projet dans une roadmap,
priorisée dans le temps en fonction de la valeur business. Dans beaucoup
d’organisations, il s’agit d’un cycle annuel : en fin d’année, le management choisit
les idées qui seront mises en place l’année suivante.
4. Lorsque la date de démarrage du projet arrive, les équipes produit (souvent au
sein de la DSI) s’emparent du sujet. Le product manager (souvent appelé chef de
projet) mène quelques études préalables et définit les spécifications
(requirements) du projet.
4
CAGAN, Marty. Inspired. p16
18
/
5. Un UX Designer est ensuite chargé de designer le produit conformément aux

spécifications. Il peut y avoir des allers-retours entre le design et le product
manager pour ajuster les spécifications.
6. L’équipe de réalisation développe le produit conformément aux spécifications. Si
Scrum ou une autre “méthode agile” est utilisée, le travail de développement est
itératif (les “sprints”) et le product manager peut adapter le travail des sprints
suivants en fonction des livrables des sprints précédents.
7. Une phase de test finale permet souvent au product manager et éventuellement
au business de valider le développement produit. Des ajustements éventuels
peuvent être faits avec l’équipe de réalisation.
8. Les développements sont ensuite livrés en production. Le produit ou sa
nouvelle version est disponible au client. L’organisation peut récupérer du
feedback, et passer au projet suivant.
Qu’est ce qui ne va pas dans ce modèle ? D’abord, la plupart des idées à développer
sont imposées par le management et le business, soit parce qu’ils pensent savoir ce qui
va fonctionner, parce que quelqu’un (souvent un cabinet de conseil) leur a dit que ça
allait marcher, ou parce qu’un client particulier leur a demandé. Bien souvent, ces idées
ne sont pas liées à une vision, une stratégie cohérente, mais parce qu’elles répondent
à une opportunité ou un problème identifié à ce moment-là. Sans vision, sans stratégie
il n’est pas clair que ce problème vaille réellement la peine d’être traité, ou que
l’opportunité vaille la peine d’être prise.
Le business case est supposé définir le coût d’un projet, ses bénéfices attendus, et le
planning de mise en œuvre est donné par la roadmap. Pourtant au moment où le
business case est défini, il est impossible de vraiment savoir combien le projet coûtera
et en combien de temps il pourra être livré. Pour correctement définir ces informations,
il faut que les équipes produit puissent définir suffisamment de détails pour estimer la
charge de travail, ce qui prend du temps. Elles sont généralement peu impliquées dans
cette étape, et même si elles le sont, la solution n’est pas encore définie ! Les
prédictions sont donc souvent fournies avec la technique dite du “doigt mouillé”...
Les bénéfices également sont impossibles à estimer à ce stade. La plupart des idées ne
marchent pas. Entre 50% et 75% des idées sont des échecs. Alberto Savoia, ancien
Engineering Director chez Google notamment, estime que 90% des idées sont des
échecs5. Les raisons de l’échec sont diverses : le produit n’est pas utilisé (il ne répond
pas à un problème utilisateur, il est mal designé ou il est trop cher…), il n’est pas
réalisable, il n’est pas viable économiquement ou juridiquement, ou pas compatible
avec le business model de l’entreprise... Avec ce modèle, toutes les idées dont le
business case est validé vont jusqu’à la phase de build et de delivery, ou au mieux sont
arrêtées très tard dans le processus.
Dans le modèle traditionnel, les équipes produit arrivent bien trop tard dans le
processus. Elles ont plus ou moins de liberté pour peaufiner les détails, mais la solution
globale leur est imposée. Elles sont souvent très éloignées des utilisateurs finaux du
5
SAVOIA, Alberto. #1: The Law of Market Failure. 31 janvier 2019. [vidéo]
https://www.youtube.com/watch?v=74JNI6RSkME
19
/
produit, en particulier lorsqu’il s’agit d’un produit externe. Les équipes de réalisations
sont même rarement impliquées dans la définition des spécifications, se cantonnant à
développer ce qui est imposé par d'autres, sans profiter de leurs préconisations sur le
volet technique. Les membres de l’équipe produit agissent comme des mercenaires,
alors qu’ils devraient être des “missionnaires”, pour reprendre la formule de Marty
Cagan6 et trouver eux-mêmes la meilleure solution aux problèmes grâce au discovery.
Tout ceci mène à avoir une organisation centrée sur les d’outputs, “extrants”7 en
français, c’est à dire les livrables de l’organisation produits, autrement dit les
fonctionnalités, là où l’organisation devrait être centrée sur les outcomes,
c’est-à-dire le résultat de la production, la valeur directement produite par les efforts de
production. C’est ce que Melissa Perri appelle le Build Trap : le fait de toujours vouloir
développer de nouvelles fonctionnalités ou de nouveaux produits, en perdant de vue
l’objectif premier, à savoir résoudre un problème et apporter de la valeur au client
et au business.
“Building is the easy part of the product development

process. Figuring out what to build and how we are going
to build it is the hard part” - Melissa Perri8
L’illusion de l’agilité
De nombreuses grandes entreprises françaises ont entamé leur transformation digitale
en mettant en place une structure agile au sein de leur DSI. Dans beaucoup de cas,
l’agilité n’est qu’un slogan, un buzzword qu’il faut utiliser, comme big data ou
blockchain. Combien d’entreprises prétendent faire de l’agilité en sous-traitant le
développement logiciel à une ESN en mode forfaitaire ?
L’ensemble des méthodes et frameworks dits “agiles”, découlant tous du Manifeste

Agile9, ont pour objectif d’optimiser le développement de logiciels en favorisant les
cycles de développement courts, itératifs et incrémentaux, permettant notamment
d’accueillir plus facilement des changements dans la définition des besoins et des
priorités. Cette approche agile du développement logiciel apporte une plus-value réelle,
permet de raccourcir le time-to-market, d’identifier plus tôt certaines erreurs voire de
constater un échec plus tôt.
6
CAGAN, Marty. Missionaries vs. Mercenaries. 24 novembre 2015. Extrait de Inspired.
https://svpg.com/missionaries-vs-mercenaries/
7
OCDE. Glossaire des principaux termes relatifs à l’évaluation et la gestion axée sur les résultats.
http://www.oecd.org/derec/dacnetwork/35336188.pdf
8
Traduction personnelle : “La réalisation technique est la partie la plus facile du processus de
développement produit. Comprendre ce qu’il faut réaliser et comment le réaliser est la partie
difficile.”
PERRI, Melissa. The Build Trap. 5 août 2014. Extrait de Escaping the Build Trap.
https://melissaperri.com/blog/2014/08/05/the-build-trap
9
Manifeste pour le développement Agile de logiciels.
https://agilemanifesto.org/iso/fr/manifesto.html
20
/
Néanmoins ces méthodes et frameworks agiles, et le plus utilisé d’entre eux, Scrum, en
particulier, ne renseignent en rien sur la façon d’alimenter le backlog, c'est-à-dire de
concevoir les éléments qui seront traités par les équipes de réalisation. Elles
expliquent comment mieux délivrer, mais elles n’expliquent pas pourquoi.
En appliquant parfaitement un framework agile au développement produit, en

respectant l’esprit de l’agilité, mais en conservant les mêmes processus de décision
pour définir les projets prioritaires et alimenter et maintenir la roadmap produit, les
organisations restent fondamentalement dans une structure décisionnelle figée qui
ne permet pas d’éviter de construire des produits qui ne répondent pas à un vrai
besoin, qui ne produisent pas de valeur, ou qui répondent de la mauvaise manière à un
problème bien réel. Elles exécutent superbement un produit qui peut ne servir à rien.
Le product management moderne propose de changer le paradigme de la prise de

décision, tout en intégrant ces pratiques agiles de développement de logiciel, pour
optimiser la valeur et le time-to-market et pour anticiper et corriger au maximum les
risques de produire quelque chose d’inutile. Le product management donne des
méthodes sur la conception du produit, c’est-à-dire savoir quel produit on doit
développer, là où l’agilité donne des méthodes sur la construction de ce produit, ou
comment le produit doit être développé.
1.2 - Le product management moderne : un modèle centré

sur la production de valeur business et client
Le product management est une fonction ancienne dans les entreprises
technologiques. Les startups américaines de la fin du XXe siècle et des années 2000
avaient une fonction Product, dont l’objectif était de gérer le backlog produit et de
piloter les développements, un peu comme les départements MOA français. Le product
management s’est totalement transformé au tournant des années 2010 pour devenir
une discipline centrale couvrant l’intégralité du cycle de vie produit, en s’inspirant du
Design Thinking, du Lean et des méthodes agiles.
Le product management moderne est une discipline qui vise à découvrir des problèmes
utilisateurs, définir les meilleures solutions à ces problèmes et faire réaliser cette
solution via la création ou l’évolution d’un produit numérique. L’objectif du product
management est donc de passer d’une logique stakeholder-driven (produit défini par les
parties prenantes internes) ou sales-driven (produit définir par les vendeurs, sur
demande de clients spécifiques, non scalable) à une logique centrée sur la résolution de
problèmes utilisateurs et la génération d’outcome.
Dit autrement, l’objectif du product management est de créer de l’innovation, en

trouvant des solutions nouvelles et meilleures que les précédentes aux bons problèmes
des utilisateurs, pour générer du retour sur investissement.
21
/
Marty Cagan résume cette discipline dans le sous-titre de son ouvrage Inspired,
considérée par beaucoup comme la bible du product management :
“How to create tech products customers love.” - Marty Cagan10
De plus en plus, le product management est une fonction à part entière dans les
organisations, séparées des fonctions business (marketing, vente…) et de la fonction de
production (généralement la direction des systèmes d’information). En particulier chez
celles dont tout ou partie du business repose sur un produit ou service numérique
fourni à des utilisateurs finaux, qu’ils soient B2B ou B2C.
Le product management s’applique essentiellement pour des produits numériques, des

produits qui s’appuient sur du développement logiciel. Par produit, on entend
également les services “productisés”, c'est-à-dire automatisés et répétables,
contrairement aux services sur mesures dédiés à un client. La plupart des services
digitaux que vous connaissez relèvent du product management : Google Search,
Facebook ou Twitter, Netflik, Airbnb, Amazon, Office 365, Salesforce, Zoom, Uber,
Android… ou bien ManoMano, LeBonCoin, MeilleursAgents, Veepee, Doctolib, Blablacar,
Yuka, MyCanal, Oui SNCF… Les objets utilisant des logiciels, en particulier s’ils sont
connectés, sont également développés en utilisant des techniques de product
management : Tesla, iPhone, Netatmo ou Parrot par exemple.
Le product management est défini par Martin Eriksson, leader d’influence de la

communauté produit et fondateur de Mind the Product11, comme une fonction à
l’intersection du Business, de l’UX et de la Tech :
Le product management à l’intersection du design, du business et de la tech,

Martin Eriksson12
10
“Comment créer des produits numériques que les clients adorent.”
11
Mind the Product. https://www.mindtheproduct.com/
12
ERIKSON, Martin. What, exactly, is a Product Manager?. 5 octobre 2011.
22
/
Business : le product management vise à maximiser la valeur business des

produits d’une organisation, en atteignant des objectifs business.
Expérience utilisateurs (UX) : afin de créer de la valeur business, le produit doit

d’abord créer de la valeur pour ses utilisateurs. Un produit est créé pour
résoudre un problème client. Les product managers utilisent des techniques
pour connaître les utilisateurs de leur produit, définir les meilleures solutions à
leurs problèmes et les représenter dans le processus de développement produit.
Technologie : Les product managers travaillent étroitement avec les équipes de

réalisation technique, et doivent être capables de comprendre leurs enjeux pour
pouvoir prendre les bonnes décisions.
Le nom “product management” fait la part belle au “produit”. Il ne faut pourtant pas s’y
tromper : Cette fonction met avant tout l’accent sur le client, l’utilisateur du produit, le
problème utilisateur auquel on souhaite répondre. Dans un second temps se pose la
question de la solution à apporter à ce problème, et donc du produit.
Damien Delautier, CPO chez Canal+ et ancien de Molotov et ING, explique l’importance
de se mettre d’accord sur la définition du product management13 :
“Le product management consiste à comprendre ce qui a

de la valeur pour l’utilisateur, et s’assurer que cette valeur
est délivrée facilement et rapidement tout au long du cycle
de vie.” - Damien Delautier
Un produit bien conçu, répondant à de réels besoins clients et proposant une

expérience client idéale est bien souvent un avantage compétitif essentiel dans le
monde actuel. C’est bien sûr le cas lorsque le produit est directement vendu au
consommateur, mais c’est aussi de plus en plus le cas lorsque le produit numérique
intervient dans le parcours client d’un service vendu au client.
Par exemple, l’industrie du taxi a été révolutionnée lors de l’arrivée sur le marché des
VTC et notamment de Uber. Le service fourni pour le consommateur est un transport
en véhicule avec chauffeur, d’un point A à un point B. Rien de directement numérique.
Néanmoins les grandes entreprises de taxi comme G7 n’ont eu d’autre choix que
d’améliorer drastiquement l’expérience client en proposant notamment un service
numérique permettant à leurs usagers de commander leur taxi en ligne facilement et à
tout moment, y compris au dernier moment, en choisissant les bonnes options et de
payer la course depuis leur smartphone. Le produit numérique est devenu un avantage
compétitif dans une industrie a priori peu digitale.
Alexandre Takacs, ancien de Viadeo et Meetic, a rejoint le magazine L’Express en tant

que Director of Product & UX pour justement mettre en place une démarche de product
https://www.mindtheproduct.com/what-exactly-is-a-product-manager/
13
Product Therapy - REX sur la mise en place d'un framework Produit chez Canal + par Damien
Delautier. Wivoo. [vidéo] ttps://www.youtube.com/watch?v=jmXuvN2x4vM
23
/
management. La direction avait choisi d’opérer un changement stratégique sur l’activité

web, justifiant la mise en place d’une organisation centrée sur l’utilisateur.
“Je suis arrivé dans un contexte de refonte globale de

l'offre produit de L’Express, du positionnement de la
marque, du positionnement éditorial aussi, qui voulait
vraiment accélérer sur le digital. L’Express voulait
monter en gamme, mettre la satisfaction utilisateur au
centre. Avant, L'Express était très orienté business et le plus
important était de faire le plus d'audience possible pour faire le plus
de revenus publicitaires possible. Quand je suis arrivé, l’objectif était
de passer vers un modèle basé sur l'abonnement. Et pour faire payer
les utilisateurs, ils devaient y trouver leur compte, qu'ils soient
contents, vraiment fidélisés et engagés auprès de la marque
L'Express.” - Alexandre Takacs
Un autre effet de la démarche produit, et non des moindre, est d’éviter les déchets, ou
de les réduire le plus possible. En changeant la démarche, en mettant les problèmes de
l’utilisateur au centre dès la définition de la stratégie produit et dès sa conception,
l’organisation peut valider ses hypothèses avant de passer aux coûteuses phases de
développements. Elle permet d’adopter une véritable culture du fail fast learn fast, en
minimisant le coût des échecs et en maximisant l’apprentissage de ces échecs.
Le product management vise à casser les silos qui préexistaient, séparant d’un côté le
business donneur d’ordres, en charge de la définition des besoins liés au produit
(typiquement le marketing produit ou autres fonction business) et de l’autre les équipes
en charge de la réalisation du produit, en particulier au sein des directions IT. Dans le
modèle produit met au centre des équipes pluridisciplinaires regroupant un product
manager, garant de la valeur business et utilisateurs, et les équipes techniques.
Le modèle d’organisation produit vise notamment à prévenir 4 risques formalisés par

Marty Cagan14 :
● risque de valeur (value risk) : que le produit ne soit pas acheté par les clients, ou
pas utilisé par les utilisateurs.
● risque d’utilisabilité (usability risk) : que les utilisateurs ne comprennent pas
comment utiliser le produit, ou qu’ils s’en détournent par déplaisir.
● risque de faisabilité (feasibility risk) : que l’équipe de réalisation ne soit pas
capable de développer le produit de façon qualitative, dans un temps
raisonnable avec les ressources disponibles.
● risque de viabilité business (business viability) : que le produit ne permette pas
à l’organisation d’atteindre ses objectifs business, qu’un problème contractuel ou
juridique empêche de le sortir, que les coûts d’acquisition de nouveaux clients
soient trop élevés...
14
CAGAN, Marty. The Four Big Risks. 4 décembre 2017. https://svpg.com/four-big-risks/
24
/
2 - Une histoire du product

management
2.1 - Naissance de la stratégie de marque… et du product
management
On fait traditionnellement remonter l’apparition du product management
à un mémo de Neil H. McElroy, alors chargé de campagnes publicitaires
chez Procter & Gamble. Dans ce mémo McElroy proposait de créer un
poste de “Brand Men” (hommes de la marque). Ces brand men sont
responsables de tous les aspects marketing d’une unique marque, des
recherches de terrain, des tests auprès des clients à la publicité et la promotion des
produits en lien avec les équipes de vente locales. 13 ans plus tard McElroy est devenu
Président de Procter & Gamble, puis Secrétaire d’Etat à la Défense sous Eisenhower.
2.2 - Divisions produit chez HP, optimisation de la

production chez Toyota
En 1957 Hewlett-Packard met en place une structure en “divisions”. Chaque division
était un département autonome de l’entreprise en charge de développer, fabriquer et
marketer un produit. Au sein de chaque département, un product manager était
responsable de porter la voix du client, rapprochant la prise de décision du besoin de ce
dernier.
Au même moment, l'industrie japonaise cherche à se transformer pour faire face à des
problèmes de flux de trésorerie. Taiichi Ohno et Eiji Toyoda inventent le système de
production Toyota basé sur les principes de kaizen15 (amélioration continue) et genchi
genbutsu16 (rechercher les sources d’un problème sur place, avec les acteurs concernés,
afin de prendre la meilleure décision). Une méthode de travail nouvelle apparaît
également : le Kanban, un système de planification qui permet de contrôler chaque
étape du système de production tout en limitant le nombre de tâches en cours, évitant
ainsi les ruptures de production.
2.3 - Le chef de produit marketing dans les années 60

Dans les années 60 aux USA, le rôle de chef de produit prend de l’importance dans la
différenciation des marques, en créant une proposition de marque au plus près des
15
FERNANDEZ, Alain. Le Kaizen et l'amélioration continue. 08 juillet 2019.
https://www.piloter.org/qualite/kaizen.htm
16
FINK, Mike. Genchi Genbutsu : Le Principe Japonais pour mieux résoudre les problèmes. 15
novembre 2019 [vidéo] https://www.youtube.com/watch?v=9t5HDIgYBes
25
/
aspirations des consommateurs. Le marketing était alors centré sur les 4 P de Jerome
McCarthy popularisés par Philip Kotler : le bon produit, à la bonne place, au bon prix, en
utilisant la bonne promotion. Le rôle de chef de produit se résumait néanmoins à une
activité marketing, sans influence sur le développement effectif du produit lui-même.
2.4 - L’approche produit centrée utilisateur dans la tech

Dans les années 70 et 80 les entreprises de tech émergent avec des méthodes
nouvelles permettant d’aligner le développement des produits logiciels avec les attentes
des utilisateurs. L’entreprise californienne Intuit vend des logiciels financiers à des PME
et des particuliers. En prenant une approche centrée utilisateur et en observant ceux-ci
utiliser leurs logiciels directement chez eux, ils ont pu créer un produit au plus proche
de leurs besoins et largement dépasser leurs concurrents.
En 1985, Microsoft développe la première version d’Excel. Le Program Manager porte la

valeur business tout au long du cycle produit en partenariat avec les équipes de
développements.
2.5 - Le produit au coeur des méthodes agiles

Dans les années 1990, les ingénieurs logiciels cherchent à créer de nouvelles méthodes
de travail permettant d’intégrer plus facilement les retours utilisateurs et les
changements de priorités. Elles sont connues sous le nom de RAD, DSDM, Scrum,
eXtreme programming… En 2001 les créateurs et promoteurs de ces méthodes se
réunissent pour rédiger le Manifeste Agile17 :
“Nous découvrons comment mieux développer des logiciels par la pratique

et en aidant les autres à le faire. Ces expériences nous ont amenés à
valoriser :
● Les individus et leurs interactions plus que les processus et les

outils
● Des logiciels opérationnels plus qu’une documentation exhaustive
● La collaboration avec les clients plus que la négociation
contractuelle
● L’adaptation au changement plus que le suivi d’un plan
Nous reconnaissons la valeur des seconds éléments, mais privilégions les

premiers.”
Les développeurs pouvaient dès lors se concentrer sur la valeur client de leur
production, et les product managers sur la définition de cette valeur client. Avec ces
méthodes les product managers peuvent prendre en compte le feedback client plus
rapidement et ajuster les orientations de développement tout au long du cycle de vie du
17
CUNNINGHAM Ward. Manifeste pour le développement Agile de logiciels. 2001.
https://agilemanifesto.org/iso/fr/manifesto.html
26
/
produit. L’expérience utilisateur (UX) auparavant cantonnée à un rôle périphérique est

maintenant prise en compte et renouvelée à chaque instant.
2.6 - L’avènement des directions produit

Dans les années 2010, le product management prend un nouvel essor. Le produit
devient un dévient un département indépendant du marketing et de la tech et est
souvent représenté dans les instances de direction des entreprises tech avec la création
du poste de Chief Product Officer (CPO).
Les méthodologies de gestion produit changent. L’utilisateur est véritablement mis au

centre d’une démarche de découverte et de livraison en continu (continuous discovery et
continuous delivery).
Suite à l’avènement des méthodes de développement « agile » au sein des DSI, on voit
également apparaître des postes de product management dans des entreprises
traditionnelles. Ces postes tendent souvent à remplacer les postes de chef de projet et
de directeur de projet, non sans poser quelques problèmes.
27
/
3 - L’équipe produit
L’équipe produit, souvent appelée squad, est l’unité de base d’une organisation produit.
Il s’agit d’une équipe transdisciplinaire et autonome dans la réalisation d’un produit, ou
d’une partie du produit qui lui est assignée lors que l’organisation est dotée de plusieurs
équipes.
La base d’une équipe produit est ce que Airbnb appelle la “triforce”18 : le product
management, le design et la technique (engineering en anglais).
Chaque équipe produit est dotée d’un product manager, qui pilote le travail de la squad,
sans être un manager hiérarchique. Le product manager est essentiellement chargé de
gérer les risques de viabilité business et de valeur. Chaque squad est doté d’un unique
product manager, même si certains comme MeilleursAgents ont expérimenté des
squads à 2 PM, leur permettant de tourner entre discovery et delivery19.
La plupart des équipes sont également dotées d’un designer, responsable de la

définition de l’expérience client et des interfaces. Il doit faire en sorte de gérer le risque
d’utilisabilité du produit. En fonction des besoins et des organisations, ce rôle peut être
rempli par une ou plusieurs personnes. Certaines organisations choisissent de partager
leurs designers entre plusieurs équipes, ce qui peut parfois poser des problèmes quant
à l’autonomie de l’équipe. Enfin, certaines équipes en charge de produits purement
techniques sans interface, comme des API ou des fondations techniques (un datalake
par exemple) ou un progiciel interne sans customisation de l’interface (CRM, outil RH…)
peuvent se passer d’un designer, au moins sur la partie design d’interface.
Enfin le troisième pilier de l’équipe produit est l’équipe de réalisation en elle-même, qui
va donner vie au produit : développeurs back-end et front-end, testeurs, architectes
solution et tout autre profil nécessaire à la réalisation technique du produit, en fonction
des besoins de l’équipe. Ils sont chargés de gérer le risque de faisabilité du produit.
D’autres types de profils peuvent être ajoutés à l’équipe en fonction des besoins :
business analyst, data analyst ou data scientist en charge notamment de faire parler les
data relatives au produit pour permettre son amélioration, product marketing manager
en charge de l’acquisition et du go-to market, experts métiers, scrum master…
Tous ces profils dépendent généralement de départements différents : les

développeurs sont rattachés à un Chief Technical Officer (CTO), le product manager et les
designers sont dans un département Product, voire dans 2 départements séparés,
certains membres de l’équipe peuvent appartenir à des départements marketing ou
d’expertise métier.
18
Alex Schleifer: a mission to belong anywhere. Design Better : 20 août 2017 [podcast]
https://www.designbetter.co/podcast/alex-schleifer/
19
PAROLA, Christopher. Deux Product Managers par Impact Team. 24 décembre 2019.
https://medium.com/meilleursagents-engineering/deux-products-managers-par-impact-team-26
4aacd74a91
28
/
Néanmoins ils forment une équipe stable sur une ou plusieurs années pour parvenir à
faire naître une alchimie entre les membres. Les membres de l’équipe partagent les
mêmes objectifs de livraison de valeur utilisateurs et business sur un produit ou une
partie de produit donnée. Idéalement, cela signifie que les membres d’une équipe
produit partagent tous une base commune d’objectifs individuels, quel que soit le
département auquel ils sont rattachés.
3.1 - Quelle taille idéale pour une équipe produit ?

Il n’y a pas de recette toute faite applicable à chaque produit et chaque organisation.
L’équipe produit doit tout de même rester relativement petite : on parle souvent d’une
dizaine de personnes maximum.
La taille idéale dépend de beaucoup de facteurs : périmètre de l’équipe, expérience de

l’équipe, maturité du produit… Une petite startup naissante n’a pas forcément besoin
de plus d’un ou deux développeurs pour monter la première itération du produit. En
phase de scale, la croissance ultra-rapide du produit peut nécessiter une équipe
beaucoup plus grosse. Un produit mature avec un product/market fit établi et peu de
concurrence peut tourner avec une équipe plus petite s’il n’y a plus autant besoin
d’innover.
La taille de l’équipe va aussi dépendre de la capacité du product manager à alimenter

les développeurs. Avec trop de développeurs dans l’équipe, le PM risque d’être trop
focalisé sur la description de ce qu’il attend de l’équipes (spécifications, user stories…),
ne pas donner assez de détails sur ce qu’il attend et ne pas avoir assez de temps à
passer sur le discovery. C’est d’ailleurs un écueil dans lequel tombent de nombreuses
organisations : quand on manque de temps, c’est toujours le discovery qui disparaît. A
l’inverse, avec trop peu de développeurs le PM risque d’avoir un peu trop de temps
libre…
Dans les phases exploratoires précédant le lancement d’un nouveau produit ou d’une
fonctionnalité innovante dans un produit existant, l’équipe passe quasiment tout son
temps à faire du discovery. Dans ce cas un PM accompagné d’un designer et d’un ou
deux développeurs expérimentés seront suffisants pour créer des prototypes ou mener
des ateliers de Design Sprint. Sur un produit beaucoup plus mature, l’équipe pourrait
passer beaucoup moins de temps en discovery et se focaliser sur des éléments de
refonte technique pour rendre le produit plus scalable, ce qui nécessitera beaucoup de
développeurs et de testeurs, mais un investissement moindre côté PM et designer.
3.2 - Les caractéristiques d’une équipe produit qui réussit

Richard Banfield, Martin Eriksson et Nate Walkinshaw20 identifient quelques
caractéristiques communes aux meilleures équipes produit, celles qui livrent les
meilleurs produits, le plus de valeur pour leurs utilisateurs et leurs business.
20
BANFIELD, Richard, ERIKSSON, Martin et WALKINSHAW Nate, Product Leadership
29
/
Amélioration continue de l’équipe
Les membres de ces équipes ne prennent jamais rien pour acquis. Ils cherchent
toujours à mieux connaître leurs utilisateurs et à identifier leurs problèmes. Ils
identifient les opportunités offertes par de nouvelles technologies. Ils cherchent un
feedback permanent et améliorent leurs propres processus et organisation.
Communication
Que ce soit au sein de l’équipe, avec les autres équipes ou avec les stakeholders, la
communication est un aspect clé du product management.
Empathie
Comprendre les utilisateurs, vraiment comprendre leurs problèmes est une des clés
pour parvenir à délivrer des solutions qui rendent les produits si réussis. On peut
notamment se référer aux méthodes de Design Thinking. Les membres de l’équipe
doivent également faire preuve d’empathie entre eux, comprendre les problématiques
et les enjeux de chacun pour favoriser un esprit d’équipe et avancer ensemble vers des
objectifs communs.
Diversité
Les origines socio-culturelles et les expériences différentes sont le terreau d’une équipe
capable de regarder les problèmes avec des perspectives différentes, pour trouver des
réponses originales et pertinentes
Compréhension du business
Si un bon produit est un produit qui apporte de la valeur au client en résolvant des
problèmes pertinents, c’est aussi un produit qui apporte de la valeur business et génère
du ROI. La compréhension du business model et de notions de gestion permettent à
l’équipe de savoir où mettre les efforts.
Représentation cross-fonctionnelle du produit
L’équipe doit avoir une représentation globale de toutes les fonctionnalités du produit
pour fournir un travail cohérent et éviter les biais.
Co-localisation
La littérature produit et agile insiste sur l’importance d’avoir le product manager, les
designers et les développeurs dans le même bureau ou côte à côte dans un open space.
30
/
Plusieurs études scientifiques en montrent les bénéfices certains2122. Cette

colocalisation a 2 intérêts principaux :
● favoriser la collaboration, le partage et la communication entre les membres de

l’équipe.
● renforcer le sentiment d’appartenance à une équipe unique.
Concrètement, grâce à la colocalisation, le partage d’information augmente entre les

membres. La production de “déchets”, c'est-à-dire de code ou de documentation inutile
diminue. Les membres montent en compétence plus rapidement. La motivation et la
satisfaction des équipes s’envolent. La vélocité et la productivité de l’équipe
augmentent. Les problèmes sont résolus plus vite. Enfin et surtout, elle permet de
garder le focus sur l’objectif de l’équipe, plutôt que de s’éparpiller sur la résolution de
problèmes non prioritaires pour l’organisation.
La crise sanitaire de 2020 et la généralisation du télétravail mettent fortement à mal la

colocalisation des équipes. Il faut trouver des parades pour garder l’esprit d’équipe et
une communication optimale entre ses membres : outils de communication écrite et
visuelle entre les membres, outils de partage de roadmap et de backlog, tableaux
blancs virtuels… Les membres d’une équipe doivent pouvoir être en interaction en
permanence, et lors d’une réunion d’idéation par exemple les personnes à distance ne
doivent pas se sentir exclues et pouvoir participer comme les autres. Idéalement, il faut
également prévoir des séances régulières de partage en physique, par exemple lors
d’une revue trimestrielle de roadmap, qui permettra également de créer du lien.
Autonomie
Une équipe qui fonctionne est une équipe à laquelle on a assigné un objectif business,
la réalisation d’un outcome, et à qui on a donné les moyens de réaliser cet objectif
business.
Cela passe d’abord par une équipe qui a le moins besoin possible de recourir à des
personnes hors de l’équipe pour réaliser son objectif. D’où l’importance des équipes
pluridisciplinaires.
L’équipe doit ensuite être capable de prendre seule les décisions sur la manière
d’atteindre ses objectifs, en respectant les règles de l’organisation (business model,
principes produits, règles d’architecture et d’infrastructure…). Elle doit donc pouvoir
décider des solutions à apporter aux problèmes qui ont été priorisés. Cela ne veut pas
dire que le management ou le business ne peut pas proposer d’éléments à rajouter à la
roadmap et au backlog, ou proposer de solutions à des problèmes identifiés. Mais
l’équipe doit pouvoir valider la pertinence ou non de ces éléments et de ces solutions,
grâce au discovery, qui lui permettront de justifier ses choix. Si un commercial arrive
21
ECCLES, Mike, SMITH, Joanne, TANNER, Maureen, VAN BELLE, Jean-Paul Van Belle and
VAN DER WATT, Stephan, The Impact of Collocation on the Effectiveness of Agile is Development
Teams. University of Cape Town, South Africa. 2010.
https://ibimapublishing.com/articles/CIBIMA/2010/959194/959194.pdf
22
TEASLEY, Stephanie, COVI, Lisa, KRISHNAN, M.S., OLSON, Judith S., How Does Radical Collocation
Help a Team Succeed?. https://agileconsortium.pbworks.com/f/p339-teasley%20collocation.pdf
31
/
avec une demande pour l’équipe, le product manager doit pouvoir étudier la pertinence
de cette demande vis-à-vis des objectifs, tester la solution auprès des utilisateurs,
éventuellement la faire évoluer, et choisir de l’intégrer ou non dans la roadmap, en
collaboration avec ses stakeholders.
Pour être autonome, l’équipe doit pouvoir en avoir les moyens. Marty Cagan23 identifie
plusieurs facteurs à prendre en compte pour définir le degré d’autonomie d’une équipe,
notamment en ce qui concerne le choix des solutions techniques à apporter à un
problème, et en particulier quant à la remise en cause d’éléments de fondation
technique (architecture, infrastructure) communs à l’organisation :
● Maturité de l’équipe : une équipe composée d’experts seniors travaillant

ensemble depuis plusieurs années sera plus à même de faire de bons choix et
qu’une équipe montée il y a deux mois composée de profils juniors.
● Importance de la vitesse : les fondations servent à éviter que chaque équipe
réinvente ce qui a déjà été fait. Si l’entreprise veut livrer rapidement, à court
terme, le respect de ces fondations au détriment de l’autonomie et de la
recherche de solutions optimales doit être priorisée.
● Importance de l’intégration : si les différents produits ou parties du produit
sont très interdépendants, les éléments communs d’architecture sont critiques.
● Source d’innovation : si l’innovation dans le produit passe par ses fondations,
l’organisation doit permettre aux équipes de les revisiter. Autrement la créativité
doit être concentrée sur le niveau applicatif.
● Taille et localisation de l’organisation : plus l’entreprise est grosse et présente
sur des sites différents plus il est compliqué de laisser beaucoup d’autonomie
aux équipes. Certains essayent de résoudre ce problème en créant des rôles ou
des processus transverses, ou des équipes d’ “excellence”.
● Culture d’entreprise : certaines entreprises poussent à la mise en commun au
maximum. Certaines équipes seniors peuvent être gênées par ces freins à
l’autonomie.
● Maturité de la technologie : attention à ne pas essayer de standardiser sur des
technologies trop récentes. Pousser les équipes à utiliser des éléments
communs immatures peut se révéler désastreux si l’organisation s’aperçoit qu’il
faut les changer ou les faire évoluer.
● Importance business du produit : sur les parties critiques du produit d’un point
de vue business, il peut être dangereux de remettre en cause les fondations. Sur
des parties moins importantes, notamment lorsque l’équipe explore de
nouvelles fonctionnalités, leur permettre d’innover en remettant en cause des
acquis peut s’avérer payant, et l’échec sera moins pénalisant.
● Niveau de responsabilisation : l’autonomie va de pair avec la responsabilité de
l’équipe. Si l’organisation ne permet pas à l’équipe d’être autonome, elle ne doit
pas la tenir responsable d’éventuels échecs. A l’inverse, si l’équipe est vraiment
responsabilisée et suffisamment mature et compétente, alors il est
probablement judicieux de respecter ses choix. Elle ne voudra pas prendre de
risque si elle ne pense pas qu’il en vaut le coup.
23
CAGAN, Marty. Inspired. p. 97-102
32
/
Interdépendance
Les équipes doivent être autonomes dans leurs choix, mais doivent être capables de
travailler efficacement avec les autres membres de l’organisation. D’abord avec les
autres équipes, afin de fournir une expérience cohérente au sein du produit ou entre
les produits d’une même organisation et une architecture technique rationnelle24. Avec
les parties prenantes et les équipes business pour s’assurer de l’adéquation entre le
marketing, les ventes et le produit en particulier25.
Qui rend des comptes
Les meilleures équipes doivent pouvoir mesurer en permanence le succès ou l’échec de

leurs initiatives, fournir ces informations en toute transparence au management et aux
parties prenantes, et ajuster son travail en fonction de ces informations. C’est comme
cela qu’elle bâtira une relation de confiance.
Enfin, pour qu’une équipe produit fonctionne, il faut qu’elle ait des processus, des
rituels, et du lien.
Les processus permettent de s’assurer que tous les membres comprennent le

fonctionnement de l’équipe, de favoriser la clarté et la transparence entre les membres.
Les rituels incitent à l’échange et à la formalisation de l’information. Une partie de ces

rituels peuvent venir d’un framework agile par exemple, mais ce n’est souvent pas
suffisant. Par exemple, l’échange avec les stakeholders ou avec les clients doit
également être formalisé.
Le lien est enfin garant d’une bonne entente au sein de l’équipe. Les membres de la
squad vont passer toutes leurs journées ensemble pendant des mois voire des années,
à œuvrer vers des objectifs communs. Il est critique d’éviter les tensions récurrentes et
de s’assurer que chaque individu ait un environnement de travail serein, dans lequel il
se sent bien.
24
A ce sujet, voir le chapitre sur le produit à l’échelle.
25
Voir notamment le rôle du product marketing manager.
33
/
II - Les rôles au sein d’une organisation produit
Partie II
Les rôles au sein

d’une organisation
produit
La fonction produit est relativement récente et en constante évolution. L’organisation

produit est basée sur le triptyque Product, Design et Tech, mais les missions de chacun
de ces rôles évoluent fortement d’une organisation à l’autre. La croissance
extrêmement rapide de certaines entreprises et la professionnalisation de la fonction
amènent les organisations à créer régulièrement de nouveaux rôles, en tant que
spécialisation des 3 rôles de base, ou en support des équipes et du management pour
maximiser la valeur livrée. Les tâches assignées à ces nouveaux rôles sont très variables
en fonction du besoin des organisations et des profils recrutés, et se chevauchent
souvent. A chaque organisation de les adapter à ses besoins. Ce chapitre essaye de
donner un panorama loin d’être exhaustif des différents rôles pouvant intervenir sur le
produit.
34
/
1 - Le Product manager, leader du

produit
Le product manager est le composant central de l’équipe produit. Sans être le manager
hiérarchique de personne, il est celui qui orchestre le travail de l’ensemble de l’équipe. Il
est responsable de l’atteinte des objectifs de la squad. On a coutume de dire que
l’équipe est responsable des succès, et que le product manager est responsable des
échecs.
En simplifiant à l’extrême, le rôle du product manager est de tout faire pour atteindre
les objectifs fixés par le management à son équipe dans le cadre de la stratégie et de la
vision produit. Il est donc responsable d’évaluer les différentes options possibles
pour parvenir aux objectifs et définir ce qui est développé par l’équipe de réalisation
et livré à l'utilisateur final. Il est donc responsable d’alimenter et de prioriser le backlog
produit en maximisant la valeur pour l’utilisateur et le business.
A la fin des années 1990, Ben Horowitz, ancien PM de Netscape, fondateur de

Loudcloud et du VC Andreessen Horowitz, avait décrit le Product Manager comme une
personne devant avoir un poste de CEO de son produit26. Cette description fait encore
débat27. Le product manager est pleinement responsable de ce qu’il délivre, il doit
prendre des choix en fonction du ratio coûts/bénéfices, mais il n’a d’autorité
hiérarchique sur personne, et n’a pas la même position vis-à-vis des parties-prenantes
internes.
Marty Cagan identifie 4 responsabilités principales pour être un bon PM. Autant dire
qu’être un expert dans tous ces domaines relève presque du super héros, mais le PM
doit être au moins expert dans un de ces domaines et à l’aise avec les autres.
● Une connaissance profonde du client : afin de construire le bon produit, le PM

doit identifier les bons problèmes et les bonnes solutions. Et pour le faire, il doit
connaître les cibles qu’il adresse. Ses clients directs et indirects, ses utilisateurs.
Connaître leurs problèmes, leurs douleurs, savoir comment ils pensent. Être
familier de leurs processus de décision et d’achat. L’objectif est de ne plus avoir à
deviner ce qui va fonctionner, mais de le savoir. Le PM peut faire appel à la fois à
des données quantitatives (comprendre ce qu’ils font) et qualitatives
(comprendre pourquoi ils le font).
26
HOROWITZ, Ben. Good Product Manager/Bad Product Manager. 15 juin 2012.
https://a16z.com/2012/06/15/good-product-managerbad-product-manager/
27
voir notamment
ERIKSSON, Martin. Product Managers – You Are Not the CEO of Anything. Mind the Product : 15
mars 2017. https://www.mindtheproduct.com/product-managers-not-ceo-anything/
GOTHELF, Jeff. Are product managers really the CEO’s of their product? 5 product leaders weigh
in. 21 septembre 2020.
https://jeffgothelf.com/blog/are-product-managers-really-the-ceos-of-their-product-5-product-le
aders-weigh-in/
35
/
Dans la réalité, le product manager va souvent faire appel à des experts pour
l’aider dans cette compréhension client, mais il doit être capable rapidement de
devenir familier avec lui.
● Une bonne connaissance de la data : depuis l’avènement du numérique, la
quantité de données disponible est devenue phénoménale, pour comprendre
les utilisateurs et ce qu’ils font avec le produit notamment. Le product manager
doit être capable de lire des chiffres, des rapports, utiliser des outils d’analytics,
être familier avec des KPI. Là encore, en fonction des équipes il pourra être
amené à traiter la data directement ou il pourra avoir un expert qui les traite
pour lui. Même dans ce dernier cas, son rôle sera d’interpréter les données
formalisées par un autre.
● Une bonne connaissance du business : le product manager ne livre pas des
produits simplement pour faire plaisir à l’utilisateur. Le produit doit servir des
objectifs business, et le PM doit comprendre la part que ce que son équipe livre
joue dans le business, quel est le business model de l’entreprise et si ce qu’il
propose a du sens dans ce business model. Il doit également connaître les
différents stakeholders business du produit, comprendre leurs enjeux pour
adapter son produit à leurs besoins, mais également les convaincre lorsqu’il le
faut.
● Une bonne connaissance du marché et de l’industrie : le product manager
doit comprendre ce que fait la concurrence directe et indirecte. En particulier
dans un environnement concurrentiel, le product manager doit identifier ce qui
permettra aux clients de la concurrence de “switcher” vers son produit, et
anticiper d’éventuels changements qui pourraient inciter ses clients à partir. Il
doit également être capable d’identifier des tendances de marché et prendre le
bon train au bon moment pour générer des avantages compétitifs. Un product
manager est toujours en veille sur son marché mais aussi d’autres marchés
connexes qui pourraient être sources de bonnes idées.
Enfin, cela peut paraître évident mais le product manager doit être l’expert absolu dans
son produit, savoir exactement comment il fonctionne, connaître ses points forts et ses
éventuelles faiblesses, pour rapidement être capable d’ajuster le tir lorsqu’un problème
ou une opportunité se présente.
1.1 - Les compétences du PM au travers du framework

CORE
Dans son ouvrage Product Management in Practice, Matt Lemay, ancien de Bitly et
Google, met en avant 4 compétences principales des product managers :
Communication, Organisation, Recherche utilisateur (Research) et Exécution
Communication
Nous en avons déjà parlé, la communication au sein d'une équipe produit est clé, et le
PM doit être le chef d’orchestre de cette communication. Il doit s’assurer que tous les
messages passent entre les différents membres, et que les informations nécessaires lui
36
/
sont également remontées. Le PM n’est pas le manager hiérarchique des membres de

l’équipe et il doit réussir à les mener vers l’objectif grâce à son influence et ses capacités
à convaincre.
Le PM doit être capable de communiquer efficacement avec ses parties prenantes, en

particulier les membres du management. Communiquer sa roadmap, communiquer les
progrès dans l’atteinte des objectifs, communiquer sur les échecs également. Il doit
également être capable de souligner des incohérences, quand un stakeholder évoque
un besoin qui n’a jamais été évoqué et qui ne rentre pas dans les objectifs assignés à
l’équipe : ne pas hésiter à mettre les pieds dans le plat et créer une situation a priori
inconfortable, plutôt que de se taire et de céder tacitement sur l’atteinte des objectifs,
ou remettre le problème à plus tard.
Enfin le PM doit savoir communiquer avec ses utilisateurs, pour les comprendre,
identifier leurs besoins réels, évaluer si les solutions qu’il propose peuvent fonctionner.
Et communiquer lors du lancement d’un produit ou d’une nouvelle version.
Alexia Boulot, ancienne Head of Product chez Veepee, Outburst, iGraal et Voyages SNCF,
parle ainsi du positionnement du PM :
“Dans le métier de Product manager, il y a une vraie

logique de management. Management de l'équipe de Dev
d’abord : organiser et rythmer le travail, donner du sens,
expliquer “pourquoi” et donner du feedback sur ce qui a
été réalisé pour que les gens aient une sensation de l'impact qu'ils
ont eu. Management des parties prenantes également :
communication et transparence. Expliquer ce qu'on fait, pourquoi on
le fait. Comment ça marche. C'est une vraie logique de trait d'union.”
- Alexia Boulot
Organisation
En tant que leader de l’équipe produit, le PM est chargé d’organiser les flux au sein de la
squad. Il priorise les différentes tâches à l’avance pour s’assurer que chaque membre
sait sur quoi et pourquoi travailler sans constamment venir lui demander. Il fait en sorte
que les objectifs et la roadmap soient correctement partagés, que le backlog soit
alimenté et priorisé. Il s’assure que l’équipe dispose de règles de travail suffisamment
claires.
Il est capable d’alterner entre vision court terme, livraison du backlog sous 2 semaines,
et vision long terme, roadmap à 6 mois ou 1 an, voire participation à la stratégie à
plusieurs années.
Si l’organisation adopte des règles communes, il doit être capable de les cascader
auprès de l’équipe. Si l’équipe adopte un framework de travail comme Scrum, il s’assure
que les différents rituels sont bien menés, que les artefacts comme la definition of ready
et definition of done sont bien compris.
37
/
Sans être expert dans les différentes frameworks de product management ou de

développement agile, ni sans connaître l’intégralité des méthodes de discovery ou de
construction de roadmap, un PM est capable de sélectionner les bons outils pour son
équipe et ses parties prenantes, c’est à dire ceux avec lesquels l’équipe sera à l’aise et
qui permettront au mieux d’atteindre les objectifs fixés.
Un PM organisé ne résout pas seulement les problèmes au sein de l’équipe, mais il fait
en sorte qu’ils n’arrivent plus. Si certaines règles ne sont pas adaptées, il doit être
capable de comprendre pourquoi et de faire évoluer les règles plutôt que de les ignorer
au cas par cas.
Recherche utilisateurs
Le fondement du product management est qu’un produit à succès est un produit qui
propose des solutions innovantes et meilleures que celles qui existent à de vrais
problèmes utilisateurs. Et que pour être capable de proposer ces solutions innovantes,
il faut d’abord connaître ses utilisateurs et leurs besoins, puis valider les solutions le
plus possible avant de les lancer à grande échelle.
Idéalement, le product manager doit connaître son marché et ses utilisateurs, ou en

tout cas apprendre à les connaître. Il doit être capable de communiquer avec eux. Il est
capable de faire la synthèse de toutes les informations qu’il reçoit, que ce soit des
données qualitatives ou quantitatives en tirer des enseignements et des perspectives
(insights en anglais) qu’il peut en tirer pour comprendre quels sont les vrais problèmes.
Il est suffisamment créatif pour proposer des solutions nouvelles et pertinentes en
travaillant avec les designers et les ingénieurs, ou en tout cas doit être capable de
stimuler la créativité de son équipe.
Un bon PM ne considère rien comme acquis, il sait se remettre en question. Et remettre

en question les opinions des membres de son équipe et de ses parties prenantes.
Exécution
Bien sûr, on attend au final du product manager qu’il soit capable de livrer un produit
de qualité. Le développement du produit en lui-même revient à l’équipe de réalisation,
et d’autres personnes sont en charge de mettre le produit en production.
Mais le PM doit être capable de leur expliquer ce qu’ils doivent faire, et pourquoi ils
doivent le faire. Son rôle n’est pas de dire comment le faire, il n’a pas à définir les
aspects techniques de la solution. Par contre, il doit être capable de comprendre
suffisamment les aspects techniques du produit pour avoir une bonne intuition de ce
qui est faisable ou non. Et il comprend les enjeux des équipes de réalisation, afin de
prendre les bons arbitrages qui peuvent lui revenir lorsqu’un problème survient.
C’est typiquement le rôle du product owner décrit dans Scrum.
38
/
1.2 - Lead product manager

Parfois appelé Principal Product Manager ou simplement Senior Product Manager, le Lead
PM est généralement le plus haut poste de PM en tant que contributeur individuel,
c'est-à-dire sans management hiérarchique.
Les Lead PM ont des responsabilités similaires aux PM dans le pilotage d’une équipe
produit, mais sont généralement positionnés sur des équipes critiques pour le succès
du produit et de l’organisation. Soit en étant responsables des parties les plus sensibles
et complexes du produit, celles qui sont au centre de la livraison de valeur aux
utilisateurs et au business. Soit en étant leader de l’innovation, à la recherche de
nouvelles features pouvant générer un avantage compétitif décisif, soit au démarrage
d’un nouveau produit ou d’une nouvelle ligne produit. Dans ce cas, le Lead PM se
concentrera en particulier sur le discovery, pour trouver de nouveaux problèmes à
résoudre et des solutions innovantes. Il sera généralement accompagné d’un designer
et d’un lead tech eux aussi seniors.
Le Lead PM fait également office de mentor et de coach pour les autres product
managers de l’organisation, pour les aider à monter en compétence et travailler avec
eux sur la résolution de problèmes complexes.
Plus que les autres PM, le lead PM doit avoir une excellente compréhension des
utilisateurs, du marché, du business et de la tech. Il est capable de travailler en
indépendance et est à l’aise avec la gestion des stakeholders. Il a un état d’esprit
stratégique, est capable de penser à long terme et d’assister son manager.
1.3 - Associate product manager

Les product managers sont généralement des postes seniors, avec un niveau important
de responsabilité. La plupart des PMs ont une expérience passée, en tant que business
analyst, développeur, designer ou marketer. Si certaines startups ou certains cabinets
de conseil proposent des postes de product manager à des personnes sans expérience,
difficile de trouver un poste dans une scale-up ou un grand groupe de tech. Et donc
difficile d’acquérir cette expérience.
Afin de pallier ce problème et créer un plan de carrière “product” complet, certaines

entreprises ont créé un poste de “associate product manager” (APM), parfois appelé
Junior PM. Dans certaines organisations, ce poste est appelé Product Analyst, même si ce
poste est généralement plus orienté Discovery. La plupart du temps l’APM ne dispose
pas d’une équipe produit à part entière, mais vient en appui d’un product manager
senior dans une équipe constituée.
Les responsabilités de l’APM varient d’une organisation à l’autre et d’une équipe à

l’autre, mais en règle générale il prend part aux phases de discovery et en en effectue la
synthèse, participe à expliquer aux équipes de réalisation ce qu’elles doivent
développer, aide au reporting auprès des stakeholders… Il peut être plus ou moins
39
/
autonome sur la création de nouvelles fonctionnalités pour le produit. Il peut également

suppléer le product manager lors de ses congés.
En échange, il bénéficie d’un mentorat de la part du PM senior de l’équipe et bénéficie

de son expérience, afin de pouvoir ensuite prétendre à un poste de PM à part entière et
disposer de sa propre équipe produit.
1.4 - Product Manager et Product Owner

Scrum est un framework de développement élaboré dans les années 2000 par Ken
Schwaber et Jeff Sutherland sur les fondements du manifeste agile et formalisé en 2011
dans le Scrum Guide28. Il s’agit du framework de développement agile le plus célèbre et
le plus utilisé, au point qu’il est presque devenu synonyme d’agilité dans le
développement de produits logiciels.
Scrum introduit un nouveau rôle appelé “Product Owner”. Le Scrum Guide décrit ainsi
ce rôle :
“Le Product Owner est responsable de maximiser la valeur du produit

résultant du travail de l’équipe de développement. La façon de jouer ce
rôle peut varier grandement selon les organisations, les équipes Scrum et
les individus.
Le Product Owner est le seul responsable de la gestion du Backlog Produit

(Product Backlog). La gestion du Backlog Produit comprend :
● L’expression claire des éléments du Backlog produit ;

● L’ordonnancement des éléments dans le Backlog produit pour
mieux réaliser les objectifs et les missions ;
● L’optimisation de la valeur du travail effectué par l'équipe de
développement ;
● L’assurance que le Backlog produit est visible, transparent et clair
pour tous, et montre sur quoi l’équipe de développement travaillera
prochainement ; et,
● L’assurance que l'équipe de développement comprend
adéquatement les éléments du Backlog produit.”
De nombreuses organisations confondent le métier de product manager et le rôle de

product owner (PO). Souvent dans ces organisations, le product owner est un
administrateur du backlog produit, qui décide du contenu de chaque itération de
développement et s’assure que l’équipe de développement livre correctement ce qui lui
est demandé. Il est généralement placé au sein de la direction informatique, loin du
client.
28
Le guide Scrum.
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-French.pdf
40
/
Scrum n’explique pas comment le product owner doit prioriser son backlog. Dans
la plupart des entreprises utilisant Scrum, le product owner se contente de prendre ses
instructions de la part d’un client interne, d’un manager ou d’un comité de pilotage. Il a
un certain degré de latitude sur les détails, mais il n’est pas au contact du client et il ne
peut pas être véritablement garant de ce que le produit va effectivement fonctionner.
La maintenance du backlog produit fait partie des attributions du product manager. Il

est bien celui qui explique aux équipes de réalisation ce qu’elles doivent faire et
pourquoi le faire. Il est celui qui valide que les développements sont adéquats et
peuvent être livrés en production. Si l’organisation utilise Scrum, alors le product
manager est le product owner. Mais le product manager est bien plus que le product
owner décrit par scrum. Il est responsable de l’intégralité du cycle de vie du produit, y
compris la création du produit, l’adéquation du produit avec le business model de
l’organisation, les phases de découverte produit (discovery), le go-to-market… Là où le
rôle de product owner ne couvre que les parties - très importantes ! - du build et du
delivery, c'est-à-dire le développement du produit et sa mise en production. Reste que
certaines organisations ont des “Product Owners” qui font effectivement un poste de
product manager… L’importance n’est pas le terme, mais bien de s’assurer que le leader
de l’équipe produit, peu importe son nom, est bien responsable de découvrir les
problèmes, valider les solutions avant leur développement, et piloter ces
développements.
Alternativement, d’autres organisations ont choisi de se doter à la fois de product

managers et de product owners. Dans ces organisations, le product manager est
responsable de la roadmap produit, à un horizon moyen terme. Il est généralement en
contact avec les clients, et peut être en charge d’une partie du discovery. Le product
owner est chargé du backlog produit, soit le court terme. C’est lui qui est chargé des
détails et en contact direct avec l’équipe de réalisation. Ce modèle est notamment celui
qui est imposé par le framework SAFe (Scaled Agile Framework)29.
Cette séparation des rôles a l’avantage de répartir les tâches : la stratégie pour le
product manager, et l’opérationnel pour le product owner. La charge de travail du
product manager peut être énorme, la séparation des deux rôles a pour avantage de
l’alléger et de permettre à chacun de se concentrer sur ce qu’il a à faire.
29
Site officiel https://www.scaledagileframework.com/
41
/
flux et responsabilités dans une organisation séparant PM et PO
Quel est le problème dans une organisation produit ? Avec ce type de modèle, les
équipes produit ont tendance à redevenir de simples exécutants, les fonctionnalités
étant imposées par les couches managériales supérieures. Le product owner se
retrouve loin des préoccupations des clients finaux, et est concentré sur la livraison
d’outputs, sans maîtriser la génération de valeur pour le business et le client, et sans
être concerné par les phases de discovery, si elles existent. Or, comme j’ai tenté de
l'expliquer dans le premier chapitre, les modèles top-down ne permettent pas
d’optimiser le produit et font généralement tomber les organisations dans le build trap
de Melissa Perri.
D’autres entreprises ont créé un nouveau rôle, celui de proxy product owner. Il est
typiquement utilisé dans 2 cas : 1. le product manager ou product owner est au sein
d’équipes business et n’a pas le temps ou pas les compétences pour expliquer aux
équipes de réalisation ce qu’elles doivent faire précisément ; 2. la réalisation est
externalisée auprès d’une société de service informatique, et le product manager
délègue le travail quotidien avec les équipes de développement au PPO. Dans les deux
cas, le product manager donne les grandes lignes de ce qu’il faut développer et priorise
le backlog, quand le proxy product owner rédige les détails (user stories) et les explique
aux développeurs. Là encore, impossible pour les équipes de réalisation de vraiment
développer le bon produit, elles sont bien trop loin du problème initial qu’il est censé
résoudre.
Les organisations qui répartissent les tâches du PM entre plusieurs personnes le font
généralement pour une raison : les tâches de product manager sont souvent trop
importantes pour être assurées par une seule personne. Comment tout à la fois
prendre le temps de connaître le marché et les utilisateurs, déterminer les problèmes à
résoudre, piloter des tests utilisateurs et en tirer des enseignements, définir une
42
/
roadmap, communiquer auprès des stakeholders, alimenter le backlog, suivre le travail

des équipes de réalisation, le valider et piloter les go-to-market ?
La réponse peut paraître simple : en faire moins, mais mieux. La plupart des idées
sont des échecs, elles ne permettent pas de livrer de la valeur. L’esprit du product
management est d’échouer le plus vite possible, idéalement lors de la phase de
discovery, pour se concentrer sur les idées qui fonctionnent, sur les meilleures réponses
au problème. En mettant moins d'efforts sur la phase de build, et plus d’effort sur la
phase de discovery, l’équipe évite de passer énormément de temps à développer des
choses inutiles. Le product manager n’a pas besoin de rédiger 15 user stories chaque
semaine pour alimenter une équipe de réalisation de 10 personnes. Le product
manager et les ingénieurs peuvent se concentrer sur la qualité. Et si les développeurs
sont intégrés aux phases de discovery, elles auront encore moins besoin de détails de la
part du product manager pour réaliser le meilleur produit.
1.5 - PM et chef de projet

Dans les organisations classiques, agiles ou non, le chef de projet est chargé de livrer un
périmètre fonctionnel ou technique demandé par le management et/ou les
stakeholders. Le rôle du chef de projet est de s’assurer que les développeurs délivrent
le périmètre fonctionnel demandé dans les contraintes de temps et de budget
imposées par l’organisation, le fameux triangle “otobos” de la gestion de projet. Il
organise les ressources, s’assure que les spécifications sont écrites (parfois il les écrit
lui-même) en consultant les parties prenantes business et techniques, que les
développeurs réalisent un logiciel informatique conformément aux spécifications, et
qu’enfin ce projet est livré en production, tout ça dans les temps. En cas de pression sur
les délais, il peut être amené à arbitrer certains pans du projet en fonction de ce qui a le
plus d’importance pour les parties prenantes.
La conception de projet est fondamentalement basée sur la livraison d’outputs : de

fonctionnalités, de nouvelles capacités, de nouveaux produits. On ne demande pas
vraiment au chef de projet de livrer de la valeur : la demande a été jugée porteuse
de valeur par le management pour être priorisée, généralement via un business case.
Souvent, une fois le projet fini, le chef de projet est amené à travailler sur un projet
différent, sur une application différente, l’empêchant d’avoir une vision long terme sur
ce qu’il délivre.
Dans la logique produit, la logique est totalement inversée. Les product managers
sont chargés de livrer des outcomes, de la valeur business et utilisateurs. Le PM
définit ce qui a de la valeur ou non, en se basant sur de la recherche utilisateurs, des
tests et de la data. Les directeurs de programmes se sont mutés en Head of Products,
mais ils ne sont plus en charge d’articuler le travail de chefs de projets pour qu’ils
délivrent les fonctionnalités considérées comme porteuses de valeur pour le business ;
ils sont en charge de cascader les objectifs business auprès de leurs équipes, de
s’assurer du bon découpage des responsabilité de chaque équipe et de faire en sorte
qu’ils ont les moyens d’atteindre ces objectifs, et l’autonomie associée.
43
/
Le product management reste une forme de gestion de projet : c’est au PM et au Head

of Product de justifier, études et données à l’appui, la valeur d’une initiative, pour
obtenir les ressources nécessaires au développement de cette initiative. Si les
contraintes fortes de temps doivent être diminuées dans une équipe produit, le PM
reste responsable de la livraison rapide de valeur, et des interdépendances avec les
équipes business. En soi, chaque initiative est un projet, mais ces initiatives s’inscrivent
dans une optique plus large, dans la réalisation d’objectifs business globaux.
Ainsi les compétences, tant au niveau softskills que hardskills sont différentes chez un
product manager et un chef de projet. Lors du passage d’un modèle classique à une
organisation produit, partir du principe que les chefs de projet vont devenir les
nouveaux product managers risque d’être un échec. Il est fondamental de définir les
compétences attendues d’un product manager au sein de l’organisation, et de valider si
les chefs de projets ont ces compétences, ou sont capables de les acquérir rapidement,
s’ils comprennent le nouveau modèle, et s’ils ont l’appétence
Reste qu’au sein d’organisations produit complexes, les projets d’entreprise continuent
d’exister. Certaines initiatives importantes pour le business peuvent ne pas pouvoir être
traitées par une équipe produit dédiée ou même une ligne produit, mais vont
nécessiter des actions transverses au sein de l’organisation produit. Avoir un chef de
projet dédié à la réalisation de ce projet peut s’avérer payant. Son rôle est d’aller voir
tous les product managers concernés pour qu’ils comprennent ces besoins et les
intègrent à leurs roadmaps, et négocier avec les Head of Products respectifs pour qu’ils
adaptent les objectifs. Généralement ces chefs de projets transverses ne portent plus le
nom de chefs de projet, mais peuvent devenir des product ops ou des product
strategists par exemple.
44
/
2 - Le product design, leader de

l’expérience utilisateurs
L’alliance française des designers (AFD) définit ainsi le design30 :
“Le design est un processus intellectuel créatif, pluridisciplinaire et

humaniste, dont le but est de traiter et d’apporter des solutions aux
problématiques de tous les jours, petites et grandes, liées aux enjeux
économiques, sociaux et environnementaux.”
Les disciplines de design appliquées aux produits tech sont nombreuses, essayons d’y
voir plus clair :
Design disciplines, @mindmeandsgn (Albina Cholak)31
30
Alliance française des designers. Design, designers : définitions.
http://www.alliance-francaise-des-designers.org/definition-du-design.html
31
CHOLAK, Albina, Design disciplines, in Instagram. 31 juillet 2019
https://www.instagram.com/p/B0lQQj9AAsE/. Référencée par Thiga dans Le Product Design dans
une organisation produit
45
/
Le premier niveau, le plus petit dans le schéma ci-dessus, est le UI design, pour User
Interface. Les UI designers sont responsables de la couche purement graphique du
produit. Ils conçoivent une interface esthétique, pratique et intuitive. C’est eux qui
définissent les couleurs, les formes, les typographies, les espacements, la navigation, les
contours, les interactions des boutons, les effets de parallaxe… Ils sont également
chargés de créer et appliquer la charte graphique d’une marque. Il s’agit de l’aspect le
plus “artistique” du design appliqué aux produits digitaux. Il correspond à peu près à ce
qui était appelé “webdesign” il y a 10 ans. C’est le dernier maillon de la chaîne de
production du design.
L’UX design, soit design d'expérience utilisateurs (user experience) a été d’abord
popularisé par Don Norman chez Apple dans les années 1980, puis s’est généralisé
comme une discipline indispensable des produits tech au début des années 2010. L’UX
design comprend les phases de recherche utilisateur et leur formalisation pour en tirer
des enseignements, la définition des parcours clients et l’ergonomie. L’UX englobe l’UI,
mais un UX designer ne sait pas forcément designer les meilleures interfaces d’un point
de vue graphique. Certaines équipes disposent d’UX designers en charge des parcours
clients et des wireframes, et d’UI designers en charge des interfaces graphiques
proprement dites.
Le Product Design est une discipline récente introduite avec le product management
moderne. Il s’agit d’une discipline assez proche de l’UX design, mais avec une approche
différente du rôle. Le product designer est un membre à part entière de l’équipe, et il
intervient dans l’intégralité du cycle de vie du produit en collaboration constante avec le
PM. Le product designer intervient dans les phases de stratégie et de définition de la
roadmap. Il mène les phases de recherche (discovery) en collaboration avec le PM. Il
s’adapte aux cycles agiles de conception du produit. Ils connaissent les objectifs du
produit et livrent des designs adaptés à la réalisation de ces objectifs, en prenant en
compte les enjeux business.
Le CX design pour Customer Experience, soit expérience client correspond au design

de l’ensemble des interfaces que le client peut avoir avec la marque, au-delà du produit.
Dans le cas d’une marque proposant à la fois de la vente en ligne et en boutique, le CX
designer permet de construire une expérience cohérente et sans couture entre les
visites sur le site de e-commerce, les newsletters reçues par le client, la visite en
magasin, l’application mobile, la livraison, le service après-vente… Chez Uber, il s’agit à la
fois de l’expérience dans l’app, l’expérience d’attente du véhicule, et l’expérience du
trajet dans le véhicule avec le chauffeur.
Le design de service enfin s’applique à améliorer les services fournis aux utilisateurs
sur les différents points de contact qu’il a avec l’organisation (que le service en question
soit entièrement, partiellement ou pas du tout digital d’ailleurs), en incluant une
réflexion sur les processus business utilisés pour fournir ces services.
46
/
2.1 - Product designer

Traditionnellement, les UX/UI designers intervenaient dans les projets digitaux tard
dans le processus. Le chef de projet ou le product manager écrivait des spécifications
après avoir récolté les besoins en termes de fonctionnalités auprès des stakeholders.
Ces spécifications étaient fournies d’une part aux développeurs pour qu’ils estiment la
charge de travail et débutent les développements backend, et d’autre part au designer
pour qu’il crée des interfaces graphiques agréables pour les utilisateurs. Le design
arrivait donc en bout de route, sans réflexion sur la stratégie produit.
Autre manière de procéder, la spécification par le design. Dans ce cas, l’UX designer (ou
l’équipe s’ils sont plusieurs) mène une étude plus ou bien moins exécutée, auprès des
stakeholders pour récolter leurs besoins, et éventuellement auprès des utilisateurs. Ils
itèrent ensuite sur des propositions de parcours au sein du produit et de design
graphique qu’ils valident avec ces stakeholders, après avoir peut-être effectué quelques
tests utilisateur. Une fois validé, le design est fourni aux équipes de réalisation qui ont
pour charge de livrer un produit conforme à ce design. L’équipe de réalisation utilise
typiquement un framework agile, type scrum ou kanban. Des ajustements peuvent être
faits à la marge en termes de design, lorsque certains éléments s’avèrent compliqués à
réaliser, ou lorsque l’équipe design ou un stakeholder change d’avis. Avec un peu de
chance, ces ajustements sont réalisés pour coller avec les cycles de développements
“agiles”. Pour autant, le processus en lui-même est un cycle en V (waterfall).
Le product designer (PD) intervient dans une démarche différente. Il intervient tout au
long du cycle de vie du produit dans une démarche de continuous discovery, en
partenariat fort avec le product manager, et de continuous delivery, en comprenant les
enjeux du framework agile utilisé par l’équipe de réalisation et en s’y adaptant. Il adopte
une démarche holistique, en prenant en compte l’intégralité du parcours client, y
compris avec les points de contact en dehors du pur produit (démarche CX).
J’ai distingué UX design et le product design, mais de nombreuses organisations

nomment leurs designers produit “UX”. Comme pour la distinction entre PM et PO, le
nom importe peu. L’important est que ces UX designers adhèrent à la démarche
produit.
Vanessa Guilloteau, Head of Product Design chez Thiga, identifie quelques hard skills
essentielles pour un product designer32 :
● La User research : maîtriser les techniques permettant d’acquérir une excellente

connaissance des utilisateurs potentiels du produit, de comprendre leurs
problèmes et d’en définir les meilleures solutions.
ex : les études qualitatives & quantitatives, les user tests, les personae, les
experience maps
32
GUILLOTEAU, Vanessa. Dessine-moi un product designer. Thiga : 22 novembre 2018.
https://blog.thiga.co/dessine-moi-un-product-designer/
47
/
● L’Idéation : animer des sessions collaboratives pour faire émerger les meilleures
idées par les différentes parties prenantes.
exemples : l’approche de Design Thinking, la méthode des Design Sprints
● La Conception : réfléchir au produit d’un point de vue “big picture”, proposer des
solutions innovantes et efficaces et savoir les présenter.
ex: l’audit d’interface, les workflows, l’architecture de l’information, les
wireframes, les storyboards
● L’UI Design : créer les interfaces graphiques à faire tester aux utilisateurs avant
les développements, les valider ou les faire évoluer, et les transmettre aux
équipes de réalisation.
exemples : les prototypes, le design d’interface, d’animations et d’interactions
● Le Product Ownership & Analytics : comprendre le cadre de travail dans lequel
l’équipe évolue, comprendre les objectifs de l’équipe et pouvoir mesurer la
progression vers l’atteinte de ces objectifs.
exemples : frameworks agiles (Scrum, Kanban…), user stories, roadmapping,
métriques d’usage du Produit
● Le Content Management : alimenter le produit en narratifs, comprendre les
enjeux des équipes en charge des contenus, optimiser le référencement,
construire l’architecture de l’information
exemples : stratégie de contenus, stratégie éditoriale, UX writing
● Le Développement : produire des animations interactives, fournir des bases de
codes aux développeurs front-end, comprendre leurs enjeux
exemples : intégration HTML/CSS, conception d’animations et d’interactions
Le plus possible, le product manager et product designer doivent travailler ensemble

sur chaque idée, dès le commencement : réflexion stratégique, connaissance
utilisateurs, test des solutions proposées… Le designer doit également travailler dans
une démarche itérative le plus possible avec le PM et les développeurs. Le design, les
fonctionnalités et la technique doivent s’alimenter les uns les autres afin de créer le
meilleur produit pour répondre aux problèmes des utilisateurs.
Similairement au product management, il peut exister des rôles de Lead Designer (ou
Principal Designer ou Senior Product Designer) qui s’occuperont des parties les plus
sensibles du produit, ou des parties les plus innovantes, notamment sur le lancement
de nouveaux produits. Ils sont également en charge de mentorer les PD plus juniors de
l’organisation et assister le management dans la mise en place d’un design holistique.
2.2 - Les autres rôles du design

UI designer
Les organisations produit cherchent généralement à recruter des profils de product
designer fullstack, c'est-à-dire capable de maîtriser toutes les chaînes de production du
design, de la recherche utilisateur à la conception des interfaces graphiques.
Dans certains cas, elles doivent séparer les rôles, soit par choix (besoin d’excellence,
organisation de l’équipe, charge de travail…) soit par contrainte (profils indisponibles,
48
/
séniorité des ressources internes…). Elles peuvent donc avoir recours à des profils
spécialisés dans le design des interfaces graphiques, potentiellement capables d’aller
plus loin que des profils généralistes.
L’UI designer peut également être mutualisé au sein d’une organisation, afin de
produire un design system cohérent33, en explicitant des règles communes sur les
interfaces qui seront exploitées par les product designers de chaque squad : couleurs,
typo, composants et patterns, grid layouts (grilles d’agencement des éléments de
design), iconographie, imagerie… et tout élément de design réutilisable au sein d’un
produit ou d’une organisation.
UX writer
L’UX writer est un spécialiste des éléments de texte et des éléments éditoriaux au sein
d’un produit. Il est le garant de la cohérence éditoriale et de marque au sein du produit.
Il s’assure que les textes aident à la compréhension du produit pour fournir l’expérience
la plus intuitive possible et réduire la charge informationnelle. Il peut également
intervenir dans la localisation d’un produit en plusieurs langues. C’est une discipline
reconnue en tant que telle récemment, et qui prend de l’ampleur au sein des meilleures
organisations produit34.
En fonction du produit, ses responsabilités peuvent être diverses, par exemple :
● Il s’assure que tous les micro-textes présents dans le produit sont cohérents, et
aisément compréhensibles par les utilisateurs : titres, labels des champs d’un
formulaire, messages de validation ou d’erreur, tooltips…
● Il rédige des contenus qui aident l’utilisateur à comprendre au mieux le produit,
comme des FAQ par exemple.
● Il crée un storytelling cohérent pour des landing pages efficaces
● Il optimise la description des articles dans des fiches produit
L’UX writer a recours à des techniques de discovery pour trouver les meilleures
formulations (tests utilisateurs, AB testing…)
Dans le cadre d’un produit web (site e-commerce par exemple), il travaille en
partenariat avec les équipes marketing et maîtrise les techniques de SEO pour favoriser
un bon référencement sur les moteurs de recherche.
DesignOps
Le rôle de DesignOps prend de l’ampleur au sein des grandes organisations produit.
Son rôle est d’assurer la cohérence du travail des designers au sein de l’organisation, et
de faciliter ce travail en leur fournissant des guides, des processus et des outils :
33
voir par exemple https://design.axa.com/ pour accéder au design system utilisé par toutes les
entités du groupe AXA
34
LIGERTWOOD, Guy. UX Writing: How to do it like Google with this powerful checklist. UX Planet : 5
juin 2017.
https://uxplanet.org/ux-writing-how-to-do-it-like-google-with-this-powerful-checklist-e263cc37f5f
1
49
/
● Il partage les bonnes pratiques en termes de design au sein de l’organisation. Il

est notamment chargé du partage du design system et de sa mise en
application. Il est également le garant du respect des normes d’accessibilité des
produits (WCAG 2.0, ARIA, ATAG 2.0, UAAG 2.0…).
● Il définit les processus de travail des équipes design, les échanges entre les
différents designers (UX researchers, product designers des différentes
squads…) et avec les autres membres des équipes produits (intégration dans les
processus d’agilité des équipes de réalisation, partage d’information avec les
équipes data…)
● Il gère les ressources design, alloue les profils aux différentes équipes ou projets,
gère les plans de formation individuels et collectifs.
● Il organise des évènements et des réunions pour réunir les équipes designs
autour de problématiques communes et favoriser les échanges.
● Il fournit des outils communs pour les phases de discovery, la production des
designs et leur partage avec les équipes de réalisation (Axure, InVision, Sketch,
Zeplin, Hotjar, Testapic, Lookback, etc.)
● Il communique sur les activités des équipes design auprès du reste de
l’organisation et met en avant la valeur produite
2.3 - Une organisation sans design ?

Que se passe-t-il lorsqu’une organisation ne possède pas de product designers en
propre ?
Le pire qui puisse arriver est l’absence de product discovery. C’est ce qui se passe
encore dans de nombreuses entreprises qui fonctionnent avec le modèle traditionnel
en cascade : les stakeholders imposent les projets et les fonctionnalités qu’un chef de
projet doit faire développer, sans aucune assurance que les idées vont fonctionner, et
en générant énormément de déchets.
Dans d’autres cas, le product discovery est assuré exclusivement par les product
managers. Ce PM doit avoir les reins extrêmement solides pour couvrir seul l’acquisition
de connaissance client, faire tester ses solutions et être capable d’alimenter les équipes
de développement. Et il risque probablement de manquer de compétence quand il faut
tester des idées auprès des utilisateurs.
Sans product designer, le PM se voit contraint de réaliser les spécifications de design

lui-même. En fonction de ses compétences, il peut être plus ou moins capable de
produire des parcours utilisateurs et des wireframes. L’écart sera à combler par les
équipes de développement directement, en fonction des compétences des designers
front, et en s’inspirant si possible d’une charte graphique marketing ou d’un autre
produit de l’organisation. Éventuellement l’équipe fera appel à un “webdesigner” interne
ou externe pour appliquer la pure couche graphique, mais sans réflexion globale sur le
produit. Autant dire qu’il y a peu de chance que les interfaces du produit soient
cohérentes, intuitives, plaisantes d’utilisation et sans charge informationnelle
importante.
50
/
Parfois ces phases sont confiées à une agence externe. Le problème avec les agences
externes est qu’elles ne sont pas responsabilisées sur les résultats. Elles mènent des
études, fournissent des présentations manquant souvent de transparence, livrent leurs
conclusions, et sont payées sans engagement de résultat business. Elles peuvent
également être chargées de produire les design graphiques, livrés sous forme de
maquettes PDF, InVision ou sur Zeplin par exemple, que l’équipe sera en charge
d’exécuter, avec tous les travers décrits à propos de l’ “ancien” UX Design.
Ces agences peuvent parfaitement bien exécuter leur tâche. Elles sont souvent expertes
dans leur domaine, et sont capables de mettre en place les meilleures techniques de
discovery pour fournir au final un design esthétiquement très réussi. Mais elles
manquent d’une vision long terme et holistique du produit, et auront énormément de
mal à travailler de façon itérative et agile avec les équipes produit. Elles sont guidées
par des impératifs court terme et le pire qu’elles risquent est de ne pas remporter le
prochain contrat… Même si le design est parfaitement exécuté, l’organisation devient
dépendante de l’agence et la plupart de la connaissance client et de l’expérience design
acquise pendant la mission sera perdue à la fin du contrat. Le recours à des agences a
du sens pour des produits à durée de vie courte, dans le cadre de campagnes
marketing par exemple, ou pour des produits à plus faible valeur ajoutée. Si le produit
est vraiment important dans la stratégie de l’entreprise, quitte à recourir à une agence,
alors faites-le pour faire monter en compétences vos designers internes.
51
/
3 - L’équipe de réalisation, de l’idée

à la réalité
L’équipe de réalisation est l’équipe qui va donner vie au produit. Ils sont également
régulièrement appelés tech. Dans le cas d’un produit purement logiciel (application
mobile, site web, logiciel SaaS…) il s’agit généralement de développeurs et autres
ingénieurs logiciels, avec leurs diverses spécialités. Dans le cadre d’un produit
comprenant une partie hardware (smartphones, objets connectés, drones, voiture
connectée…) des ingénieurs hardware en charge des capteurs notamment peuvent
également faire partie de l’équipe.
Au sein d’une équipe produit, les personnes en charge de la partie réalisation doivent
être davantage que de simples ingénieurs exécutant les demandes émanant du
business ou du product manager. Elles doivent être au clair avec la démarche produit,
et toujours avoir en tête les objectifs business et travailler dans pour atteindre ces
objectifs business, les outcomes, plutôt que pour livrer des fonctionnalités, les outputs.
Elles doivent également être familiarisées avec les utilisateurs, comprendre leurs enjeux
et leurs problèmes, afin de développer les bonnes solutions.
En contrepartie, le product manager doit être capable de comprendre les enjeux des
équipes de réalisation, être suffisamment à l’aise lors de discussions techniques pour
pouvoir prendre les bonnes décisions. Et fournir un feedback régulier aux techs quant à
leur contribution à la réalisation des objectifs business.
Les équipes de réalisation sont impliquées dans l’intégralité du cycle de production

produit. Cela signifie que leur travail ne commence pas lorsque des items du backlog
arrivent dans le sprint planning (dans le cadre d’une équipe fonctionnant en Scrum).
Certains membres de l’équipe de réalisation participent aux phases de discovery : ils
fournissent des idées pour résoudre les problèmes utilisateurs, ils co-construisent des
prototypes ou des POC (proof-of-concept) pour les tests utilisateurs, ils donnent leur avis
sur la faisabilité technique des options envisagées par le PM. Reste qu’ils doivent le
moins possible développer de lignes de code dans ces phases de discovery, le but étant
d’aller le plus vite possible et d’éviter de gâcher des ressources précieuses dans des
échecs.
Lors des phases de build, le rôle du product manager est d’expliquer aux équipes de
réalisation ce qu’elles doivent construire et pourquoi elles doivent le construire. Mais il
évite au maximum de préconiser comment le construire, et laisse l’équipe définir
elle-même les meilleures réponses techniques. Par contre, il doit être disponible pour
répondre à toutes les questions que ses membres pourraient poser, et faire des
arbitrages si besoin.
52
/
3.1 - Les développeurs

Le cœur de l’équipe de réalisation est évidemment constitué des développeurs qui
créent et font évoluer les lignes de codes qui constituent le produit.
Les développeurs de l’équipe sont formés aux différentes technologies qui constituent
le produit, que ce soit en termes de langage de programmation, framework de
développement, socles applicatifs, APIs… Ils sont également à l’aise avec les frameworks
agiles utilisés par l’équipe ou l’organisation, les différentes normes d’architecture, de
sécurité, de devops…
Les développeurs au sein de l’équipe produit sont généralement répartis en deux

groupes :
● Les développeurs dits back-end, qui gèrent la partie “cachée” de l’application :

toutes les couches de traitement de l’information, les règles de gestion, la
gestion des bases de données le développement et l’intégration d’APIs
permettant aux différents systèmes d'interagir, les configurations de serveurs
applicatifs, les moteurs de recherche… Les langages qu’ils maîtrisent sont
typiquement Java, PHP, C#, Python, Ruby, NodeJS, SQL…
● Les développeurs dits front-end, qui s’occupent de la partie “visible” de
l’application : les couches graphiques. Ils travaillent en partenariat étroit avec les
product designers pour la partie graphique, et avec les développeurs back-end
pour exploiter les API qu’ils développent et afficher les informations à l’écran, ou
traiter les informations fournies par les utilisateurs. Ils utilisent typiquement
HTML, CSS et Javascript, ainsi que de nombreux frameworks reposant sur ces
trois langages, comme React, Angular, Bootstrap, Vuejs; jQuery… Les applications
mobiles natives utilisent des frameworks natifs très spécifiques, propres à
Android et iOS
Certains développeurs généralistes sont dits fullstack et sont capables de développer

aussi bien côté front que back. Les compétences techniques restent très diverses et la
plupart des équipes possèdent des profils spécialisés, voire très spécialisés dans
certaines technologies. Il n’est pas rare de voir des équipes produits composées d’un
développeur web front-end, un développeur Android, un développeur iOS et un ou
plusieurs développeurs backend plus ou moins spécialisés.
Certaines équipes un peu particulières sont en charge de fournir les plateformes

d’infrastructure utilisées par les autres équipes pour développer leurs produits : on
parle de IaaS pour Infrastructure as a Service, c’est-à-dire la mise à disposition de
serveurs permettant de contenir les applicatifs du produit, ou de préférence de PaaS,
Platform as a Service, des services d’infrastructure pré-packagés et préconfigurés.
Concrètement, avec une plateforme PaaS les développeurs n’ont plus à se soucier de la
configuration des serveurs, des systèmes d’exploitation, des mises à jour de version,
etc. Ils ont à leur disposition des containers applicatifs et services de base de données,
de moteur d’indexation, de serveurs web, de services de messagerie, de monitoring…
directement disponibles et utilisables en toute autonomie.
53
/
Afin de fournir ces services de plateforme, les équipes de réalisation de ces produits
“plateforme” sont composées de profils très spécifiques et techniques, comme des DBA
(administrateurs de base de données) ou ingénieurs réseaux. Le product manager de
cette équipe plateforme, au service des autres, a lui aussi un profil très technique.
3.2 - Tech Lead

Chaque équipe produit doit disposer d’un Tech Lead, voire d’un tech lead front-end et
d’un tech lead back-end. Il est parfois appelé Lead Developer ou Senior Developer. Le tech
lead est un profil senior, particulièrement compétent dans au moins une des
technologies employées par l’équipe. Il a une vision holistique du produit et est celui qui
comprend le mieux l’interaction entre les différents composants qui composent le
produit dont l’équipe a la responsabilité, mais également les interactions avec les autres
produits de l’organisation.
Le Tech Lead est responsable de l’application des normes techniques internes, en

termes de frameworks, de processus, d’outils et de langages. Il pourra interagir avec les
experts techniques lorsqu’une intervention externe est nécessaire (sécurité,
infrastructure, ops, architecture…).
Le Tech lead est aussi susceptible d’intervenir en priorité lors des phases de discovery,
en raison de ses compétences techniques et de sa connaissance profonde du produit.
3.3 - Quality Assurance (QA)

Les ingénieurs d’assurance qualité (QA) assurent le bon fonctionnement du produit en
mettant en place des tests automatisés pour s’assurer à tout moment qu’il n’y a pas de
bug, que le produit fonctionne conformément aux attentes.
L’objectif est double :
● Vérifier que les développements récemment achevés par les développeurs

fonctionnent conformément aux attentes, dans le respect de critères définis avec
le product manager (par exemple des critères d’acceptation liés aux user stories,
pour tous les développements effectués durant le sprint, dans une démarche
scrum)
● S’assurer qu’il n’y a pas de régression, c’est-à-dire de bugs apparus sur
d’anciennes fonctionnalités liées à des effets de bord des développements
récents, en rejouant régulièrement tous les tests développés dans les itérations
précédentes.
Avec une QA bien exécutée le product manager doit pouvoir être confiant dans sa
capacité à livrer ses itérations produit à l’utilisateur final, sans avoir à mener lui-même
une batterie de tests complets et sans risquer de fournir à l’utilisateur un produit plein
de bugs, déceptif voire inutilisable.
54
/
Les bonnes pratiques veulent que les développeurs mettent en place des tests
unitaires, validant le bon fonctionnement de chaque module indépendamment les uns
des autres.
Les tests mis en place par les QA vont plus loin. D’une part, ils assurent des tests de plus
haut niveau, en assemblant les modules ensemble pour tester le fonctionnement global
de l’application. D’autre part, ils apportent une vue fonctionnelle sur le produit, et
définissent des scénarios de test poussés correspondant à des parcours utilisateurs
réels.
Il y a une dizaine d’années, il n’était pas rare de voir des testeurs jouer manuellement
des cahiers de test sans fin pour vérifier que tous les cas d’usage fonctionnaient
correctement. La plupart du temps ces tests étaient effectués après de longs
développements (plusieurs sprints scrum, ou plusieurs mois de développement en
waterfall). Le Time To Market était très mauvais, et le coût de la correction d’un bug était
très élevé puisqu’il fallait replonger dans du code rédigé plusieurs semaines ou mois
auparavant. L’alternative agile était de monopoliser de nombreuses personnes pour
tester pendant le sprint. Le product manager/owner y passait une bonne partie de son
temps.
La QA moderne est maintenant pratiquement totalement automatisée. Ces tests sont

soit développés par les QA, qui prennent souvent le nom de test automation engineers,
soit par les développeurs directement, grâce à des outils comme Selenium, Cucumber,
Ranorex ou Eggplant.
Pour pouvoir définir des tests globaux pertinents par rapport aux besoins des
utilisateurs et aux parcours clients, les QA interviennent en amont des développements.
Ils travaillent avec le product manager et les designers afin de comprendre vraiment
l’utilisateur, avant de comprendre les fonctionnalités. Le QA est souvent considéré
comme le premier utilisateur du produit, il joue lui aussi un peu le représentant de
l’utilisateur auprès de l’équipe de réalisation.
Certaines équipes rédigent même les requirements fournis aux développeurs sous
forme de tests fonctionnels formalisés grâce à un langage de type Gherkin, décrivant
simplement les tests à passer sous un former GIVEN (état de départ) WHEN (action)
THEN (résultat final). Cette méthodologie est appelée BDD, pour Behavior Driven
Development.
Les QA sont donc des experts du fonctionnement du produit, d’un point de vue
fonctionnel et technique. Ils maîtrisent une palette d’outils et de langages spécifiques.
Ils sont à l’aise avec les méthodologies agiles employées au sein de l’équipe. Ils
fournissent des métriques relatives à la qualité du logiciel. Ils comprennent les enjeux
des utilisateurs, certains besoins business et techniques propres au produit (SEO,
accessibilité, sécurité…). Ils sont à l’aise avec les différents outils utilisés pour accéder au
produit, par exemple les navigateurs web, les différentes versions de smartphones et
d’OS mobile, les objets connectés...
55
/
4 - Les experts et fonctions

transverses
4.1 - Product researcher
Le product discovery est une discipline à part entière impliquant un nombre de
savoir-faire et de techniques qu’il est difficile de maîtriser entièrement pour des profils
plus généralistes de PM et de PD.
Par ailleurs, lorsque les organisations grossissent, il peut devenir difficile pour les
product designers et les product managers au sein des équipes de mener l’intégralité
des phases de product discovery.
Le Product researcher est un profil dédié à la recherche utilisateurs, la découverte de

leurs problèmes, la production de connaissances et d’insights… Généralement
mutualisés au sein du département produit ou au sein d’une ligne produit, ils
fournissent des informations qui permettent d’informer les équipes de prendre des
décisions éclairées. La mutualisation permet également d’éviter que plusieurs équipes
produit sollicitent plusieurs fois les utilisateurs sur des sujets connexes avec des
résultats incohérents. Il est parfois appelé UX Researcher.
Attention toutefois à ne pas trop éloigner les équipes de leurs utilisateurs, elles doivent
pouvoir participer activement aux phases de discovery, sinon l’organisation risque de
retomber dans le travers du product manager comme simple PO chargé du delivery
produit.
4.2 - ProductOps
De façon similaire au DesignOps, mentionné plus haut, et calqué sur le modèle du
DevOps, dont je parlerai plus tard, un nouveau rôle émerge dans certaines
organisations en forte croissance. Il a notamment été popularisé par un livre blanc
rédigé par Pendo (société qui édite un outil d’analytics produit et d’interaction
utilisateur) et Product Collective (club professionnel autour du produit)35.
En tant que rôle émergent, les tâches et le positionnement des ProductOps peut être
très différent d’une organisation à l’autre. Généralement, les missions du ProductOps
sont d’harmoniser les processus et de diffuser les bonnes pratiques au sein du
département Produit, et rationaliser les interactions avec les autres départements
intervenant dans le cycle de vie du produit.
35
Pendo & Product Collective. The rise of Product Ops.
56
/
Pendo et Product Collective positionnent ainsi le ProductOps à l’intersection du Produit

(incluant le Design), de l’IT (engineering) et du Customer Success (ou en fonction de
l’entreprise, du marketing, des ventes…) :
Les ProductOps rapportent généralement au directeur du département Produit (CPO,

VP Product…) et aident l’ensemble du leadership produit à construire leur stratégie et
gérer leurs ressources.
Dépendant de chaque organisation, voici un exemple des missions qui peuvent être
confiées au ProductOps :
● Piloter les phases de discovery en amont des phases de développement, en lien

avec les équipes produit. Faciliter les expérimentations menées par les
équipes produit en rationalisant les séquences de tests, en fournissant les
ressources nécessaires, en recrutant les usagers testeurs...
● Centraliser les feedbacks utilisateurs (équipes commerciales et service client,
tickets de support...) et les transformer en données analysables.
● Organiser les sources de données produit et client, assurer l’intégrité et la
qualité de ces données, les croiser et les analyser, pour fournir aux équipes
produit des rapports actionnables.
● Proposer des outils aux PM pour optimiser leurs tâches et harmoniser les
pratiques (outils de communication, de roadmapping, d’idéation…), assurer la
formation à ces outils, les administrer, gérer la relation avec les fournisseurs.
● Fournir des dashboard de reporting à l’organisation produit et aux
stakeholders pour faciliter la prise de décision.
● Optimiser la communication au sein du département produit, et promouvoir
l’apport du département au sein de l’entreprise. Communiquer la roadmap
produit aux clients.
● Favoriser la collaboration et améliorer les processus avec les autres
départements (Tech, marketing, sales, finance…)
57
/
● Assister le management Product sur la définition de la stratégie et

l’organisation des équipes.
“At Uber, product ops is responsible for gathering insights and

scoping out the business needs at the very beginning of the
product development process (which often includes going out
and talking to users), as well as at launch time, working with
their ops counterparts around the world to execute launches
and go-to-market strategy.” - Matt Shroder, ancien Head of Product Operations
chez Uber36
4.3 - Product Data Analyst

Un des points forts des produits digitaux est la quantité colossale de données
disponible. Il y a quelques années, une organisation capable de collecter des données,
de les analyser et d’en tirer quelques conclusions avait un avantage compétitif sur la
concurrence. Dorénavant, l’analyse de la donnée est devenue une discipline commune,
presque obligatoire. L’avantage compétitif réside maintenant dans la capacité à trouver
les bonnes données à croiser, et à en tirer des conclusions pertinentes.
Les données et les KPI sont partout dans la gestion produit : des OKR globaux du
département produit à la moindre modification sur un bouton ou aux micro-tests de
discovery. Le product manager est généralement responsable de l’analyse de données.
Dans des organisations qui grandissent de plus en plus, avec des responsabilités de
plus en plus importantes et un volume de données en croissance exponentielle, les PM
délèguent de plus en plus la collecte et l’analyse des données utilisateurs, produit et
business à des spécialistes, les data analysts.
Le data analyst est en charge de collecter la donnée et en garantir la qualité et la

complétude. Il est également chargé des analyses de données pour fournir au reste
de l’équipe et aux stakeholders des insights leur permettant de prendre les
meilleures décisions. Le data analyst est également responsable de la conformité du
traitement des données personnelles avec les normes en vigueur, comme le RGPD en
Europe.
Le data analyst dispose de compétences techniques en développement (R, Python,

JavaScript, SQL, C#...). Il est familier des outils d’analytics produit (Google Analytics,
Amplitude, Mixpanel, Heap, Pendo...) et des outils de data visualisation et de business
intelligence (Tableau, Google Data Studio, Toucan Toco, Power BI…). Lorsqu’il est
spécialisé dans l’analyse des besoins business et la production d’analyse, il est souvent
appelé business analyst.
36
“Chez Uber, le Product Ops est en charge de rassembler les insights et d’enquêter sur les
besoins business au tout début du processus de développement produit (ce qui implique
souvent de sortir et parler aux utilisateurs), et également au moment du lancement, travailler
avec les Ops des autres départements à travers le monde pour mettre en oeuvre les lancements
et les stratégies de go-to-market.”. Extrait de The Rise of Product Ops.
58
/
Les data scientists sont des profils traitant et analysant les données grâce à des
techniques d’intelligence artificielle de type machine learning. Ils sont spécialisés dans
des technologies de pointe de type big data (R, noSQL, Hadoop, Spark, Scala, D3…)
4.4 - Product Growth

Le growth hacking est un état d’esprit et un ensemble de processus et de techniques
permettant de générer rapidement et à faible coût de la croissance pour entreprise
ou un produit digital. Il est notamment fortement impliqué dans la recherche du
product / market fit.
Le growth hacking fait appel à des méthodes souvent originales et innovantes pour
générer cette croissance. Tous les “hacks” sont testés et leur impact précisément
mesuré avant d’être éventuellement étendus à l’ensemble des utilisateurs sur le
produit.
En fonction de la culture de l’entreprise, le growth peut être soit indépendant (au sein
d’une direction Growth), soit rattaché à un ou plusieurs départements (growth
marketing, product growth, growth engineering, growth design…).
2 modèles principaux existent :
● Le growth manager dispose de sa propre équipe (au sein du département

Growth ou Product) pour développer les expérimentations et les implémenter au
sein du produit. Dans ce cas, il prend le nom de Growth Product Manager, ou
parfois Product Growth Manager. Et les membres de son équipe sont appelés
Growth Designer, Growth Engineer, Growth Data…
● Le growth manager est intégré à une équipe existante, en charge des
expérimentations au même titre qu’un UX researcher par exemple. Il procède à
des tests dans le but d’atteindre les objectifs donnés à la squad, en lien avec le
product manager. Charge au PM d’inclure dans le backlog la pérennisation des
expérimentations réussies, avec les équipes de développement.
59
/
5 - Le management produit
Dans une startup naissante, le produit est généralement piloté par un des
cofondateurs. Lorsque la startup grossit, commence à embaucher plusieurs
développeurs et que le cofondateur n’a plus le temps, ou l’expertise pour gérer le
développement du produit, elle embauche un product manager dédié au pilotage
opérationnel de cette cellule regroupant également le design et la tech.
Quand elle commence à scaler, une seule équipe produit ne suffit plus. Il faut séparer
les activités, créer plusieurs équipes chargées des différentes parties du produit. Et
mettre en place un département pour le département produit.
5.1 - Head of product

Le Head of Product est le premier niveau de management dans la hiérarchie du produit.
Il est parfois appelé Product Director. Le Head of Product est le manager direct des
product managers. Au sein des grosses organisations, le Head of Product est
responsable d’une ligne produit, encadrant les différents PM en charge de parties du
produit.
Alors, que fait un Head of Product ?
● Gestion des individus

○ Recruter les bons talents et les conserver
○ Gérer leur carrière et leurs plans de formation.
○ Coacher les individus, notamment les profils plus juniors
● Gestion des équipes
○ Organiser et coordonner le travail des différentes équipes
○ Mettre en place un environnement propice à l’épanouissement des
product managers, les supporter, les inspirer.
○ Diffuser la culture produit au sein de son équipe
○ Coacher les équipes et accompagner le changement
● Stratégie produit
○ Participer à définir la stratégie produit en lien avec les C-level (membres
du comité de direction) et le business.
○ Décliner la stratégie produit dans ses équipes et donner des objectifs en
accord avec cette stratégie (par exemple, via des OKR)
○ Structurer la roadmap du produit en lien avec les product managers
● Relation avec les autres équipes
○ Créer du lien avec les parties prenantes
○ Aligner les objectifs avec ses contreparties Design et Tech
Ce que le Head of Product ne fait pas :
● Expliquer à ses équipes ce qu’elles doivent faire

● Imposer la roadmap produit
60
/
● Rentrer dans le détail fonctionnel du produit, sauf sur demande d’un PM pour le
conseiller
A noter que dans certaines organisations, notamment des startups en début de

croissance, il arrive que le manager hiérarchique, appelé Group PM, cumule son poste
avec celui de PM d’une squad dédiée.
5.2 - Chief Product Officer

Le Chief Product Officer, ou CPO, est le poste de plus haut niveau dans la hiérarchie du
management produit. A la tête du département, il est C-level et siège donc au comité,
au même titre que le CTO ou le CMO.
Le CPO chapeaute l’ensemble des lignes produit et des Heads of Product, et des
éventuelles strates de management intermédiaires.
Quelles sont les qualités d’un CPO ?
● Il sait attirer les talents et gérer leurs carrières. Il sait quel type de profil
promouvoir au sein de l’organisation. Il sait s’appuyer sur les forces de ses
ressources, et les aider à gérer leurs faiblesses. Et il sait se séparer de ceux avec
qui ça ne fonctionne pas.
● Il est le garant de la vision produit au sein de l’entreprise. Cette vision peut
avoir été forgée par lui-même en accord avec les autres membres du comité
exécutif, ou par un CEO leader visionnaire, mais elle est dans tous les cas portée
par le CPO. Le CPO est également celui qui pilote la stratégie pour atteindre
cette vision, et définit les objectifs de ses différentes équipes.
● Il met en place la structure produit dans l’organisation, du product discovery
au delivery. Des études exploratoires pour la création de certains produits
jusqu’au retrait d’autres produits. Il maîtrise le cycle de vie du produit. Il sait
construire un planning, mener une recherche utilisateur, lire un dashboard de
données produit, ou piloter une équipe technique agile.
● Il diffuse la culture produit au sein de l’organisation. Il promeut des concepts
tels que le continuous discovery et continuous delivery ou le fail fast learn fast. Il est
le premier représentant du produit - et du client - au sein de l’organisation, et
promeut l’apport du département produit auprès des autres fonctions de
l’entreprise. Il s’assure notamment que les équipes produit sont autonomes dans
la prise de décision, et que les parties prenantes business ne tentent pas
d’imposer des fonctionnalités qui ne rentrent pas dans la stratégie.
Au sein d’organisations produit particulièrement importantes, il est possible de trouver

d’autres strates managériales : VP Product, qui pilote généralement plusieurs Head of
Products et rapporte au CPO ; Product Director, situé soit sous le Head of Product, soit
entre le Head of Product et le VP Product… CPO qui n’est pas présent au comité exécutif
et rapport à un C-level (CMO ou CTO), ou à l’inverse membres du Comex qui porte le
titre de VP Product. Et d’autres entreprises ont inventé leurs propres noms de poste.
Les termes changent fortement d’une organisation à l’autre. L’essentiel est d’avoir une
61
/
structure hiérarchique claire, et un management poussant la stratégie produit, le

développement des équipes et leur autonomie dans la prise de décision.
exemple de hiérarchie produit dans une grande entreprise37
5.3 - Head of Design, leader de l’équipe design

Dans une organisation produit, les designers rapportent soit à des Head of Product,
responsables à la fois des PM et des PD, soit à un Head of Design chapeautant
l’ensemble des designers du département. Il est d’abord responsable d’assurer une
expérience utilisateur holistique, c’est-à-dire cohérente sur tous les canaux et tous les
produits.
Le Head of Design est également chargé de recruter les bonnes ressources et les
retenir, notamment en assurant leur formation et en gérant leur carrière. Il définit les
objectifs individuels de chaque designer, en lien avec les objectifs produit. Idéalement,
une partie au moins de ces objectifs est commune à tous membres de chaque squad
produit, PD, PM et techs.
Le Head of Design rapporte généralement à un C-level, c’est à dire un membre du

comité de direction de l’organisation, idéalement le Chief Product Officer (CPO), parfois
un Chief Marketing Officer ou un Chief Digital Officer. Parfois le responsable du design
est un membre du comité de direction, auquel cas il prend typiquement le nom de Chief
37
Chief Product Officer: Background, Skills Required, and Whether You Need One. Altexsoft : 24
février 2020. https://www.altexsoft.com/blog/chief-product-officer/
62
/
Design Officer (même si encore une fois, les noms ont peu d’importance et changent
énormément d’une organisation à l’autre).
5.4 - Le leadership technique

Au sein des organisations Produit, le CTO, Chief Technology Officer joue un rôle clé, au
moins autant que le CPO. Son département est responsable de la construction
technique des produits et de leur maintien en conditions opérationnelles. Mais
son véritable devoir est de permettre à l’organisation d’atteindre ses objectifs business
en utilisant une approche technologique innovante.
Le CTO est le manager hiérarchique des développeurs et des QA des équipes produits.
En fonction de la taille de l’organisation, il supervise également les équipes en charge du
delivery, du maintien en condition opérationnel du système, des architectes, des
ingénieurs d’infrastructure…
Les responsabilités et le champ d’action du CTO changent énormément en fonction de

la taille de l’organisation et de son contexte38.
Au tout début de la startup, en phase de pre-seed, le CTO est généralement le seul tech
à bord, ou un des seuls. Il définit seul l’architecture du produit, en développe les toutes
premières versions, souvent sous forme de POC ou de MVP, assure la qualité et la
sécurité du produit si celui-ci est déjà prêt à être mis sur le marché, gère les incidents…
Lorsque la startup réunit des fonds, et commence éventuellement à passer à une

démarche produit, le CTO devient le leader d’une petite équipe de développeurs et de
QAs. Il est chargé de recruter son équipe en fonction des besoins techniques, cascade la
vision produit dans son équipe et la stratégie technique pour la réaliser. Il arbitre les
choix techniques. Il doit relever les challenges techniques auxquels son équipe ne
parvient pas à répondre. Une fois le produit lancé, il explore avec le produit les
différentes options jusqu’à trouver un product/market fit, et assure la scalabilité de la
solution et ses évolutions techniques. Il gère les fournisseurs d’infrastructure
(hébergement, réseau, outils collaboratifs…) et les éventuels partenaires techniques. Il
représente le versant technique de l’entreprise, notamment dans le cadre d’évènements
auxquels la startup participe.
Lorsque la startup est en phase de scaling, le CTO est responsable de plusieurs dizaines
de personnes. Des compétences managériales deviennent indispensables pour attirer
et retenir les talents, et organiser la fonction Tech en départements. Il est le
représentant de la vision technique de l’entreprise. Il reste proche des préoccupations
de terrain et doit être l’architecte principal des solutions développées par l’organisation,
et son principal administrateur. Le CTO s’entoure d’experts et de managers
intermédiaires et choisit les partenaires techniques. Il est à la pointe de la technologie,
38
TAYLIYEV, Arslan. What does the CTO in a startup do? Roles and responsibilities. 20 janvier 2020.
https://medium.com/extendnode/what-does-a-cto-in-a-startup-do-roles-and-responsibilities-49a
fd188f541
63
/
capable d’implémenter de nouvelles technologies de pointe qui peuvent être

bénéfiques pour le produit.
Enfin, lorsque l’entreprise est en phase d'expansion maximale, voire de stabilisation, le

département Tech peut compter plus d’une centaine de personnes. Le CTO sait
impérativement s’entourer des meilleurs experts et déléguer le management
opérationnel. Il intervient dans les éventuelles décisions de M&A et de build/buy/partner.
Il pilote la stratégie de R&D et s’assure que ses équipes restent en veille technologique
permanente pour saisir les opportunités techniques propres à donner un avantage
compétitif à l’organisation. Il s’assure de la collaboration au sein de son département, il
évangélise les autres départements sur la valeur apportée par la Tech, et il assure la
représentation technique de l’entreprise à l’extérieur.
64
/
6 - Le marketing dans une

organisation produit
Dans les entreprises ayant mis en place une organisation produit, le rôle du marketing
change. D’après la théorie historique des 4 P créée par Jerome McCarthy et popularisée
par Philip Kotler dans les années 70, le marketing était en charge de la politique de prix,
de la distribution du produit (place) et de la communication autour du produit
(promotion) et du produit, ou en tout cas de la proposition de valeur associée au
produit.
Le product management historique consistait lui à développer le produit conformément

à la proposition de valeur : le marketing décidait de ce qu’il fallait faire, des orientations
du produit à ses caractéristiques, ses fonctionnalités quand il s’agissait d’un produit
numérique ; le product management (généralement appelé assistance à maîtrise
d’ouvrage dans les entreprises française) exécutait les décisions du marketing, décrivait
les spécifications fonctionnelles détaillées et pilotait les développements informatiques.
Avec la modernisation du product management, le département produit est devenu

responsable de la proposition de valeur. Ce sont les product managers qui définissent
les caractéristiques du produit en accord avec les objectifs business de l’entreprise. Les
PM deviennent également des experts dans la connaissance de l’utilisateur et de ses
besoins. Le positionnement et les responsabilités du marketing doivent être adaptés.
Dans les organisations produit, notamment les startups, les marketers “traditionnels”
sont d’abord responsables de l’image de marque, et de l’acquisition, la rétention et la
conversion via des mécanismes en dehors du produit lui-même (canaux externes,
emails, CRM, marketing automation…).
6.1 - Product marketing manager

Le product marketing manager (PMM) est un rôle récent en France, mais de plus en plus
fréquent dans les organisations produit, en particulier B2B SaaS. Il est situé à
l’intersection entre le produit, le marketing et la vente :
● Le PMM est familier avec les théories et pratiques propres au product

management. Il comprend le cycle de conception du produit et l’importance de
placer la valeur client et business au centre de ce cycle. Il est également à l’aise
avec les produits digitaux.
● Le PMM est un expert du marketing. Il est l’expert de son marché et de ses
clients. Il est en veille permanente sur la concurrence et les tendances de
marché. Il maîtrise les concepts et techniques propres au branding et aux canaux
d’acquisition et de conversion.
● Le PMM connaît les canaux de vente du produit. Dans un business reposant sur
des équipes Sales, il connaît leurs forces et leurs limites. Il agit comme un
65
/
facilitateur pour les vendeurs et les équipes customer success en les formant
sur le positionnement et le message produit et en leur fournissant des outils
d’aide à la vente.
Le PMM à l’intersection du produit, des ventes et du marketing
“Product marketers are the people responsible for being

able to deeply understand and therefore articulate what is
different and better and remarkable about your offering.” -
April Dunford39
Le rôle du PMM dépend énormément du type d’entreprise, du type de produit qu’elle

commercialise, de sa taille, de la présence ou non d’autres marketers, et du rôle de
l’équipe produit.
La Product Marketing Alliance définit le PMM autour de 5 grands pôles :
● Discover : connaissance des clients et prospects, connaissance de la

concurrence et des marchés cibles, win-loss analysis...
● Strategize : objectifs business, politique de prix, stratégie de go-to-market,
acquisition et rétention, sales enablement...
● Define : positionnement marché du produit, messaging, segmentation clients...
● Get Set : accompagnement des ventes et customer success, actions marketing
● Grow : analyse et optimisation
39
Product marketing. Product Marketing Alliance.
https://productmarketingalliance.com/product-marketing/
66
/
Le framework du Product Marketing, par la PMA40
Dans les équipes marketing, les PMM sont les spécialistes du produit. D’autres
personnes peuvent être responsables de la stratégie de marque, de l’acquisition de
clients en inbound marketing, de la mesure de la performance… Lorsqu’il y a plusieurs
product marketers dans une organisation, ils se répartissent certaines tâches
transverses, et sont chacun les interlocuteurs de quelques équipes produit.
Product Marketing Manager et Product Manager

PMM et Product Manager sont interdépendants, ils fonctionnent en binôme : chacun
se nourrit de l’expertise de l’autre pour livrer les meilleures solutions aux problèmes les
plus pertinents pour le client et les distribuer de la meilleure façon en accord avec le
business model de l’entreprise.
Le product marketing manager est orienté vers l’extérieur, il est à la fois expert du
client, du marché et du business. Il est également le leader de la stratégie de
40
Product Marketing Alliance. https://productmarketingalliance.com/
67
/
go-to-market. Dans une organisation intégrant des PMM, le PM est lui concentré sur
l’interne, sur la réalisation du bon produit, toujours dans une optique de livrer de la
valeur aux utilisateurs en ligne avec la stratégie business. Pour les produits en début de
cycle, les deux profils jouent un rôle important dans la quête du product/market fit.
La responsabilité des rôles entre PMM et product manager varie d’une organisation à
l’autre. Il est important de bien définir les limites de responsabilité. Même si les deux
travaillent souvent ensemble sur une partie des sujets, les interlocuteurs internes
doivent savoir qui a le lead, et est à même de prendre les décisions. Voici un tableau
avec quelques exemples de partage de responsabilités entre PMM et PM
Product Marketing Manager Product Manager
Orienté vers l’extérieur Orienté vers l’intérieur
Expert du marché et des clients Expert des utilisateurs et du produit
Responsable de la stratégie de Responsable de la stratégie produit

go-to-market et de la stratégie de prix
Utilise la roadmap produit pour Responsable de la roadmap produit

construire son plan de go-to-market.
Influence la roadmap produit.
Interlocuteur privilégié des équipes Interlocuteur privilégié des équipes tech

marketing, vente et customer success et design
Responsable des KPI marketing Responsable de KPI produit
Collecte le feedback client et le transmet Utilise le feedback client pour améliorer

aux équipes produit le produit
Identifie des opportunités d’amélioration Identifie des opportunités d’amélioration

(initiatives produit) (initiatives produit), les challenge et valide
celles qui sont pertinentes.
Responsable de la recherche clients (qui Responsable de la validation ou de

ils sont, quels problèmes), l’invalidation des hypothèses, notamment
accompagnement des phases de bêta via des tests utilisateurs
Responsable des campagnes marketing, Responsable de délivrer le bon produit

de l’inbound marketing (parfois réalisé avec la meilleure expérience et les
par d’autres marketers) fonctionnalités les plus pertinentes
Responsable de l’onboarding produit Responsable de l’expérience produit
Responsable de la communication au Responsable de la communication à

client en dehors du produit : newsletters, l’utilisateur au sein du produit : messages
articles de blogs, annonces produit, in-app, emails transactionnels...
engagement…
68
/
Le product marketing manager intervient à la fois au début et à la fin du cycle de

conception des initiatives produit :
● En amont des évolutions produit, il est chargé de parfaire sa connaissance du

marché et du client et d’identifier ses principaux problèmes, traduites en
opportunités produit. Il apporte son expertise au product manager.
● Le PMM et le PM identifient ensemble les initiatives produit les plus pertinentes,
et mènent le début du discovery.
● Une fois les bonnes initiatives identifiées, le product manager et sa squad
identifient les bonnes options pour répondre au problème, et réalisent la
première version du produit livrée au client.
● Pendant le développement du produit, le PMM peut intervenir sur le contenu
interne au produit, notamment en alignant les messages avec le tone-of-voice
défini pour le produit.
● Le PMM reprend le leadership sur le plan de commercialisation (go-to-market
plan) et la relation avec les équipes de vente.
● Le PMM accompagne le PM dans les phases de bêta quand elles existent. Dans
tous les cas, il est chargé de cascader les retours clients (la feedback loop) aux
squads pour améliorer le produit.
● Enfin il est responsable du monitoring des objectifs business et la
communication aux équipes produit et aux stakeholders de l’évolution des KPI.
Le PMM dans les organisations B2B

Le rôle du product marketing manager est particulièrement pertinent dans les
entreprises B2B, notamment pour les produits SaaS, d’autant plus quand le modèle de
distribution passe par des équipes de vente et customer success. Le PMM définit le
positionnement produit sur le marché par rapport à la concurrence, forme les
vendeurs sur le pitch et les grandes caractéristiques du produit, définit en amont le
messaging produit (nom des fonctionnalités…) et fournit des outils marketing d’aide
à la vente. Il fournit également aux équipes Customer Success des outils pour favoriser
l’upsell ou le cross-sell. Le PMM est notamment responsable de toutes les actions
marketing orientées produit qui vont intervenir en fin de parcours d’achat : démo
produit, participation à des évènements, présentations commerciales, vidéos de
promotion, articles de blog, pages web webinars, customer advocacy…
69
/
”50% de mon métier de product marketing manager est axé

produit : travailler avec les product managers pour les
accompagner dans les décisions liées à la conception de
nouvelles fonctionnalités et préparer le lancement de
celles-ci pendant qu'elles sont construites. Les aider à répondre à des
questions essentielles comme "Pourquoi décidons nous d'investir du
temps et de l'argent pour créer cette fonctionnalité ? Est-ce pour
répondre à un besoin sur un marché spécifique ? Est-ce que ça
augmentera la satisfaction de nos clients pour mieux les fidéliser ?
Est-ce que ça va enrichir notre offre qui sera de plus en plus complète ?
Une fois la fonctionnalité développée, mon métier consiste aussi à
m'assurer de bien le communiquer en interne à nos équipes, à nos
clients, et en externe. Les autres 50% sont sur des thématiques
commerciales au sens large (enablement) : créer avec l'équipe design
les outils d'aide à la vente. J'accompagne donc les équipes sales et
customer success en tant qu'experte produit pour qu'ils puissent
vendre Spendesk de la meilleure manière. ” - Chloé Lecerf, PMM chez
Spendesk
Pour les produits B2B, les personnes responsables de l’acquisition des produits sont
généralement distinctes de celles qui l’utilisent. De nombreux rôles peuvent intervenir
dans le processus d’achat. La décision d’acquérir repose sur des critères hétérogènes,
rationnels et émotionnels. Le cabinet de consulting Bain a déterminé 40 critères de
valeur (cf. ci-dessous), classés des plus basiques aux plus complexes, sur le modèle de
la pyramide des besoins de Maslow.
1. Des critères de bases à savoir la conformité aux spécifications, le prix, la

conformité réglementaire et les standards éthiques
2. La valeur fonctionnelle du produit, comme sa qualité technique, sa scalabilité
ou sa capacité à réduire les coûts.
3. La perception d’une certaine facilité à faire du business, comme l’amélioration
de la productivité, la relation avec le vendeur ou des aspects stratégiques
4. Une valeur propre à l’individu amené à faire le choix : la perception d’une
influence positive sur sa carrière, son développement personnel, l’amélioration
de son réseau professionnel ou un aspect “fun”.
5. Enfin une valeur émotionnelle inspirante, une quête de sens, l’adhésion à une
vision ou la suggestion d’un espoir.
70
/
Les éléments de valeurs B2B - Bain & Company41
Pour ces produits B2B, le PMM doit être l’expert du client et de l’acheteur, là où le
product manager et le product designer seront les experts de l’utilisateur. Les rôles
intervenant dans le processus d’achat sont souvent conceptualisés par les PMM sous
forme de buyer personas, représentation archétypale des différentes personnes
susceptibles d’intervenir dans le processus d’achat. Ces buyer personas peuvent être
par exemple :
● Un directeur exécutif, membre du Comex ou du Codir de l’organisation, chargé

de la ligne business concernée par le produit (marketing, vente, finance, RH,
opérations…)
● Différentes couches de management intermédiaire dans l’entité business
concernée
● Le directeur informatique de l’organisation, CTO ou CIO, ainsi que les couches de
management intermédiaire IT concernées
41
ALMQUIST, Eric, CLEGHORN, Jamie & SHERER, Lori. The B2B Elements of Value. March 2018.
https://hbr.org/2018/03/the-b2b-elements-of-value
Accessible en version interactive ici :
https://www.bain.com/insights/explore-the-b2b-elements-of-value-interactive/
71
/
● Des experts techniques (sécurité, architecture…) qui peuvent fortement guider le

choix d’une solution intégrée au système d’information
● Le responsable projet, en charge de déployer le produit en interne
● Les opérationnels, utilisateurs finaux du produit, qui correspondent
généralement aux user personas du PM
● Les éventuels acheteurs de l’entreprise, qui pilotent notamment les appels
d’offre
● Un contributeur individuel, qui pourrait utiliser la version gratuite d’un produit
ayant un business model freemium, et éventuellement convertir d’autres
personnes dans son entreprise
Les buyer personas permettent au PMM d’identifier les organisations les plus
susceptibles d’acheter le produit, en ne se reposant pas que sur les besoins
fonctionnels et techniques mais également sur les attentes des individus
responsables des décisions d’achat. Ces buyer personas sont critiques dans la
stratégie d’inbound marketing, et servent également à guider les efforts de vente. Les
éléments suivants sont intéressants à identifier pour un buyer persona :
● Le type d’entreprise (taille, secteur d’activité…)

● Son rôle dans l’entreprise, ses responsabilités, ses compétences, les outils qu’il
utilise...
● Ses objectifs, ce qui le motive, comment il se situe à moyen et long terme...
● Ses problèmes dans la réalisation de son travail
● Ses sources d’information, susceptibles de l’influencer : réseaux, publications en
ligne et hors ligne…
● Son mode d’achat professionnel : recours à des appels d'offres, contact avec les
équipes de vente, comment il identifie des fournisseurs potentiels…
● Son rôle dans le processus d’achat
● Ses freins à la procédure d’achat, voire points de blocage (notamment pour
identifier ceux qui n’achèteront pas, car il sont hors budget, ou ont déjà choisi
une autre solution et viennent prendre de bonnes idées)
● Les critères qu’il valorise, consciemment ou non, lorsqu’il recherche un produit
numérique, en utilisant par exemple la pyramide de Bain.
72
/
Exemple de persona VP Marketing42
Focus sur le go-to-market

La stratégie de go-to-market, stratégie de commercialisation en bon français, est
l’ensemble des actions et des informations nécessaires au lancement, à la promotion et
à la commercialisation d’un produit. Le meilleur produit ne fonctionnera jamais si
personne ne le connaît. Le bouche-à-oreille ne suffit pas et le buzz ne se décrète pas. Il
faut définir un plan d’action pour que les utilisateurs entendent parler du produit, s’y
intéressent et, dans le cas d’un produit B2B en particulier, l’achètent. Peu importe que
cette stratégie passe par des moyens “traditionnels” (display, search, presse…) ou par de
l’inbound marketing (partenariats de contenu, blogs, influenceurs…)
A quel moment créer un go-to-market plan ? Au premier lancement du produit bien sûr,
mais aussi à chaque lancement dans un nouveau marché : nouvelle zone géographique,
nouvelle verticale, etc. Et à chaque version majeure du produit, à chaque lancement de
grande fonctionnalité.
Le plan de go-to-market doit notamment contenir les éléments suivants :
● les buyer personas qui vont être ciblés

● la politique de prix
● les canaux d’acquisition pour chaque buyer persona
● le parcours d’achat des personas
● le message associé au produit, la proposition de valeur
● les plans de campagne marketing et le plan média
● la formation des équipes de vente et support client
● les KPI de succès du plan
42
Buyer Persona Example. Buyer Persona Institute.
https://www.buyerpersona.com/buyer-persona-example
73
/
● le budget et les ressources pour le lancement
En cas de mise à jour d’un outil SaaS par exemple, le PMM doit également prévoir
d’accompagner les clients en cas de mise à jour technique nécessaire (mettre à jour son
intégration avec d’autres outils par exemple) et assister les PM dans les phases de bêta
(test de la future version du produit par des clients).
6.2 - L’intégration du marketing aux squads
Au cours d’un webinar organisé par Maestro43, Alexia Boulot,

ancienne Head of Product des interfaces client de Veepee, et
Laure Helary ex-Directrice User Engagement de Veepee
expliquent comment elles ont réussi à avoir d’excellents
résultats en intégrant les équipes marketing et produit en charge de l’engagement
utilisateur au sein d’une même équipe.
Les équipes produit de Veepee sont découpées en fonction du parcours utilisateur dans
l’application : User Engagement, Navigation, Sales, Orderpipe, Post-Sales… Au sein de
cette organisation, l’équipe User Engagement est chargée de l’onboarding du prospect
pour le transformer en client. Côté marketing, une autre équipe User Engagement d’un
point de vue business est chargée de la génération de trafic via divers canaux
d’acquisition payants ou non et du CRM, sur la partie activation. Ces deux équipes ont
été fusionnées en quelque sorte, en formant une squad unique, avec le renfort d’un
data analyst dédié, chaque membre de l’équipe continuant à rapporter à son manager
business, produit, tech ou data.
business, produit et data au sein d’une seul équipe d’acquisition chez Veepee
43
BIGNON, Annabelle. Intervention d'Alexia Boulot et Laure Helary ex-@Veepee sur le framework
Product x Business. Youtube : 22 juillet 2020. [vidéo]
https://www.youtube.com/watch?v=f0St9R5Dgzg
74
/
Quelles ont été les clés du succès pour mener cette transformation ?
● D’abord, donner des objectifs communs aux équipes business et produit, en

l’occurrence 1,2 million de first time buyers par an. Tous les membres de l’équipe
sont co-responsables de l’atteinte de ces objectifs. Lors de la présentation des
résultats au Comex, l’équipe entière est invitée à participer, à répondre aux
questions sur les éventuels problèmes et à célébrer les succès en cas d’atteinte
des objectifs.
● Assurer une complémentarité des profils, des rôles et des personnalités pour
que les membres de l’équipe se nourrissent des apports des autres. Développer
un esprit d’empathie, afin que chaque membre de la squad comprenne les
enjeux de chacun. Les responsabilités sont ensuite définies en fonction des
forces et des faiblesses de chaque profil.
● Donner de l’autonomie à l’équipe pour la prise de décision. En donnant des
objectifs communs à tous, en favorisant la discussion et en fournissant des
données objectives sur les problèmes, les désaccords disparaissent et les
décisions finissent par se faire au consensus.
● Co-localiser les équipes (product, réalisation, business, data) pour favoriser les
échanges et le sentiment d’appartenance à une équipe commune.
● Mettre en place une organisation matricielle avec un leadership quadripartite
vertical par produit (product, marketing, tech et design), et un leadership
horizontal sur les pratiques techniques IT et business (par technologie, sur la
data...)
● Formaliser des rituels communs aux équipes produits et business, pour
recevoir des feedbacks clients, échanger sur les données, co-construire les
fonctionnalités, démontrer les réalisations ou proposer des améliorations dans
les processus.
● Favoriser le lien entre les membres de l’équipe, en incitant à la tenue
d’évènements (afterworks...) ou de rituels informels (café du matin), voire en
organisant des évènements de team building.
● Parier sur la confiance : confiance des membres de la squad entre eux, grâce à
l’empathie entre les membres et les liens qui se créent entre eux, et confiance du
management dans ce que les équipes vont produire. La confiance se gagne, mais
il faut partir du postulat qu’elle va s’instaurer.
● Enfin, ce modèle fonctionne particulièrement bien s'il existe une équipe business
unique en ligne avec la structuration de l’équipe produit. Si les partie-prenantes
business sont éparpillées dans l’organisation, il est beaucoup plus compliqué de
mettre en place ce modèle.
75
/
III - La stratégie produit
Partie III
La stratégie produit
La stratégie produit est l’ensemble des éléments qui vont guider le cycle de vie du
produit à moyen et long terme. Il s’agit d’un plan macro, qui décrit ce vers quoi le
produit doit tendre.
La stratégie peut généralement être découpée en 3 niveaux :
● La vision produit, qui définit un horizon à long terme pour le produit. La vision
est un guide qui doit être à l’esprit de toutes les parties prenantes à tous les
stades du développement du produit.
● Les objectifs stratégiques, et les KPI associés, qui donnent des jalons
mesurables à moyen et long terme, afin d’atteindre la vision.
● La roadmap, qui donne une vision ordonnancée des différentes priorités sur
lesquelles les équipes produit travaillent à court et moyen termes.
La construction d’une stratégie efficace est un processus long, qui ne se résout pas en
quelques workshops. Elle demande de parfaitement comprendre ses utilisateurs, sa
cible ; de connaître le marché et la concurrence ; d’être familier avec le business model
de l’entreprise. Elle est faite d’allers retours entre d’un côté les opérationnels, les
product managers, designers, researchers et strategists qui vont acquérir la
connaissance client et marché et valider les idées auprès des cibles, et d’un autre côté le
top management qui définit les grandes lignes, les grands objectifs et la stratégie
business qui vont guider les équipes.
76
/
La stratégie produit évolue dans le temps : si la vision doit être solide et ne pas changer
pendant plusieurs années, les objectifs sont régulièrement challengés et de nouveaux
objectifs peuvent apparaître. Quant à la roadmap, elle est mise à jour très
régulièrement au gré des urgences, des nouveaux problèmes et nouvelles opportunités
identifiés.
La stratégie doit être lisible de tous, communiquée à toutes les équipes produit et aux
parties prenantes, aux investisseurs et potentiellement également aux clients. Elle
permet d’engager toutes les forces vers la même direction, créer de l’enthousiasme. Le
feedback que les investisseurs et les clients pourraient fournir peut également être une
source d’inspiration importante.
77
/
1 - La vision produit
Toute bonne stratégie produit démarre par une vision, un horizon clair vers lequel le
produit doit tendre, son but global à long terme.
En amont de la vision produit, la vision de l’entreprise détermine le but global à long

terme de l’entreprise, sa raison d’être. Elle donne le cap pour toutes ses activités, le
développement des produits donc, mais également les ventes, la finance, les services
clients, la communication et la marque, etc.
Dans une startup ou une entreprise mono-produit, cette vision d’entreprise suffit
généralement. Lorsque l’entreprise dispose de plusieurs lignes produits distinctes, ou
que le produit ne constitue qu’un pan de l’activité de l’entreprise, il est utile de définir
une vision pour chacun de ces produits : quel objectif le produit doit atteindre et
comment se positionne-t-il de façon originale dans la vision globale de l’entreprise ?
La Scrum Alliance décrit ainsi la vision produit : “La vision produit doit décrire un but
global et engageant : un but qui guide les efforts de développement mais laisse
suffisamment de place à la créativité ; un but qui engage et qui inspire les gens, qui
encourage la créativité et qui génère de l’adhésion.”44
La vision fonctionne comme une “North Star” (étoile polaire) : un but global à atteindre
pour l’organisation produit, qui permet d’avoir une base de compréhension commune à
toutes les équipes, sur ce qu’elles doivent accomplir ensemble. En ayant une vision long
terme de ce qu’elles doivent accomplir, les équipes peuvent anticiper des
investissements à long terme, comme des choix d’architecture ou de hardware coûteux,
pour servir au mieux les besoins auxquels ils doivent répondre. Elle servira également
de base pour définir le découpage des équipes produit.
Une vision réfléchie et bien rédigée est un outil de communication incroyablement

efficace. Elle permet d’inspirer et de motiver les équipes en leur donnant le sentiment
de travailler sur quelque chose qui a du sens, à la réalisation d’un produit hors du
commun qui doit améliorer voire révolutionner la vie de ses utilisateurs. Elle permet au
client et aux prospects de comprendre la raison d’être de l’entreprise ou du produit,
ainsi que le bénéfice qu’ils peuvent en attendre. Elle permet également d’inspirer et de
convaincre les différentes parties prenantes de l'entreprise, les partenaires et les
investisseurs. Une bonne vision doit être ambitieuse et inspirante. Elle doit donner
envie aux membres de l’organisation d’y adhérer.
Une vision percutante est aussi un outil de recrutement particulièrement utile,

notamment pour attirer des talents au sein des équipes produit. Elle permet aux
44
“The product vision should describe a broad and engaging goal: a goal that guides the
development effort but leaves enough room for creativity; a goal that engages and inspires
people, fosters creativity, and generates buy-in.”
SCRUM ALLIANCE, The Product Vision. Janvier 2009.
https://www.scrumalliance.org/community/articles/2009/january/the-product-vision
78
/
candidats de se projeter dans un futur professionnel qui a du sens, et de comprendre

quel impact leur travail aura. Elle permet de s’identifier à l’entreprise. Elle est d’ailleurs
souvent mise en avant sur les sites de recrutement des entreprises orientées produit.
Julie Knibbe, ancienne Head of Product Strategy chez Deezer, explique pourquoi il est
important d’avoir une vision produit45 :
● Fail fast : Les organisations tentent de nombreuses choses pour améliorer leur
produit, et elles ont besoin d’identifier rapidement ce qui ne fonctionne pas. Une
bonne vision sert de cap pour échouer rapidement et retenir ce qui marche.
● Les pivots, changements de positionnement produit, coûtent cher, sont un
frein à l’optimisation et créent de la confusion chez l’utilisateur. Une vision
pertinente donne une direction pour plusieurs années.
● Vouloir résoudre les problèmes des utilisateurs génère de l’innovation
technologique. La vision doit refléter les problèmes principaux que le produit
doit résoudre.
● Les employés ont besoin d’une raison (purpose). Plus la vision de l’entreprise est
claire et engageante, plus ils ont envie de se lever le matin pour y parvenir.
Elle définit ainsi la vision produit de Deezer :
“Deezer is the link between you and the music that

moves you. We listen to the beat of your heart and help
you find the songs that match it.”
1.1 - Construire sa vision produit

Construire une vision produit est un processus long. Une phase d’étude préalable de
découverte produit - ou product discovery - est nécessaire pour valider les hypothèses et
être confiant dans la pertinence de la vision, menant au succès de l’entreprise en cas de
réalisation. Elle est nourrie par la stratégie business (comment l’entreprise fait de
l’argent), les feedbacks utilisateurs et la créativité des équipes.
Parfois, cette vision est donnée par un leader visionnaire. C’est souvent le cas dans une
startup early stage où les équipes exécutent la vision d’un des fondateurs. Parfois, cet
état d’esprit perdure lorsque l’entreprise grandit. On peut penser à Elon Musk avec
Tesla, SpaceX et Neuralink, ou à Steve Jobs et Apple. Mais la vision produit est
pratiquement toujours alimentée par la créativité des équipes en amont. L’entreprise ne
peut se reposer que sur les coups de génie de son leader visionnaire. Depuis la mort de
Steve Jobs, Apple n’est plus une entreprise aussi innovante. Ses produits sont sans
cesse perfectionnés et sa base d’utilisateurs conquis lui permet d’être la première
capitalisation boursière au monde devant les 4 autres GAFAM. Mais Apple, longtemps
45
KNIBBE, Julie, Do we need a vision?. 8 décembre 2016.
https://deezer.io/do-we-need-a-vision-847592dad002
79
/
dans le top 5 des entreprises les plus innovantes du monde, est maintenant à la 39e
place d’après Fast Company46, loin derrière Snapchat, Microsoft ou Tesla.
Marty Cagan expose 10 principes pour une vision produit :
46
The World’s 50 most innovative companies. Fast Company.
https://www.fastcompany.com/most-innovative-companies/2020
80
/
Revenons sur deux de ces principes :
Commencer par pourquoi :
“Les gens n’achètent pas ce que vous faites, mais pourquoi

vous le faites”. Simon Sinek47
Un produit extrêmement bien réalisé ne fonctionnera pas s’il n’a pas une raison d’être
claire. Avant de créer un produit, il faut clairement définir le problème qu’il cherche à
résoudre, et la raison pour laquelle on choisit une façon de le résoudre. L’organisation
qui prétend résoudre un problème doit le faire avec des convictions affichées. C’est en
jouant sur les émotions et les convictions que l’organisation pourra attirer les early
adopters, sa base d’utilisateurs fidèles qui lui permettront de démarrer et de grandir. Ce
principe est intimement lié à la génération d’outcomes comme moteur du product
management.
Être têtu sur la vision, mais flexible sur les détails :
“We are stubborn on vision. We are flexible on details…. We

don’t give up on things easily.” - Jeff Bezos48
Une bonne vision est construite sur le long terme et sur des expérimentations
préalables ayant permis de la valider. Dès lors, en cas de doute ou d’échec dans la mise
en œuvre de cette vision, les équipes doivent rester confiantes et garder le cap. Les
changements de stratégie sont acceptables mais pas les pivots de vision. Par contre, les
équipes produits doivent être suffisamment flexibles pour être capable de changer les
détails dans la réalisation de cette vision. C’est même un des objectifs du product
discovery.
Une excellente vision produit est nourrie de 4 éléments principaux :
● Une appropriation des principes du business de l’entreprise : sa mission, son

modèle économique et ses objectifs.
● Une compréhension intime des utilisateurs, de leurs besoins profonds, qui
permettent de définir quel est le grand problème auquel le produit doit
répondre, le “why”.
47
SINEK Simon, How great leaders inspire action. Ted : septembre 2009. [vidéo]
https://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action
48
“Nous sommes têtus sur la vision. Nous sommes flexibles sur les détails… Nous ne renonçons
pas facilement”.
GREATHOUSE, John. 5 Time-Tested Success Tips From Amazon Founder Jeff Bezos. In Forbes. 30 avril
2013.
https://www.forbes.com/sites/johngreathouse/2013/04/30/5-time-tested-success-tips-from-amaz
on-founder-jeff-bezos/
81
/
● Une excellente connaissance du marché sur lequel se positionne le produit : la

concurrence, les tendances pour les années à venir, les innovations
technologiques, afin de construire une vision durable, qui permet de positionner
l’entreprise à la pointe de son marché plutôt qu’en tant que suiveur.
● Les principaux facteurs différenciants du produit, ce qui permet de lui donner
un avantage compétitif par rapport à la concurrence et convaincre les
utilisateurs de le choisir lui plutôt qu’un autre.
Voici quelques questions qui peuvent permettre de définir la vision de l’organisation :
● Pourquoi votre organisation/équipe existe-t-elle ?

● Qu’est ce qui inspire tout le monde pour venir travailler chaque jour ?
● Quel est votre business model ?
● Qui sont vos clients, que pensent-ils de vous ?
● Qu’attendez-vous de vos employés quand ils viennent travailler ?
● Qui sont vos concurrents ?
Le value proposition template

Geoffrey Moore propose49 un modèle d’elevator pitch qui peut être utile pour
commencer à formaliser la vision produit : le value proposition template.
Pour [client] qui [besoin/opportunité], notre [produit] est [catégorie de

produit] qui [bénéfice].
Par exemple : Pour les consommateurs qui sont soucieux de l’impact sur leur santé des
produits qu’ils consomment, Yuka est une application mobile qui fournit des
informations sur la qualité des ingrédients du produit simplement en scannant son
étiquette.
Le Golden Circle de Simon Sinek

Simon Sinek50, conférencier et auteur du livre Commencer par le pourquoi, propose de
formuler la proposition de valeur d’un produit ou d’une entreprise en commençant par
sa raison d’être, avant d’expliquer comment ils font quelque chose, puis en finissant par
ce qu’ils font.
49
MOORE, Geoffrey A. Crossing the chasm : marketing and selling disruptive products to mainstream
customers.
50
SINEK Simon, How great leaders inspire action. Ted : septembre 2009. [vidéo]
https://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action
82
/
Il prend l’exemple d’Apple, en formulant leur proposition de valeur de cette façon :
“Dans tout ce que nous faisons, nous croyons à la remise en cause du statu
quo, nous croyons en une manière différente de penser. [pourquoi ?]
Nous remettons en cause le statu quo en rendant nos produits
magnifiquement designés, simples à utiliser et conviviaux. [comment ?]
Il se trouve que nous faisons des ordinateurs formidables. [quoi]”
En commençant par l’objectif, la mission, les croyances de l’organisation, le message est

beaucoup plus inspirant.
1.2 - L’énoncé de mission

La vision ne doit pas être confondue avec l'énoncé de mission (mission statement en
anglais) de l’entreprise. La mission est la raison d’être de l’entreprise, souvent formulée
sous forme de slogan. Elle définit ce qu’est l’entreprise à très long terme, elle définit ce
qu’elle fait. Il s’agit d’un but audacieux, paraissant presque inatteignable, ce que Jim
Collins définit comme “BHAG” (big hairy audacious goal)51. La mission a un objectif
différent : elle décrit pourquoi l’entreprise veut atteindre cet objectif, et elle donne des
pistes sur comment y parvenir. Comme l’explique Richard Banfield52, la mission est la
montagne à gravir, et la vision décrit pourquoi et comment la gravir.
Exemples de missions :
51
COLLINS, Jim. BHAG – big hairy audacious goal. Extrait de Built to Last, 1994.
https://www.jimcollins.com/article_topics/articles/BHAG.html
52
BANFIELD, Richard, Why Your Product Vision Might Be More Critical Than Your Company
Mission. 17 avril 2018.
https://medium.com/the-heroic/why-your-product-vision-might-be-more-critical-than-your-comp
any-mission-ac29dc44e15c
83
/
Make People Happy.
Notre objectif est d'organiser les informations à l'échelle mondiale pour les
rendre accessibles et utiles à tous. 53
Donner à tous la possibilité de créer une communauté et de rapprocher le
monde entier. 54
We strive to offer our customers the lowest possible prices, the best
available selection, and the utmost convenience
“Become #1 or #2 in every market we serve and revolutionize this

company to have the speed and agility of a small enterprise.”
Nous apportons de la liberté, de l’équité et de la fraternité au monde du

voyage55
“Contribuer à transformer les cabinets et les hôpitaux pour rendre notre

système de santé plus humain, efficace et connecté.”56
Révolutionner le monde de la photographie en donnant la possibilité

aux photographes de se consacrer à leur passion57
53
https://about.google/
54
https://about.fb.com/fr/company-info/
55
https://blog.blablacar.fr/about-us
56
https://about.doctolib.fr/mission.html
57
https://www.meero.com/fr/about-us
84
/
2 - Les objectifs stratégiques

Les objectifs produit représentent les moyens d’avancer vers la réalisation de la vision,
les grandes étapes que les équipes produit doivent atteindre pour arriver à l’objectif
final. Si la vision décrit le but à atteindre, le Why, les objectifs stratégiques définissent
comment atteindre la vision, le How.
Il s’agit par exemple d’une série de product / market fits (par persona, par zones
géographiques, par verticales…), ou d’un séquencement logique (mise en place d’un
système d’avis, pour ensuite établir un système de “sentiments” à partir des données,
puis mettre en place un système de recommandations).
Gibson Biddle, ancien VP Product de Netflix, explique quelles étaient les étapes de leur
stratégie dans les années 200058. Elle tenait en 3 points : 1. Devenir géant sur les DVD 2.
Être leader sur le marché du streaming 3. S’étendre dans le monde entier.
Ces objectifs intermédiaires permettent aux équipes produit de garder le focus sur une
mission, d’être alignées sur un objectif commun. Elles vont se concentrer sur le
lancement du plus petit livrable possible pour atteindre une étape avant de passer à
l’étape suivante. Les idées complémentaires, qui ne correspondent pas aux objectifs,
seront prises en compte plus tard.
Marty Cagan établit 5 grands principes pour construire une bonne stratégie59 :
1. Se concentrer sur un marché ou un persona à la fois. Ne pas essayer de

satisfaire tous les besoins dans chaque release. En construisant un produit
qu’une partie des utilisateurs adorent, il pourra aussi être utile à d’autres.
2. Aligner la stratégie produit avec la stratégie business. Prendre en compte le
business model et la stratégie de monétisation de l’entreprise pour construire le
produit.
3. Aligner la stratégie produit avec la stratégie de vente et le go-to-market. Si
un nouveau canal marketing est priorisé, les objectifs produit doivent être
adaptés.
4. Être obsédé par les consommateurs, pas la concurrence. Les clients ne vous
quittent pas pour la concurrence, ils vous quittent parce que vous arrêtez de
vous occuper d’eux, parce que votre produit ne répond plus à leurs problèmes.
5. Communiquer la stratégie au sein de l’organisation. Tous les stakeholders
clés doivent connaître les clients et marchés sur lesquels l’équipe produit
travaille actuellement, et ceux qui sont priorisés ensuite.
58
BIDDLE, Gibson. How to Run a Quarterly Product Strategy Meeting: A Board Meeting for
Product. 21 juin 2017.
https://medium.com/@gibsonbiddle/how-to-run-a-quarterly-product-strategy-meeting-a-board-
meeting-for-product-3a14c4d53d1b
59
CAGAN, Marty. Inspired, chap. 26 : Principles of Product Strategy.
85
/
Les auteurs de Product Roadmap Relaunched estiment que tous les objectifs business
peuvent être regroupés en 10 grandes catégories60 :
● Les objectifs liés à la pérennité du produit

○ soutenir la valeur intrinsèque du produit
○ créer une barrière à la concurrence
● Les objectifs de croissance
○ augmenter les parts de marché
○ répondre à plus de demande
○ développer de nouveaux marchés
○ améliorer les revenus récurrents
● Les objectifs de profit
○ soutenir des prix plus élevés
○ améliorer la valeur du capital client (customer lifetime value)
○ diminuer les coûts
○ exploiter des actifs existants
Ryan Panchadsaram conseille61 de se poser les 5 questions suivantes lors de la

formulation des objectifs :
● Demandez-vous quelque chose d’incrémental, un saut, ou une découverte ?

● Vos objectifs peuvent-ils être plus spécifiques ?
● Vos objectifs peuvent-ils être plus orientés action ?
● Pouvez-vous formuler le même objectif d’une façon plus concise ?
● Pouvez-vous rendre l’objectif plus mémorable ?
2.1 - Les OKR - Objectives and Key Results

OKR est une méthode pour définir et mesurer des objectifs et les résultats qu’ils
produisent. La création des OKR est attribuée à Andy Grove, un des fondateurs d’Intel,
qui a documenté la méthode dans le livre High Output Management publié en 1983. La
méthode est notamment célèbre pour avoir été introduite chez Google par le Venture
Capitalist John Doerr, alors que Larry Page et Sergey Brin étaient à la tête d’une startup
dans un garage.
“OKRs have helped lead us to 10x growth, many times over.

They’ve helped make our crazily bold mission of “organizing
the world’s information” perhaps even achievable. They’ve
kept me and the rest of the company on time and on track
when it mattered the most.” - Larry Page62
60
LOMBARDO, C. Todd, MCCARTHY, Bruce, RYAN, Evan & CONNORS, Michael. Product Roadmaps
Relaunched. p. 75
61
What Matters. OKRs 101 - Lesson 2.4: Refining Your Objectives - Learn how to set and achieve
audacious goals? Youtube : 8 septembre 2020 [vidéo]
https://www.youtube.com/watch?v=sdRf0N1k5_0
62
préface de DOERR, John. Measure What Matters.
86
/
La méthode OKR repose sur deux piliers :
● Des objectifs ambitieux, qui reflètent la vision de l’organisation

● Des résultats clés (Key Results), indicateurs mesurables et faciles à évaluer
permettant de suivre l’avancement d’un objectif stratégique donné.
L’idée est simple : en définissant des métriques claires pour évaluer les progrès vers un
objectif, l’organisation donne un outil qui permet aux équipes de se concentrer sur un
chemin communiqué et partagé pour atteindre cet objectif.
Les OKR sont applicables à n’importe quel projet ou niveau hiérarchique :
● A un niveau stratégique, les OKR peuvent être utilisés pour définir les objectifs
stratégiques de l’organisation, et les métriques associées. Les OKR sont définis
collectivement par les membres du comité de direction, de façon trimestrielle,
ou, au plus, annuelle.
● Les OKR sont ensuite déclinés par département, en assignant des objectifs
intermédiaires pertinents, dans la direction des OKR stratégiques.
● Les OKR sont enfin attribués par équipe au sein de chaque département. Au sein
du département produit, chaque squad a ses propres OKR qui lui permet de se
concentrer sur des objectifs actionnables. Les objectifs sont généralement
donnés à une échelle de temps plus courte que les objectifs stratégiques, au
trimestre ou au mois par exemple.
Pour aligner les OKR entre les différents niveaux organisationnels il y a 2 méthodes
principales :
● Un des KR du niveau supérieur devient un objectif du niveau inférieur. A l’équipe

de créer ces propres KR pour atteindre cet objectif.
● Le niveau inférieur crée son propre OKR comme proposition pour aider à
atteindre un des OKR du niveau supérieur.
La littérature et les retours d’expérience conseillent de se limiter à 3 à 5 objectifs par

strate, et 3 à 5 key results par objectif. Moins l’organisation ou l’équipe a d’objectifs et
de key results, plus elle sera concentrée sur leur réalisation. Les entreprises les plus
matures se contentent de 2 objectifs et 2 KR par strate.
Quelques précisions sur les OKR :
● Les objectifs doivent donner du sens, être ambitieux et inspirants, ils

doivent donner un horizon élevé aux équipes pour leur donner envie de se
surpasser.
● Les objectifs représentent les choses les plus importantes que l’organisation
doit faire. Ce qu’elle doit commencer à faire, ou arrêter de faire. Elles sont une
représentation de ce à quoi ressemble le succès pour l’organisation. Ils ne sont
pas faits pour évaluer les tâches récurrentes de l’organisation.
● On parle souvent de stretch goals pour les OKR, c'est-à-dire d’objectifs
pratiquement impossibles à atteindre, pour pousser les équipes à se surpasser.
Les Key Results ne doivent pas nécessairement être atteints à 100% dans le
87
/
temps donné pour considérer que le travail effectué est un succès. En fait, si tous
les KR sont régulièrement à 100%, les objectifs ne sont probablement pas assez
ambitieux. Les managers doivent être capables de définir le seuil à partir duquel
un objectif est considéré comme atteint (autour de 60% ou 70% des KR
généralement), tout en poussant les équipes à aller plus loin.
● Les OKR sont publics et partagés au sein de l’organisation. Chaque membre de
l’organisation doit pouvoir voir sur quoi travaille chaque équipe et quel est l’état
d’avancement des key results.
● Les OKR sont des objectifs business, pas des outputs. Les équipes concernées
par un OKR doivent être libres de définir le moyen pour atteindre cet objectif.
● L’équipe doit avoir les moyens de réaliser son OKR. Il n’est pas envisageable
d’imposer à une équipe de réaliser un objectif si elle ne dispose pas des leviers
organisationnels suffisants pour l’atteindre. Dans une organisation produit, la
création d’équipes autonomes et pluridisciplinaires est essentielle pour donner à
ces équipes les moyens de réaliser leurs objectifs.
● Les OKR ne sont pas imposés par la direction. Ils sont définis après un
échange entre les managers et les équipes concernées, qui se mettent d’accord
sur les meilleurs indicateurs à utiliser pour mesurer l’atteinte de l’objectif.
● Les meilleurs indicateurs sont des indicateurs facilement mesurables et
vérifiables, ils ne laissent pas de place à l’interprétation. Ils sont spécifiques et
limités dans le temps. Ils sont agressifs, mais réalistes.
● Les OKR doivent être revus régulièrement, sur la base de leur avancement. Si
un OKR est atteint, un nouveau peut être assigné. Si un OKR ne semble pas
atteignable, l’équipe et le management doivent collectivement se demander
pourquoi : est-ce que l’OKR est trop ambitieux ou plus pertinent ? l’équipe n’a
pas les moyens de le réaliser ? les KR sont mal définis ?
Les OKR peuvent être plus ou moins simples à atteindre. Il est d’ailleurs possible de
mélanger des OKR.
● Les committed OKR (OKR engageant) : l’organisation ou l’équipe s’engage à

atteindre 100% de ces OKR dans la période donnée. Ce sont des objectifs
essentiels à l’activité de l’organisation, qui justifient de réajuster les plannings et
les priorités, de tout faire pour les atteindre.
● Les aspirational OKR (OKR ambitieux), correspondant aux stretch goals de
Google. Ce sont des OKR à plus long terme, qui permettent à l’équipe ou à
l’organisation de se projeter dans le futur. Ces objectifs sont pratiquement
impossibles à atteindre dans la période donnée, mais poussent l’équipe à se
surpasser et tendre vers des objectifs stratégiques à long terme de
l’organisation.
● Les learning OKR (OKR d’apprentissage), grâce auxquels l’organisation ou
l’équipe cherche à valider des hypothèses et acquérir des validated learnings.
Dans une logique produit, ils peuvent servir pour donner des objectifs de
discovery comme la validation d’un prototype ou une recherche sur un nouveau
marché par exemple.
88
/
Les key results sont des indicateurs à atteindre pour parvenir à l’objectif. Ils forment
ensemble un “package” cohérent qui doit permettre d’atteindre l’objectif, ils ne sont pas
indépendants. Les KR d’un objectif peuvent être un mélange d’input, d’outputs et
d’outcomes :
● Les inputs (entrants) : ce que l’organisation peut directement contrôler. Le

problème des inputs est qu’ils imposent la solution pour atteindre un résultat, et
ne permettent pas à l’équipe d’être créative. Si les inputs choisis ne sont pas
bons, l’objectif risque de ne jamais être atteint.
○ Lancer 30 nouvelles boutiques
○ Tester 3 campagnes marketing pour renouveler l’abonnement à notre
service
○ Créer 100 nouveaux articles sur le site web
○ Pour faire élire notre candidate, frappez à la porte de 10k personnes
● Les outputs (extrants) : les effets directs des inputs. L’organisation ne les
contrôle pas directement, mais ils représentent la performance de l’input. Les KR
sous forme d’outputs permettent aux équipes d’être plus créatives sur la façon
de les atteindre.
○ Atteindre un chiffre d’affaire de 100k€ par boutique
○ Atteindre un taux de renouvellement de 63%
○ Atteindre 1M pages vues sur le site web
○ Faire en sorte que 20k personnes s’engagent à voter pour notre candidate
● Les outcomes (résultats business) : des indicateurs connectés avec la raison
d’être de l’objectif. Ils mettent généralement l’accent sur un changement entre la
situation actuelle et la situation désirée. Ils sont plus performants, plus
inspirants, mais ils sont également généralement plus compliqués à définir et à
mesurer.
○ Augmenter le chiffre d’affaire de 20%
○ Augmenter le NPS de 5 points
○ Augmenter les visites organiques sur le site de 30%
○ Augmenter de 10 points les résultats de notre candidate par rapport à la
précédente élection
Les OKR ne sont pas faits pour définir des objectifs de performance individuels en soi,
mais ils peuvent aider à l’alignement des membres d’une équipe. En alignant les
objectifs individuels de chaque membre d’une équipe sur les OKR de cette équipe,
l’organisation s’assure que tous les membres de l’équipe vont aller dans la même
direction.
89
/
3 - La roadmap produit
La roadmap est la matérialisation physique des différentes étapes de la stratégie
produit. En fonction du niveau d’abstraction et du produit, elle décrit les différents
objectifs stratégiques à une échelle de plusieurs années, ou les différentes initiatives
produits à un an par exemple.
La plupart des organisations ont l’habitude d’établir des roadmaps. Elles le font juste
d’une mauvaise manière. La plupart du temps, il s’agit d’une liste de projets, d’initiatives
et de fonctionnalités, réparties sur un planning assorties de dates de livraison
attendues. Elles ne donnent aucune information sur les objectifs réels. Les dates sont
généralement arbitraires et très souvent irréalistes. Elles imposent bien trop souvent
une pression incroyable aux équipes produits, dans l’objectif de livrer des
fonctionnalités souvent inutiles ou obsolètes avant même le démarrage des
développements.
Pourquoi faire une roadmap ? D’abord parce que le management a besoin de s’assurer
que la valeur la plus importante sera livrée en premier. Ensuite parce qu’il a besoin
d’information pour pouvoir coordonner le travail des équipes de vente et de marketing
et des éventuels partenaires avec la livraison de l’équipe produit. Les roadmaps, si elles
sont bien exécutées, restent un outil de communication très puissant aux mains des
product managers.
3.1 - Pourquoi les roadmaps traditionnelles ne fonctionnent

pas ?
La plupart des projets et des fonctionnalités déployés sont des échecs. Les causes
potentielles sont nombreuses : j’ai mentionné les risques de valeur, d’utilisabilité, de
faisabilité ou de viabilité business63. Celles qui ne sont pas des échecs nécessitent
généralement plusieurs itérations avant d’être des succès, avec un time to market
incertain. L’échec n’est pas forcément l’absence de livraison du projet. Certains projets
sont parfaitement exécutés et livrés d’un point de vue technique. Mais ils ne délivrent
tout simplement pas la valeur business escomptée : il n’y a pas de retour sur
investissement (ROI). Pire parfois, le ROI attendu n’est même pas défini avant de
démarrer le projet.
Ce type de roadmap est généralement imposé par les parties prenantes du produit :
management qui impose des fonctionnalités et des dates pour donner l’illusion de
contrôler l’organisation, engagement pris auprès d’un client en particulier...
Ces roadmaps sous forme de liste de fonctionnalités ne laissent pas la place nécessaire
au product discovery, phase pourtant nécessaire pour identifier quels sont les réels
problèmes des clients ou utilisateurs à résoudre, et quelle est la bonne réponse à
63
cf chapitre Le product management : un modèle centré sur la production de valeur business et
client
90
/
apporter. Les premiers feedbacks remettront probablement en cause une grande partie
de ce qui avait été prévu initialement, mais ces roadmaps ne permettent pas de
prendre en compte les échecs, d’apprendre et de s’améliorer.
Afin de définir une date de livraison précise, les équipes de réalisation ont besoin des
détails exacts de ce qu’elles doivent développer. Au moment où la roadmap est établie,
les fonctionnalités sont généralement au mieux décrites par quelques lignes ou un
vague mockup, les dates sont donc forcément indicatives. Elles tendent toutefois à être
considérées comme des engagements, ce qui crée fatalement des tensions. Lorsque le
planning ne peut être tenu, soit les équipes livrent en retard, soit elles coupent dans ce
qui doit être livré, en éliminant généralement une partie significative du bénéfice
attendu de la fonctionnalité.
Les roadmaps traditionnelles mènent souvent à la livraison de fonctionnalités

non pertinentes, non alignées avec l’objectif du produit et ne permettent pas aux
autres membres de l’organisation de planifier leurs tâches. C’est une recette assurée
pour l’échec.
3.2 - Une roadmap orientée outcomes

Les roadmaps sont utiles au management pour s’assurer que la plus forte valeur est
priorisée et pour pouvoir planifier. Comment faire ?
La réponse est plutôt simple : la roadmap doit être basée sur des outcomes, des
résultats attendus, plutôt que sur des outputs, des fonctionnalités ou des projets. Marty
Cagan rapporte une citation du Général Patton :
“Never tell people how to do things. Tell them what to do

and they will surprise you with their ingenuity.” - George
S. Patton
Une bonne roadmap doit indiquer le contexte business : la vision produit, et la stratégie
définie pour l’atteindre ; les objectifs business ; les KPI qui permettront de mesurer
l’atteinte de ces objectifs. A partir de là, les équipes produit peuvent prioriser des
résultats business, qui permettent d’atteindre les objectifs, plutôt que des
fonctionnalités.
Concrètement, la roadmap indiquera par exemple un objectif d’amélioration du taux de

rétention de 20% sur tel persona, ou la mise en conformité avec telle disposition
juridique, plutôt que les fonctionnalités ou évolutions qui sont supposées répondre à
ces objectifs. Charge aux équipes produits de définir de façon autonome comment
résoudre le problème posé, de la façon la plus simple et la plus rapide possible.
Le product manager est responsable de la roadmap

Un des principes de base du product management est de constituer des équipes
autonomes pour atteindre les objectifs stratégiques donnés par l’organisation dans le
91
/
but d’atteindre la vision produit. Le product manager est responsable de l’atteinte

de ces objectifs.
Dans une organisation orientée produit, créer la roadmap est un travail collaboratif et
itératif entre le management et les product managers :
● Le management donne les objectifs stratégiques aux équipes produits, et si

besoin l’ordre de priorité de ces objectifs stratégiques. Ce sont des objectifs
business, délivrant une valeur business, et non des fonctionnalités.
● Le product manager définit les étapes pour atteindre ces objectifs. C’est à lui
de prioriser les initiatives qu’il veut explorer et délivrer. Finalement, c’est lui qui
construit la roadmap. Si l’organisation utilise des OKR, ces initiatives doivent être
alignées avec les key results de l’équipe.
Bien sûr, le product manager ne décide pas arbitrairement des initiatives, et ne les
impose pas à l’organisation et au management. Il doit être capable de justifier ses
choix, présenter des données factuelles qui le poussent à prioriser telle initiative plutôt
qu’une autre. Les roadmaps sont généralement validées par le management à intervalle
régulier. En cas de désaccord, le management ne doit pas imposer de prioriser telle ou
telle initiative, mais demander au PM de revoir sa copie sur la base d’éléments justifiant
cette revue de roadmap (par exemple des contraintes externes que le PM n’aurait pas
suffisamment prises en compte, qui justifient d’avancer une initiative ou d’en reculer
une autre).
Lorsque plusieurs équipes produit interviennent sur un même produit, la roadmap

présentée est généralement une consolidation des initiatives de chaque équipe. La
consolidation est généralement faite par le Head of Product concerné, mais son rôle
n’est pas de prioriser cette roadmap consolidée : il s’assure que toutes les équipes
produit fournissent une roadmap cohérente, et que les éventuelles dépendances entre
les équipes sont gérées correctement dans la roadmap. Il challenge les équipes produit,
mais ne leur impose pas de priorités.
Prendre un engagement de date dans une roadmap orientée

outcome
La plupart des dates imposées dans les roadmaps n’ont pas de réel intérêt business.
Elles ont soit pour objectif de rassurer le management en leur donnant l’impression
qu’ils contrôlent ce qu’il se passe (même si au final elles ne sont pas tenues, ou si elles le
sont, les développements ne répondent pas au vrai problème), soit sont contraintes par
des processus budgétaires annuels incompatibles avec une réelle démarche produit.
Il arrive parfois que des dates soient vraiment nécessaires : contrainte juridique,
évènement de lancement produit par exemple. La meilleure façon d’y répondre est
grâce à ce que Marty Cagan appelle les engagements à haute intégrité (high integrity
commitments)64. Ils se déroulent en 5 étapes :
64
CAGAN, Marty. High-Integrity Commitments. 15 juillet 2012.
https://svpg.com/managing-commitments-in-an-agile-team/
92
/
1. Une demande business arrive, assortie d’une contrainte de date (soit le business
a besoin de connaître la date de résolution du problème, soit une contrainte
forte impose de le résoudre avant telle date).
2. L’équipe produit mène une phase de découverte (product discovery) sur le
problème, afin de déterminer la bonne réponse à y apporter. Elle valide la valeur
business et utilisateur de la solution, l’utilisabilité de la réponse et la faisabilité
technique.
3. Une fois cette phase de discovery effectuée, l’équipe peut prendre un
engagement informé et ferme, à la fois sur la date et sur le résultat qu’elle
compte livrer. En cas de date contrainte, des ressources supplémentaires
peuvent éventuellement être engagées.
4. La demande business est ensuite priorisée sur la roadmap et mise en phase de
développement (build)
5. Enfin les développements sont livrés en production (delivery) à la date prévue, le
problème est résolu.
Les éléments d’une roadmap orientée outcome

Les auteurs de Product Roadmaps Relaunched65 donnent une liste des éléments
essentiels à avoir dans toute roadmap produit :
● La vision produit est le moteur qui doit guider toutes les actions effectuées sur
le produit. Elle doit être répétée autant que possible et mise en avant sur la
roadmap.
● Les objectifs business sont des étapes mesurables vers la vision, et doivent là
encore être rappelés à tous.
● Une idée de temporalité. Elle permet de fournir une bonne idée de la
priorisation, mais elle ne doit pas être vue comme un commitment. Cela peut
être un découpage de l’année en trimestre, ou même un simple “Now”, “Next”,
“Later”.
● Les thématiques traitées dans la roadmap, orientées Outcomes. Les besoins
clients et business, les thèmes techniques.
● Une clause de non-responsabilité, qui indique clairement que la roadmap n’est
pas figée dans le marbre. Par exemple, la date et un message du type “sujet à
changement sans avertissement”. Si les roadmaps sont communiquées au public
ou à des partenaires, il est bon d’inclure le département juridique pour créer ce
disclaimer.
65
LOMBARDO, C. Todd, et al. Product Roadmaps Relaunched.
93
/
Exemple fictif de roadmap produit, par les auteurs de Product Roadmap Relaunched
Quelques informations additionnelles peuvent être ajoutées :
● Un marqueur sur l’état d’avancement des thématiques en cours. Par exemple

que le sujet est en cours de développement, ou qu’il est en phase de discovery.
● Un exemple de fonctionnalité, là encore pour les thématiques les plus proches
pour lesquelles les équipes sont confiantes. Ne pas être exhaustif.
● Des éléments sur le marché ciblé, par exemple le type de client ou le pays
● Les équipes en charge des différents éléments de la roadmap, lorsque la
roadmap concerne plusieurs squads (toute une ligne produit par exemple).
● Des informations liées aux ressources, des contraintes de dates (quand elles
sont réelles), des dépendances, des risques
● Des drivers extérieurs, comme un événement, un changement réglementaire…
Utiliser le framework GIST en guise de roadmap

Le framework GIST a été conçu et perfectionné par Itamar Gilad chez Google66. Il est
l’acronyme de Goals (buts), Ideas (idées), Step-projects (projets par étapes) et Tasks
(tâches). Il revient à présenter les futurs développements produits en utilisant 4 niveaux
de granularité.
66
GILAD, Itamar. Why you should stop using product roadmaps and try the GIST Framework.
https://itamargilad.com/gist-framework/
94
/
● Goals : ce sont les principaux objectifs de l’organisation : objectifs stratégiques,

OKR… Ils sont orientés outcomes et donnés sur un horizon de temps long.
● Ideas : des propositions hypothétiques pour atteindre les objectifs. Qui
correspondent aux initiatives produit. Un nombre important d’idées ne
fonctionneront pas. Toutes les initiatives qui peuvent être collectées sont
ajoutées au GIST, et doivent au moins faire l’objet d’une première évaluation. Les
idées sont priorisées sur base trimestrielle.
● Step-projects : des mini-projets de 10 semaines maximum pour tester les idées,
et implémenter celles qui marchent. Cette étape est fondamentalement inspirée
par le Lean Startup : une approche itérative et incrémentale pour valider des
hypothèses et éviter au maximum de passer du temps sur des choses inutiles.
Les step-projects sont revus toutes les semaines ou toutes les 2 semaines, en
fonction des itérations projet.
● Tasks : les différentes activités à réaliser pour chaque step-project : phases
d’expérimentations, user stories dans un backlog, tâches de release… La
fréquence de réalisation des tâches dépend du framework utilisé pour le build
(scrum, kanban…)
95
/
3.3 - Trouver les idées, définir les initiatives

Les feedbacks et la data
Pour un produit existant, il est essentiel de prendre en compte les feedbacks des
utilisateurs, et les données relatives au produit. Apprenez à connaître vos utilisateurs,
segmentez vos audiences, et analysez leur comportement.
Mettez en place des systèmes pour obtenir le plus possible de feedbacks clients, et
pensez également dès le départ à la façon dont vous allez traiter ces feedbacks :
● Organisez régulièrement des ateliers de recherche utilisateur.

● Mettez en place des systèmes sur votre produit pour collecter des feedbacks de
vos clients : intégration de modules de feedback client, emails automatisés,
pop-up de notation d’app, sondages de satisfaction
● Rapprochez-vous des équipes qui sont au contact quotidien avec votre client :
marketing produit, ventes, customer success, service client…
● Regardez les avis à propos de votre produit sur le web : forums, media sociaux,
notation des apps dans les stores…
Mettez également en place dès le début, dès votre MVP, des outils de tracking pour
évaluer ce que font vos utilisateurs avec le produit : outils d’analytics web, outil de
tracking produit basé sur les évènements, heatmaps… Mesurez le parcours de vos
utilisateurs et identifiez des pain points. Parfois la résolution sera simple, mais dans
certains cas, il faudra passer par une initiative produit beaucoup plus importante pour
corriger un problème ou saisir une opportunité.
Être à l’écoute des stakeholders et des membres de l’équipe

Dans une optique produit, le management n’impose plus aux équipes les
fonctionnalités à développer. C’est le product manager qui définit les initiatives
priorisées dans la roadmap. Cela ne signifie certainement pas que le product manager
est responsable de toutes les idées qui vont être explorées dans le cadre de la
roadmap!
Le PM doit être capable de travailler avec l’ensemble des stakeholders pour entendre
tous les points de vue, éviter les frustrations et découvrir les meilleures idées. Tant que
l’organisation n’est pas mature sur la démarche produit, certains directeurs et
parties-prenantes vont imposer des fonctionnalités. Le meilleur moyen dans ce cas-là
est de prendre les demandes comme des initiatives potentielles, et de commencer à les
explorer en phase de discovery : si l’initiative est pertinente, tant mieux ; si elle ne l’est
pas, le PM aura des données factuelles pour justifier le fait de ne pas aller plus loin.
Les auteurs de Product Roadmaps Relaunched ont publié un tableau67 listant quelques
raisons pour impliquer les stakeholders pour la constitution de la de la roadmap.
67
LOMBARDO, C. Todd, et al. Product Roadmaps Relaunched. p. 61
96
/
Stakeholder Bénéfice pour le stakeholder Comment il contribue
Client Est enthousiaste sur les bénéfices Fournit un feedback sur la valeur
qu’ils pourront tirer de futures utilisateur et les priorités.
versions produit.
Direction Comprend comment les Fournit le contexte business, une

ressources sont utilisées et le ROI direction pour le produit et les
potentiel. priorités stratégiques.
Ventes Peut répondre aux questions des Fournit des feedbacks sur ce qui
prospects et clients à propos du pousserait les prospects à acheter
futur du produit. le produit, et les clients à rester.
Marketing Prépare le lancement et la Fournit un feedback sur ce qui

promotion de futurs produits et aura l’attention des marchés
fonctionnalités. cibles.
Service client Peut répondre aux réponses des Fournit un feedback sur les
clients sur les bugs, les problèmes principaux problèmes rencontrés
d’utilisabilité, les futures par les clients.
fonctionnalités.
Recherche Planifie les projets de recherche Fournit des informations sur le

produit en fonction des thématiques de la marché et les utilisateurs.
roadmap.
Autre équipe Synchronise les livraisons et les Synchronise les livraisons et les
produit approches techniques. approches techniques.
Operations, Comprend les besoins futurs en Fournit des informations sur les
Production, termes de ressources, d’outils, coûts des ressources, outils,
Achats, RH d’infrastructures... infrastructures…
Finance Anticipe les dépenses prévues et Fournit des informations sur le

le ROI anticipé. budget disponible et un feedback
sur les cibles de ROI.
Fournisseurs et Anticipe les demandes en termes Fournit des informations sur la

partenaires de projets et de fournitures. capacité à faire et les innovations
technologiques technologiques.
Partenaires Anticipe les canaux de Fournit un feedback sur ce qui

commerciaux distribution, les prix, la pourrait se vendre et à quel prix.
promotion...
Au sein de l’équipe produit même, les différents membres ont probablement tous des
idées pour améliorer le produit :
● Le product designer, évidemment, connait bien les utilisateurs et leurs

problèmes et une partie de son rôle est de découvrir des problèmes qui valent la
peine d’être creusés. Il peut également fournir de bonnes idées en se tenant au
97
/
courant des dernières “modes” dans la communauté du design. Le rôle peut

également incomber à des product researchers mutualisés entre les équipes.
● Les membres de l’équipe de réalisation sont évidemment essentiels pour définir
toutes les initiatives techniques (amélioration de la performance, migrations
techniques, refactoring, nouvelles technologies…), mais pas seulement. Ils ont
souvent de bonnes idées fonctionnelles pour résoudre des problèmes
utilisateurs.
● Les membres de l’équipe en charge de l’analyse des données ont également
probablement de bonnes idées pour résoudre des pain points qu’ils peuvent
identifier en crunchant les données produit et utilisateurs.
Le marché et la concurrence
Les pratiques du marché sont une importante source d’idées pour améliorer votre
produit :
● Observez les pratiques de la concurrence, directe et indirecte : n’essayez pas de

copier, mais comprenez pourquoi ils sortent tel produit ou telle fonctionnalité,
quelle est leur démarche et leur vision.
● Intéressez-vous aux autres acteurs de votre marché : ils ont probablement une
bonne compréhension de votre écosystème commun, comprenez quels
problèmes ils adressent et comment ils le font. Anticipez leurs mouvements,
vous pourriez bientôt devenir concurrents.
● Regarder ce qui se fait sur des marchés adjacents : cibles différentes, autres
zones géographiques… Vous pourriez emprunter de bonnes idées, mais
n’essayez pas de copier les fonctionnalités : essayez de plutôt comprendre les
problèmes qu’ils cherchent à résoudre. Si ce problème est pertinent,
inspirez-vous de leur solution, mais cherchez à vous différencier.
● Soyez attentifs aux best practices du marché, aux innovations des leaders et des
startups qui lèvent des fonds. Restez en veille technologique pour identifier des
opportunités produit.
L’impact mapping
L’impact mapping est une méthode théorisée par Gojdo Adzic68 en 2012. Elle a pour
objectif de définir collectivement les initiatives produit générant un maximum d’impact
pour les utilisateurs et le business, en mettant de côté tout ce qui n’est pas générateur
d’impact.
L’impact mapping est réalisé lors d’un atelier dédié, réunissant toutes les
parties-prenantes intéressées par un projet, c'est-à-dire l’atteinte d’un objectif business
pour le produit. Le déroulement d’un atelier d’impact mapping est notamment
documenté par MeilleursAgents69, pionniers en France dans la gestion d’un produit par
68
ADZIC, Godjo, Impact Mapping. https://www.impactmapping.org/. Voir aussi le livre Impact
Mapping : Making a big impact with software products and projects, du même auteur.
69
FOULON, Nicolas. Conseils pour réussir son atelier d’Impact Mapping. Medium, MeilleursAgents
Engineering : 22 novembre 2019.
98
/
l’impact. Le livrable de l’atelier est une Impact Map, un outil visuel sous forme d’arbre à
4 ou 5 niveaux :
un exemple d’impact mapping pour augmenter les revenus publicitaires sur l’application
mobile d’un site d’information musicale70
● L’objectif stratégique que l’organisation veut adresser, par exemple sur la base
des OKR.
● Les acteurs concernés par l’impact mapping. Ces acteurs peuvent être des
utilisateurs, des clients, des acteurs internes (administrateurs du produit,
commerciaux…), des acteurs susceptibles de freiner l’atteinte des objectifs…
● Les impacts : ce qui doit être changé pour l’acteur concerné afin d’atteindre
l’objectif. Les impacts constituent les initiatives produit, qui peuvent être
priorisées sur la roadmap. Ce sont les outcomes que souhaitez générer.
● Les livrables : ce qui peut être fait sur le produit pour générer l’impact concerné.
Ce sont les outputs, qui permettent de générer l’outcome.
● Enfin ces livrables peuvent éventuellement être découpés en stories, éléments
qui seront utilisés comme hypothèses de discovery, puis pour construire le
backlog. Ce sont les expérimentations que vous souhaitez mener pour créer
l’output
https://medium.com/meilleursagents-engineering/conseils-pour-r%C3%A9ussir-son-atelier-dimp
act-mapping-a8d648e3d0c
70
Example impact maps. Impact mapping. https://www.impactmapping.org/example.html
99
/
Chaque branche peut être explicitée grâce à la phrase suivante71 :
Par exemple : Permettre à “Super-Fans avec un appareil mobile” de “revenir plus

fréquemment” grâce à des “offres spéciales” contribue à “augmenter les revenus publicitaires
sur mobile”.
Comme toutes les bonnes techniques d’idéation, l’atelier d’impact mapping alterne des
phases de divergence (chacun réfléchit dans son coin à un problème, puis aux
solutions), et des phases de convergence (les participants discutent des idées
individuelles et choisissent collectivement les plus pertinentes). Cet atelier se déroule en
3 phases :
● Une première phase de divergence, lors de laquelle chaque participant va

déterminer les impacts que l’organisation doit avoir sur les acteurs pour
atteindre l’objectif stratégique, et les présenter au reste de l’assemblée.
● Une deuxième phase de divergence où les participants vont sélectionner les
impacts qui leur semblent les plus prometteurs personnellement et lister des
initiatives qui permettent d’atteindre ces impacts. Là encore, chaque participant
vient partager ses idées avec le reste des participants.
● Enfin, une phase de convergence, lors de laquelle les participants votent pour les
initiatives auxquelles ils croient le plus et le moins.
La méthode impact mapping permet d’impliquer les parties-prenantes dans la

définition des initiatives à explorer pour résoudre un problème, et de fournir à toute
l’organisation un outil visuel simple et évolutif pour identifier les axes sur lesquels les
équipes travaillent. Au cas où de nouvelles initiatives ou de nouveaux impacts sont
identifiés, l’arbre est très simple à mettre à jour.
Cet impact mapping fournit un guide pour le product manager, qui peut ensuite
explorer les différentes initiatives listées dans l’arbre, les tester et les challenger en
phase de discovery.
Le framework pirate AARRR

Dave McClure, fondateur du VC 500 Startups, a inventé le framework AARRR pour aider
les startups débutantes à se concentrer sur les indicateurs qui affectent directement la
santé de leur business, et juger de la qualité de leurs efforts marketing et produit.
71
FOULON, Nicolas. Conseils pour réussir son atelier d’Impact Mapping. Medium, MeilleursAgents
Engineering : 22 novembre 2019.
https://medium.com/meilleursagents-engineering/conseils-pour-r%C3%A9ussir-son-atelier-dimp
act-mapping-a8d648e3d0c
100
/
Ce framework est notamment connu pour être utilisé par les équipes de Growth (et
notamment le “Growth Hacking”), mais il est également utile pour les product
managers.
Le principe est de penser le produit en fonction d’un tunnel de comportement des

clients, en le découpant en 5 grandes étapes :
Acquisition
Comment les visiteurs découvrent-ils le produit ? Il s’agit d’un aspect essentiellement

externe au produit, regroupant tous les canaux de notoriété et d’acquisition qui
permettent de faire venir des prospects vers le produit. Les équipes marketing sont en
grande partie responsables de ces métriques, mais dans certains cas les équipes
produit jouent aussi leur rôle.
Par exemple, Damien Delautier, CPO chez Canal+, explique que son équipe produit est
en charge d’un site web de programmes TV, qui permet de promouvoir les offres de
l’application myCANAL72.
Exemples de leviers : SEO, médias sociaux, publicité, campagnes marketing...
Activation
Les utilisateurs font-ils les actions que l’on souhaite qu’ils fassent ? Une fois qu’ils sont
attirés vers votre produit (ou vers une landing page, le site web présentant votre
produit, la page de votre application mobile…), est-ce qu’ils font des actions confirmant
leur intérêt ?
WIVOO, Product Therapy - REX sur la mise en place d'un framework Produit chez Canal + par
72
Damien Delautier. 12 mai 2020 [vidéo] https://www.youtube.com/watch?v=jmXuvN2x4vM

101
/
Exemples de leviers : téléchargement d’application, création de compte, utilisation de

certains fonctionnalités du produit, formulaire de contact, inscription à une newsletter,
demande de démo, téléchargement d’un livre blanc, expérience utilisateur...
Rétention
Les utilisateurs activés restent-ils engagés avec le produit ? Après leur première visite,
continuent-ils à interagir avec lui ? Restent-ils actifs à long terme ?
Exemples de leviers : expérience utilisateur, qualité de service, emails, push notification,

utilisation de certaines fonctions du produit, gamification...
Revenus :
Les utilisateurs activés génèrent-ils des revenus pour l’organisation ? Continuent-ils à en

générer en continuant à utiliser le produit ? Est-ce que le revenu qu’ils génèrent dépasse
le coût d’acquisition ? Est-ce que les investisseurs ont un ROI ?
Exemples de leviers : achat sur le site, abonnement premium, clic sur des publicités,
upsell/cross-sell...
Recommandation (Referral)
Les utilisateurs recommandent-ils le site ? Aident-ils à recruter d’autres clients ?
Exemples de levier : parrainage, programmes ambassadeurs, témoignages, avis

clients...
Chaque organisation a ses spécificités et doit définir comment ses différentes étapes
s’organisent dans son parcours client, et quels sont les indicateurs les plus pertinents
pour mesurer le succès de ce parcours.
En établissant une sorte de carte des indicateurs sur le chemin AARRR, l’organisation
peut ainsi identifier les points douloureux au cours desquels une partie significative des
clients et prospects part, et donc identifier des initiatives pour améliorer ces indicateurs.
Par exemple, si un des objectifs de l’organisation est d’améliorer le revenu moyen par
client sur une période donnée, le PM pourra envisager des initiatives sur le revenu
(augmentation du panier moyen, upsell…) ou des initiatives autour de la rétention (faire
revenir le client pour qu’il dépense à nouveau).
Un exemple d’utilisation du framework AARRR dans le service public, ou la

nécessité de questionner les outils du product management
Matti Schneider, un spécialiste de l’innovation numérique gouvernementale,

actuellement Chief Innovation Officer au Ministère des Affaires étrangères et ancien
responsable de l’incubateur de startups d’état beta.gouv, explique comment le
framework AARRR peut être utilisé pour un produit de service public73. Cet exemple met
73
La Product Conf - LPC & LPCx. Appliquer la mentalité produit au secteur public (Matti Schneider).
Youtube : 27 septembre 2019. https://www.youtube.com/watch?v=dOZFcmnVE5g
102
/
en lumière le fait que les outils utilisés en product management posent généralement
des hypothèses implicites qu’il faut questionner pour s’assurer d’en faire le meilleur
usage.
Une des particularités du service public (en France) est que l’utilisateur est bien souvent
captif : il n’a pas d’autre choix que d’utiliser le site web des impôts pour faire sa
déclaration, parcours sup’ pour faire ses choix d’orientation en études supérieures ou le
site de l’URSSAF pour faire ses déclarations. Dans bien des cas, il conserve le choix de ne
pas du tout utiliser le produit (et donc de ne pas bénéficier de certaines aides, ou de
continuer à suivre un processus physique ou papier).
Cette particularité a des conséquences sur la recommandation : le service responsable

d’un produit pourrait faire le choix de ne pas s’en soucier, puisque les utilisateurs sont
captifs. Néanmoins, lorsqu’un utilisateur est captif, le moindre problème devient
insupportable. Fournir une expérience de qualité constitue un levier essentiel pour
éviter une mauvaise publicité et obtenir des recommandations, au même titre qu’un
produit commercial.
La rétention est souvent analysée d’une façon diamétralement opposée à l’approche

des produits commerciaux. Dans la plupart des cas, le service public ne souhaite pas
qu’un utilisateur revienne sur son produit : il doit pouvoir faire ses démarches ou
trouver l’information du premier coup, sans avoir à revenir plusieurs fois. Une bonne
rétention est donc souvent une rétention très faible pour un produit de service public.
Les revenus sont également analysés d’une façon différente : la plupart des revenus ne
rapportent pas de valeur financière à l’Etat, et en tout cas aux investisseurs (les
ministres et chefs de cabinets). Dans les startups d'État, le revenu est analysé comme
capital réputationnel : un bon produit peut apporter des bons retours presse et une
satisfaction des usagers qui peut améliorer la réputation interne et externe des
décideurs qui ont financé le produit.
Formaliser une initiative : l’approche Working backwards d’Amazon

Pour valider le lancement de nouvelles initiatives produit, Amazon utilise une démarche
appelée working backwards74 (travailler à rebours).
Le product manager rédige un communiqué de presse fictif à destination des

utilisateurs du produit (qu’ils soient des clients externes, ou des utilisateurs internes
d’un outil). Le communiqué doit être suffisamment inspirant pour motiver les équipes
et convaincre du bien-fondé de l’initiative. Le communiqué est centré sur les problèmes
que rencontrent actuellement l’utilisateur et comment le nouveau produit ou l’évolution
74
MCALLISTER, Ian. What is Amazon's approach to product development and product
management? 18 mai 2012 [22 août 2020]
https://www.quora.com/What-is-Amazons-approach-to-product-development-and-product-man
agement?ref=http://www.product-frameworks.com/
voir aussi : MCALLISTER, Ian. Working Backwards Press Release Template and Example. LinkedIn : 23
avril 2020.
https://www.linkedin.com/pulse/working-backwards-press-release-template-example-ian-mcallis
ter/
103
/
du produit existant est supposé surpasser les solutions actuelles. Le product manager
recommence son communiqué de presse jusqu’à ce que la solution proposée apporte
un réel bénéfice client.
Le communiqué, qui doit tenir sur une seule page, doit être écrit dans un langage
compréhensible par l’utilisateur final. Si le PM ne parvient pas à rédiger le communiqué,
l’idée n’est probablement pas assez bonne ou assez claire pour être réalisée.
Le communiqué de presse suit un formalisme précis décrit par Ian McAllister, ancien
directeur d’Amazon, notamment en charge d’AmazonSmile, d’Alexa International puis
de Amazon Day :
● Titre : Nom du produit, compréhensible par l’utilisateur final

● Sous-titre : décrit le marché adressé par le produit et le bénéfice utilisateur, en
une phrase.
● Résumé : Description du produit et des bénéfices en quelques phrases, le client
doit y comprendre son intérêt sans lire autre chose.
● Problème : ce que l’initiative doit résoudre.
● Solution : Comment le produit résout de façon élégante le problème
● Citation corporate : citation du PM ou d’un porte-parole de l’entreprise sur le
produit.
● Par où commencer : souligner la facilité avec laquelle l’initiative peut commencer.
● Citation client : citation fictive d’un client hypothétique décrivant les bénéfices
qu’il obtient du produit.
● Conclusion et call-to-action : ce que le lecteur doit faire ensuite.
3.4 - Prioriser les initiatives

La priorisation des différentes initiatives dans une roadmap est souvent un cauchemar :
les intérêts des différentes parties-prenantes diffèrent et toutes essayent de pousser
leurs idées, les équipes se sentent dépossédées de leur produit lorsqu’un manager de
haut niveau veut imposer une feature, les retours clients sont très disparates, le coût et
les revenus associés à chaque initiative sont inconnus à ce moment…
Plusieurs méthodes et outils fournissent une aide pour prioriser la roadmap. Ils
permettent généralement de comparer des initiatives entre elles, plutôt qu’essayer de
définir une valeur intrinsèque à chaque initiative.
Le modèle de Kano
Du nom de son inventeur Noriaki Kano, ce modèle permet de prioriser les éléments
d’une roadmap en étant centré sur la valeur utilisateur délivrée par les initiatives
produit.
Dans un premier temps, un questionnaire est envoyé à un ensemble d’utilisateurs

potentiels, listant toutes les besoins ou fonctionnalités envisagés pour le produit. Pour
chaque besoin ou fonctionnalités, deux questions sont posées :
● Si vous pouviez faire XXX, qu’en penseriez-vous ? (question fonctionnelle)

104
/
● Si vous ne pouviez pas faire XXX, qu’en penseriez-vous ? (question

dysfonctionnelle)
Avec pour chaque question 5 réponses possibles :
1. Ca me fait plaisir (like)

2. Je m’attends à ce que ce soit le cas (expect)
3. Cela m’est égal (neutral)
4. Je l’accepte (live with)
5. Cela me dérange (dislike)
Les résultats sont analysés en utilisant la matrice ci-dessous
La matrice de Kano75
Les besoins sont triés dans 6 catégories :
● Obligatoire (M) : Couvrir ce besoin est incontournable, c’est une exigence

basique. Vous n’aurez pas de satisfaction particulière à le couvrir, mais l’oublier
serait impardonnable.
● Linéaire (L) : le niveau de satisfaction client est proportionnel à ce qui est
implémenté : si le besoin n’est pas couvert, le client est mécontent. S’il est
couvert, il est content.
● Excitant (E) : La satisfaction de ce besoin est un “delighter” de votre produit, ce qui
peut faire la différence. S’il n’est pas couvert, l’utilisateur ne s’en rend pas
75
Le modèle de KANO: si précieux pour …. QualityStreet : 13 décembre 2007.
https://www.qualitystreet.fr/2007/12/13/le-modele-de-kano/
105
/
compte, mais il apprécie fortement quand il l’est. C’est généralement une

fonctionnalité innovante du produit, qui peut faire la différence.
● Indifférent (I) : Ce n’est pas un besoin de l’utilisateur, mais si la fonctionnalité est
présente ça ne le dérange pas
● Inverse (R) : Ce n’est absolument pas un besoin de l’utilisateur, si la fonctionnalité
associée est incluse dans le produit, il s’agit d’un facteur de mécontentement.
● Contradictoire (Q) : Les réponses sur ce besoin sont contradictoires. Certains
utilisateurs attendent qu’il soit couvert, d’autres ne veulent pas qu’ils soient
couverts. Essayez de trouver si vous pouvez segmenter votre audience en
fonction de ce critère.
Un diagramme de Kano
Les résultats sont ensuite représentés sur un diagramme de Kano, montrant l’impact du
degré de couverture des besoins sur la satisfaction client. Les besoins des catégories
indifférent et inverse sont ignorés dans le développement produit. Les éléments
basiques doivent être couverts, au PM de définir le degré de couverture. Enfin le PM
doit équilibrer sa roadmap entre les éléments linéaires, pour éviter de l’insatisfaction en
cas d’absence, tout en maximisant l’effet “wow” en considérant certains effets excitants.
Les avantage de Kano
Il met l’utilisateur au centre de la priorisation, en se focalisant sur la valeur perçue. Il

permet également de prendre en compte l’aspect dysfonctionnel du produit : que se
passe-t-il si un besoin n’est pas couvert ?
Les inconvénients de Kano
Il ne prend pas en compte la complexité pour couvrir le besoin. Le PM doit pouvoir le

prendre en compte notamment pour arbitrer entre les différents besoins linéaires et
106
/
excitants. En étant basé sur les avis des utilisateurs, il est sensible aux biais, notamment
sur la façon dont les besoins sont exprimés. Enfin il est très axé “fonctionnalité”, et ne
prend pas en compte l’objectif business.
Le modèle de Kano peut être utile lorsque l’organisation cherche à lancer un produit,
pour déterminer les grands domaines fonctionnels auxquels il doit pouvoir répondre. Il
peut également être utile pour choisir les domaines à investiguer avant même de
songer à l’effort engagé : quelles initiatives prioriser en phase de discovery ?
La méthode RICE
Le modèle RICE a été documenté par la société Intercom76. Il s’agit d’un modèle de
scoring permettant de comparer différentes idées produit entre elles pour les prioriser.
Chaque initiative est évaluée selon 4 axes, avec un système de notation de chaque axe
qui doit être commun à toutes les initiatives comparées.
● Reach : estimation du nombre de personnes qui seraient concernées par une

initiative, pendant une période donnée, ou d’évènements sur cette même
période. Si possible, ce chiffre doit être une métrique réelle, provenant
d’analytics produit.
Intercom utilise le nombre d’utilisateurs concernés par trimestre.
● Impact : l’impact de l’initiative sur le KPI recherché, idéalement l’objectif produit
que les équipes cherchent à atteindre (en utilisant par exemple les OKR).
Par exemple Intercom utilise une échelle de 0,25 (minime), 05, 1, 2 à 3 (impact
massif).
● Confidence : confiance dans l’impact que générera l’initiative et l’effort qu’elle
demandera.
Intercom choisit d’exprimer la confiance en pourcentage : 100% pour une
confiance totale, 80% pour une confiance moyenne, 50% pour une confiance
basse. En dessous de 50%, même pas la peine d’y penser.
● Effort : coût d’implémentation estimée de l’initiative
Intercom utilise le nombre d’équivalents temps plein (ETP ou FTE) sur 1 mois
pour implémenter la solution.
Le RICE score est calculé de la façon suivante :
Un score RICE est attribué à chaque initiative, ce qui permet de les classer pour les
prioriser. A noter que comme chaque système de classement par points, il doit servir de
76
MCBRIDE, Sean. RICE: Simple prioritization for product managers. Inside Intercom.
https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/
107
/
guide pour la priorisation, et non être pris comme une règle absolue, d’autres facteurs
pouvant jouer dans la priorisation.
Les avantages de RICE
Ce système est basé sur des métriques actionnables, et prend notamment en compte
l’impact sur les KPI ou OKR associés aux objectifs. Il prend en compte une diversité de
facteurs permettant d’avoir une vue globale du problème, notamment la valeur
business et client, tout en considérant l’incertitude inhérente à la construction de
roadmaps.
Les inconvénients du RICE
Basé sur des métriques concrètes, le RICE peut difficilement être utilisé pour la création
d’un produit pour lequel le Reach et l’impact sont largement inconnus. Il est davantage
adapté à l’évolution de produits existants qu’à la création de nouveaux produits.
Attention également au facteur Reach, en particulier sur les produits de type plateforme
qui mettent en relation deux populations dont les effectifs sont déséquilibrés.
Christopher Parola, Lead PM de MeilleursAgents, propose de mesurer le RICE par
rapport aux OKR77. Par ailleurs, en tout début d’initiative, l’effort est totalement inconnu.
Pour prioriser les initiatives à investiguer en discovery, Thiga propose d’adapter le RICE
en PRIC78 : enlever la variable Effort, et la remplacer par une variable Problem, pour
évaluer la pertinence du problème que l’initiative cherche à résoudre.
La méthode ICE
La méthode ICE a été inventée par Sean Ellis, considéré comme le créateur du growth
hacking. Tout comme le RICE, ICE est un modèle de scoring pour évaluer des initiatives
produit (ou marketing) en les comparant entre elles. Le score ICE a d’abord été conçu
pour prioriser les expérimentations de growth, il a été adopté par les product manager
pour pouvoir prioriser les initiatives produit et les fonctionnalités.
Il revient à prioriser les idées ayant le meilleur impact produit et la plus grande facilité
d’exécution, pondérées par un indicateur de confiance dans ces estimations.
77
La Product Conf - LPC & LPCx. Piloter les équipes Produit par l'impact. Youtube : 8 août 2018
[vidéo] https://youtu.be/VqdUA3bhW38?t=1010
78
Commentaires de Fabrice Des Mazery, CPO de Thiga, pendant le webinar Retour sur la
construction d’une Roadmap chez MedecinDirect ! Thiga : 9 juin 2020.
https://laproductconf.com/lpcx/retour-sur-la-construction-dune-roadmap-chez-medecindirect/
108
/
Le ICE score est basé sur 3 sous-scores, chacun noté de 1 à 10 :
● Impact : dans quelle mesure l’idée ou l’initiative va affecter positivement

l’objectif ou le key results (si on utilise des OKR) concernés
● Confiance : quelle confiance accorder aux deux autres scores
● Ease (facilité) : dans quelle mesure l’idée ou l’initiative sera simple à implémenter
Itamar Gilad, ancien PM chez Google notamment, propose un outil pour mesurer
l’indice de confiance79. L’idée est d’améliorer progressivement l’indice de confiance
d’une initiative en itérant sur différents moyens permettant d’évaluer la pertinence de
cette initiative.
Avantages de ICE
Le modèle ICE est très simple et rapide à mettre en place. SI vous avez besoin de
donner un premier ordre de priorité dans une longue liste d’initiatives pour rapidement
identifier les plus prometteuses et les moins intéressantes, ou si vous n’avez pas besoin
de justifier scientifiquement vos choix, ICE peut être utile.
79
GILAD, Itamar. Idea Prioritization With ICE and The Confidence Meter.
https://itamargilad.com/the-tool-that-will-help-you-choose-better-product-ideas/
109
/
Inconvénients de ICE
Contrairement au scoring RICE, ICE est basé sur des indicateurs subjectifs. Des
personnes différentes vont probablement assigner des scores significativement
différents pour chaque indicateur. Il est très sensible aux biais individuels. Les
organisations utilisant ICE devraient également définir une échelle collective sur ce que
signifie tel ou tel score dans les différents indicateurs, sur le modèle de ce que Itamar
Gilad propose pour le score de confiance.
3.5 - Prendre compte les imprévus

Les objectifs stratégiques, les OKR et la roadmap permettent de définir les priorités des
équipes produit et de les communiquer à toute l’organisation. Néanmoins, il arrive que
des événements externes à l’organisation l’obligent à revoir en urgence ces priorités.
L’organisation doit être capable de réagir très rapidement, éviter d’être figée par les
processus et les obligations internes.
Par exemple, Nicolas Baron, CTO de MeilleursAgents, mentionne80 le moment où

Google a annoncé que le modèle de pricing de Google Maps allait changer un mois plus
tard. Pas le choix pour un produit faisant une utilisation intensive de Google Maps, OKR
ou non, il fallait prioriser ce sujet et proposer une solution dans les temps.
Autre exemple, celui de la transformation de Doctolib en 2020, qui a pu transformer

toute l’entreprise en quelques jours pour généraliser le service de téléconsultation :
● En décembre 2019, une nouvelle maladie est identifiée à Wuhan, en Chine,

appelée plus tard Covid-19.
● En janvier 2020, les premiers morts apparaissent toujours à Wuhan, et les
premiers malades sont identifiés en France.
● Le 14 février 2020 le premier mort est annoncé en France, et à la fin du mois les
premiers foyers de contamination y sont détectés.
● Le 5 mars, Doctolib annonce la gratuité de la téléconsultation pour tous les
médecins français, contre 79€/mois auparavant. Les 3500 clients existants sont
remboursés.81 Dans la foulée, Doctolib dédie une équipe d’une centaine de
personnes pour déployer la consultation à grande échelle, sur un effectif de
1250 personnes82.
Plusieurs centaines de cas de Covid-19 sont rapportés en France.
● Le 9 mars un décret est publié pour mettre fin à l’obligation d’avoir consulté son
médecin dans l’année précédant une téléconsultation.
80
La Product Conf - LPC & LPCx. Piloter les équipes Produit par l'impact. Youtube : 8 août 2018
[vidéo] https://youtu.be/VqdUA3bhW38?t=1158
81
RENAULT, Marie-Cécile. Doctolib rend la téléconsultation gratuite pour les médecins français.
Le Figaro : 5 mars 2020.
https://www.lefigaro.fr/conjoncture/doctolib-rend-la-teleconsultation-gratuite-pour-les-medecins
-francais-20200305
82
ZIRAR, Wassinia. Coronavirus: Doctolib installe une "cellule dédiée" à la téléconsultation (Stanislas
Niox-Chateau). Tic santé : 12 mars 2020.
https://www.ticsante.com/story/5064/coronavirus-doctolib-installe-une-cellule-dediee-a-la-teleco
nsultation-(stanislas-niox-chateau).html
110
/
● Le 11 mars les visites en EHPAD sont interdites. L’OMS déclare la situation de

pandémie mondiale.
● Le 14 mars, le Premier Ministre annonce la fermeture de tous les lieux publics
non indispensables à partir de minuit.
La téléconsultation représente 4% de l’activité de Doctolib.
● Le 17 mars, le confinement est mis en place en France. La téléconsultation
représente désormais 18% de l’activité de Doctolib.83.
● A partir du 18 mars, la téléconsultation est remboursée à 100% par l’Assurance
Maladie.
● Le 20 mars, le volume de téléconsultations a été multiplié par 40, pour atteindre
plus de 50% de l’activité de Doctolib.84.
● Au 1er avril, Doctolib annonce 100 000 téléconsultations par jour85.
● Le 11 mai, la France entame une phase de déconfinement.
● Le 8 juin, Doctolib annonce que 4,6 millions de téléconsultations ont été
effectuées sur sa plateforme, par 1,4 millions de patients et 32500
professionnels de santé.
Près de 40 000 consultations vidéo sont encore réalisées chaque jour, contre
1500 avant l’épidémie.86
83
DANRE, Cécile. Coronavirus: en un mois, les téléconsultations via Doctolib ont été multipliées par
18. BFM Business : 18 mars 2020.
https://www.bfmtv.com/economie/coronavirus-en-un-mois-les-teleconsultations-via-doctolib-ont
-ete-multipliees-par-18_AN-202003180072.html
84
ROUQUETTE, Pauline. Coronavirus : le nombre de téléconsultations médicales explose. Europe1 :
20 mars 2020.
https://www.europe1.fr/sante/coronavirus-confinement-oblige-le-nombre-de-teleconsultations-
medicales-explose-3956743
85
Doctolib. 100 000 téléconsultations par jour sont désormais réalisées sur DOctolib, dont 85% dans
le cadre d’un suivi de patient. 1er avril 2020.
https://cdn2.hubspot.net/hubfs/5479688/B2B%20-%20Press/CP_Doctolib_TC_Covid19_200401-p
age-001.jpg
86
Doctolib. Encore 30 fois plus de consultations vidéo qu’avant l’épidémie : comment pérenniser cette
pratique ?. 8 juin 2020.
https://cdn2.hubspot.net/hubfs/5479688/B2B%20-%20Press/CP%20200608%20-%20L%E2%80%9
9usage%20de%20la%20consultation%20vid%C3%A9o%20reste%20beaucoup%20plus%20%C3%
A9lev%C3%A9%20qu%E2%80%99avant%20la%20crise.pdf
111
/
4 - Le cycle de vie du produit

Tout produit, qu’il soit créé par une startup ou une grande organisation suit un cycle de
vie particulier. Chaque étape implique des objectifs et des tâches particuliers pour un
produit. En ne tenant pas compte de ces étapes ou en essayant de les brûler,
l’organisation prend un risque énorme de livrer un produit qui ne servira à rien, ou en
tout cas, dont une large partie des fonctionnalités seront inutiles, donc du temps passé
et des investissements dépensés pour le créer seront gâchés.
Dans une startup, le cycle de vie et la recherche d’investissements sont liés : certains
investisseurs early stages sont prêts à prendre le risque d’investir dans une startup à la
recherche du problem-solution fit, tandis que les tours plus tardifs arrivent quand la
startup recherche son product/market fit, voire une fois qu’elle l’a trouvé.
4.1 - La recherche du bon problème à résoudre : le

problem/solution fit
La création d’un nouveau produit vient généralement d’un problème à résoudre : soit
un problème identifié sur le marché pour lequel l’organisation pense pouvoir apporter
une réponse plus pertinente que les solutions existantes (une réponse qui fournit plus
de valeurs aux clients/utilisateurs, ou une réponse qui fournit le même niveau de valeur
mais pour un coût moindre). Bien souvent, les organisations qui ont identifié un
problème, et en particulier les corporates, passent directement à la solution.
Avant de penser à comment résoudre le problème, il faut être certain que ce problème
existe, qu’il vaut la peine d’être résolu et qu’il est suffisamment cadré. En d’autres
termes, il faut essayer d’atténuer dès le départ le risque de valeur. Ensuite seulement,
l’organisation peut commencer à réfléchir à la meilleure solution pour résoudre ce
problème.
L’approche Lean Startup fournit des clés pour vérifier le problème et tester des
solutions : Vous formulez des hypothèses sur le problème, pour lesquelles vous
construisez un prototype (qui peut être aussi simple qu’un schéma sur une feuille de
papier pour commencer), et vous menez des enquêtes qualitatives pour vérifier ou
invalider vos hypothèses. Vous itérez ainsi jusqu’à valider suffisamment d’hypothèses
pour vous lancer.
Daria Nepriakhina, fondatrice du réseau IdeaHackers87, a créé le problem/solution fit

canvas. Il s’agit d’un outil visuel qui permet de comprendre si tous les aspects du
problème ont bien été traités pour proposer une solution pertinente. Le canvas indique
dans quel ordre les cases doivent être remplies.
87
https://www.ideahackers.network/
112
/
Le problem/solution fit canvas de IdeaHackers88
La première ligne, en rose, est appelée Customer State fit. Elle permet de vous assurer
que vous comprenez votre cible :
● Qui sont vos segments clients ?

● A quelles limites se heurtent-ils lorsqu'un problème survient ?
● Quelles solutions sont disponibles pour les utilisateurs lorsqu’ils font face à ces
problèmes ? Et quels sont les avantages et inconvénients de ces solutions ?
En orange, la section Problem/Behavior fit permet de mettre en lumière les problèmes

les plus urgents à résoudre :
● Quels sont les problèmes que vous souhaitez résoudre pour vos clients ? A
quelle fréquence surviennent-ils ?
● Quelle est la cause de chacun de ces problèmes ?
● Que font-ils quand ce problème survient ?
En vert, le Communication/Channel fit aide à formaliser la communication que vous

allez adopter pour répondre à ces problèmes :
● Qu’est-ce qui pousse un client à agir ?
88
NEPRIAKHINA , Daria. The Problem-Solution Fit canvas. Medium : 19 décembre 2016.
https://medium.com/@epicantus/problem-solution-fit-canvas-aa3dd59cb4fe
Accessible en version PDF ici :
https://static1.squarespace.com/static/5e735af15d82f4609cd315d0/t/5f5cc2fe381d4c58cea18fcc
/1599914751215/problem-solution-fit-canvas-by-daria-nepriakhina-ideahackers-network.pdf
113
/
● Que ressentent les personnes qui ont un problème, et quelles sont leurs
émotions lorsque ce problème est résolu ?
● Quels sont les canaux online et offline sur lesquels le comportement des
utilisateurs s’exprime en réaction aux problèmes que vous souhaitez résoudre ?
Enfin en bleu la solution proposée pour résoudre les problèmes identifiés via les bons
canaux.
4.2 - La recherche du Product/Market fit

Le concept de product/market fit a été créé par Andy Rachleff, fondateur du VC
Benchmark Capital et de la startup Wealthfront, et popularisé par Marc Andreessen89,
co-créateur des navigateurs Mosaic et Netscape, et co-fondateur du VC Andreessen
Horowitz.
“The only thing that matters is getting to product/market fit.” -

Andy Rachleff
”Product/market fit means being in a good market with a

product that can satisfy that market.” - Marc Andreessen
Le product/market fit (PMF) est le moment où le produit répond si bien aux attentes du

marché qu’il devient économiquement viable. Il n’y a pas de définition claire du moment
où le PMF est atteint. Ce n’est d’ailleurs pas un moment précis. Par contre, il est clair
que certains produits n’ont pas atteint leur PMF, certains ne l’atteindront jamais même
en existant pendant des années, et certains indices permettent d’identifier qu’un certain
degré de PMF est bien atteint.
Pour tendre vers le product/market fit, le principe reste le même que pour cadrer le
problème et la solution : poser des hypothèses, et les valider ou les réfuter grâce à des
expérimentations sur le terrain. Les hypothèses deviennent de plus en plus précises, les
MVP de plus en plus concrets et aboutis. Lorsque les hypothèses ne permettent plus de
délivrer de valeur, l’organisation pivote.
89
Andreessen, Marc. The PMARCA guide to startups : Part 4: The only thing that matters. 25 juin
2007. https://pmarchive.com/guide_to_startups_part4.html
114
/
Le product/market fit présente trois caractéristiques majeures90 :
● La cible du produit comprend votre proposition de valeur, parvient à vous

identifier et adhère à la solution que vous proposez.
● La cible est prête à payer pour votre produit, ou en tout cas à l’utiliser
régulièrement et à effectuer des actions qui vous permettent de le monétiser (si
votre business model est basé sur la publicité par exemple).
● La cible apprécie suffisamment votre produit pour en parler et le recommander.
Comment mesurer le product/market fit ?

Le product/market fit n’est pas une science exacte, mais quelques indicateurs
permettent d’avoir des indices sur l’atteinte ou non du PMF :
● Le Net Promoter Score (NPS)

○ La question “Quelle est la probabilité que vous recommandiez ce produit
ou ce service à un ami ou un proche ?” est posée aux utilisateurs du
produit, avec comme réponse possible une valeur de 1 à 10.
○ Toutes les réponses de 6 ou moins sont considérées comme des
détracteurs. Les 7 et les 8 sont neutres, les 9 et les 10 sont des
promoteurs.
○ Le NPS est calculé en soustrayant le pourcentage de détracteurs au
pourcentage de promoteurs. Un score supérieur à 0 est un signe de
bonne santé.
○ Par exemple, si un produit a 25% de détracteurs (6 ou moins), 45% de
neutres (7 ou 8) et 30% de promoteurs (9 ou 10), son NPS est de 5, ce qui
est plutôt bon. A comparer avec les autres acteurs de son marché.
● Churn rate (taux d’attrition) : ratio du nombre de personnes ayant quitté le
service sur le nombre total d’utilisateurs du service. Il s’agit du contraire de la
rétention.
● Taux de croissance : évolution d’une métrique d’une année sur l’autre, par
exemple les revenus, le nombre d’utilisateurs...
● Part de marché
● Bouche à oreille : si les clients parlent de votre produit à d’autres personnes, ils
deviennent en quelque sorte vos propres vendeurs.
● Couverture média : si des journalistes ou des analystes parlent de votre produit
de plus en plus fréquemment, vous êtes probablement sur la bonne voie.
La courbe de diffusion de l’innovation : dépasser les early adopters

Afin d’atteindre le product/market fit, vous devez acquérir suffisamment de clients pour
atteindre une taille critique sur votre marché. La courbe de diffusion de l’innovation a
été théorisée par Everett Rogers dans son livre Diffusion of Innovations. Cette théorie
90
LEVREY, Fabien & IRRMANN-TEZE, Alexandre. Guide du Growth, Règle 1 / Product Market Fit : pas
de PMF, pas de croissance !. Thiga : 17 mai 2017.
https://blog.thiga.co/guide-du-growth-1-product-market-fit-pmf-croissance/
115
/
explique l’adoption d’un nouveau produit ou d’une innovation au sein d’un marché en
divisant ce marché en 5 groupes.
La courbe de diffusion de l’innovation de Everett Rogers
Dans Crossing the Chasm, Geoffrey Moore a approfondi cette théorie et l’a appliquée à
l’innovation liée aux produits digitaux.
● Les fans de techno (Technology Enthusiasts), correspondant aux Innovators de

Rogers : Ils aiment bien tester de nouvelles choses et acceptent la prise de
risque. En entreprise, ce sont des cellules d’innovation, des labs, des
départements R&D. Ils sont familiers avec les concepts scientifiques et
techniques. Ils apprécient d’être sollicités pour donner du feedback. Ils sont vos
tous premiers utilisateurs, éventuellement vos premiers clients, ceux sur
lesquels vous testerez vos hypothèses de départ.
● Les visionnaires (Visionaries) ou Early Adopters : Ils sont prêts à payer cher pour
être parmi les premiers à utiliser une nouveauté. Ils adoptent une nouveauté en
étant convaincus par le storytelling autour du produit, par la vision, par le
“pourquoi”. Ils sont leaders d’opinion, et influencent la presse spécialisée. Ils
utilisent l’expérience des innovateurs pour choisir ce qu’ils adoptent.
● Les pragmatiques (Pragmatists) ou Early Majority : Ils représentent une partie
importante du marché, plus du tiers, et sont essentiels pour la viabilité du
produit. Ils sont optimistes et apprécient la nouveauté, à partir du moment où
elle a été validée et qu'elle répond mieux qu’un autre à leur besoin. Pour les
produits B2B, les processus d’acquisition deviennent plus lourds, passant
généralement par des appels d’offres gourmands en temps et en ressources. Ils
sont prêts à payer pour une innovation qui a un véritable impact sur leur vie ou
sur leur organisation. Ils ne changent pas facilement de solution et sont donc
loyaux quand ils adoptent un produit.
● Les conservateurs (Conservatives) ou Late Majority : Avec les pragmatiques, ils
représentent l’essentiel du marché. Ils adoptent tardivement un produit et sont
influencés par les nouveaux standards adoptés par les pragmatiques. Ils ne sont
pas attirés par le côté innovant d’un produit et cherchent des solutions à prix
plus faibles, généralement quand d’autres innovations sont déjà apparues sur le
marché.
116
/
● Les sceptiques (Skeptics) ou Laggards : Ils refusent la nouveauté par principe. Ils
n’adoptent un nouveau produit que lorsqu’ils y sont forcés, parce que les
solutions qu’ils utilisent ne sont plus produites par exemple.
Moore explique qu’il y a un gouffre (chasm) entre l’adoption d’un produit innovant par
les visionnaires et l’adoption de ce même produit par les pragmatiques.
Le gouffre (ou “Chasm”) à franchir entre les Early Adopters et la Early Majority
● Les fans de techno et les visionnaires adhèrent aux valeurs du produit et

l’adoptent de façon enthousiaste. Ils sont intéressés par le futur et aiment voir le
potentiel de nouveaux produits. L’organisation peut s’appuyer sur sa
communauté. Les premiers contrats sont signés assez rapidement et le bouche à
oreille fonctionne bien pour attirer de nouveaux clients. Les nouvelles
fonctionnalités sont développées en accord avec ces premiers clients heureux de
trouver un produit qui répond très bien à leurs besoins.
Néanmoins la création de ces nouvelles fonctionnalités “sur mesure” coûte cher
et le segment des early adopters n’est pas assez important pour permettre au
produit d’être rentable. Passé les premiers enthousiastes, les efforts marketing
pour acquérir de nouveaux clients deviennent trop importants par rapport aux
revenus générés par ces clients.
● Pour devenir rentable, l’organisation doit impérativement pouvoir cibler les
pragmatiques. Ce segment a des attentes très différentes de celles des early
adopters. Ils apprécient également la nouveauté. Mais là où les early adopters
aiment le produit et adoptent la vision qui leur est proposée, les pragmatiques
sont intéressés par la résolution de leurs problèmes actuels et ne se sentent pas
concernés par les produits qui promettent d’ouvrir des opportunités dans le
futur. Ils sont convaincus par les références de leurs pairs plus que par les early
adopters. Ils veulent être certains que les produits fonctionnent et ne veulent
pas assumer les dysfonctionnements
Pour franchir ce gouffre, Moore propose de segmenter le marché cible en segments

de niche et de tout faire pour devenir leader sur une de ces niches. La niche idéale est
une niche délaissée par les principaux acteurs du secteur : ils ont des problèmes
117
/
particuliers qui ne sont pas réglés par les produits de masse, et financièrement, ils ne
sont pas intéressants pour ces mêmes acteurs. Pour répondre aux besoins de cette
niche, l’organisation identifie les cas d’usage du produit les plus pertinents pour cette
niche et réoriente leur roadmap pour renforcer ces cas d’usages. Les équipes marketing
développent les messages, les contenus et les canaux pour conquérir des premiers
clients, obtenir des références et acquérir de nouveaux clients les uns après les autres
jusqu’à devenir le leader de cette niche. Une fois ce micro-segment conquis,
l’organisation choisit une deuxième niche connexe à la première pour reproduire la
même stratégie, en ayant cette fois des références utiles.
Tant que le produit n’a pas réussi à conquérir une partie de cette early majority,
commencé à être leader sur certains marchés et trouver une certaine rentabilité, il n’a
pas atteint de product/market fit.
4.3 - La phase de croissance : le growth

Quand le produit commence à trouver son product/market fit, ses premiers clients, il
rentre dans une phase de croissance. Pour les produits ayant le plus de succès, c’est le
moment de grandir le plus possible : augmenter l’adoption du produit, créer une
préférence de marque et gagner des parts de marché. En grossissant, le produit
rencontrera de nouveaux concurrents, soit en attaquant des marchés connexes, soit
parce que de nouveaux entrants arriveront. L’entrée dans un marché de masse permet
aussi de réaliser des économies d’échelle et d’optimiser les processus pour augmenter
très significativement les profits.
Pour grossir, le produit doit bien sûr attirer de nouveaux clients, les faire passer à
l’action, les retenir, les monétiser, et les faire recommander le produit à d’autres. Il s’agit
des 5 étapes du framework AARRR, le plus utilisé pour mesurer la croissance d’un
produit.
Travailler sa rétention
La fidélisation et la rétention des utilisateurs est généralement un facteur essentiel de
croissance, surtout lorsque le coût d’acquisition du client est élevé et qu’il met du temps
à être rentabilisé. C’est particulièrement vrai pour les applications mobiles : est-ce que
les utilisateurs qui ont téléchargé et une application mobile s’en servent encore 2, 5, 20
jours après ?
En mettant en place des campagnes marketing coûteuses, il est “facile” d’attirer de

nombreux visiteurs sur le produit (Acquisition dans le framework AARRR). Il est plus
compliqué de les activer, et encore plus de les retenir.
La rétention est généralement formalisée sous forme de courbe de rétention, mesurant

le pourcentage d’utilisateurs d’une cohorte donnée qui utilisent encore l’application X
jours après l’acquisition (le téléchargement de l’application). Toutes les courbes de
rétention déclinent, vous n’aurez jamais 100% de vos utilisateurs initiaux qui restent
fidèles à votre produit.
118
/
Une bonne courbe (en vert sur le graphique) est une courbe qui se stabilise dans le
temps, et donc pour laquelle on voit des utilisateurs qui continuent à rester actifs à long
terme.
Une mauvaise courbe est une courbe qui ne se stabilise jamais, et qui tend rapidement
vers le 0, donc que les utilisateurs cessent rapidement d’utiliser le produit. Plus
exactement, la courbe est mauvaise si elle atteint ce 0 avant d’avoir rentabilisé les coûts
d’acquisition et généré des profits pour l’organisation.
Exemple montrant une bonne et une mauvaise courbe de rétention91
Il existe deux moyens principaux pour améliorer une courbe de rétention :
Shift the curve up, repousser la courbe vers le haut :
L’objectif est de retenir plus d’utilisateurs dès les premiers jours, afin de retarder le
moment où les utilisateurs vont cesser de l’utiliser. Le meilleur moyen de les retenir au
départ est d’améliorer l’expérience de prise en main du produit, aussi appelé
onboarding. Concrètement, il faut que l’utilisateur comprenne le plus tôt possible
quelle est la valeur que le produit peut lui apporter et comment l’utiliser.
Afin d’améliorer cet onboarding, les product growth managers cherchent ce qu’on
appelle le “aha moment”, c’est-à-dire les facteurs qui font qu’un utilisateur a le déclic,
est engagé avec le produit et se met à l’utiliser fréquemment. Par exemple, le aha
moment de Facebook arrive quand un utilisateur a ajouté à son réseau 7 amis en 10
jours92. Chez Twitter, ce aha moment arrive quand l’utilisateur suit 30 comptes, et qu’au
moins 10 comptes le suivent à son tour93. Pour myCANAL, c’est quand un utilisateur
91
BONNIE, Emily. The Mobile Marketer’s Guide to Mastering User Retention. Clevertap : 19 août
2020. https://clevertap.com/blog/guide-to-user-retention/
92
STANCIL, Benn. Facebook's Aha Moment Is Simpler Than You Think. Mode : 30 janvier 2015.
https://mode.com/blog/facebook-aha-moment-simpler-than-you-think/
93
MAKKAR, Gaurav. Facebook, Twitter, and the Aha Moment!. UX Planet : 1er avril 2019.
https://uxplanet.org/facebook-twitter-and-the-aha-moment-7f8e4c503e3e
119
/
regarde au moins 6 vidéos au cours des 7 premiers jours94. A partir du moment où le

aha moment est identifié, les équipes en charge de l’onboarding produit développent
toute leur stratégie pour faire en sorte que ces critères soient réalisés : Facebook vous
incite à ajouter suffisamment d’amis dès le départ. Twitter vous propose de suivre des
comptes pertinents, dont certains susceptibles de vous suivre à leur tour. myCANAL
essaye de vous faire faire regarder des vidéos dès le départ.
Flatten the curve, aplatir la courbe :
La deuxième technique consiste à inciter les utilisateurs à revenir une fois l’onboarding
effectué avec succès. En analysant les données, le PM peut identifier les
comportements saillants des utilisateurs qui utilisent déjà le produit de façon régulière :
quelles fonctionnalités utilisent-ils ? À quels moments de la journée sont-ils le plus actifs
? En poussant ces fonctionnalités au bon moment, les nouveaux utilisateurs ont de
bonnes chances de trouver quelque chose qui les intéresse et de revenir.
De nombreux autres facteurs favorisent l’engagement sur le long terme. L’ajout de

nouvelles fonctionnalités pertinentes pour mieux répondre à certains besoins, ou
l’amélioration de fonctionnalités existantes après avoir identifié des points de friction.
Nir Eyal détaille95 de nombreuses techniques pour engager les utilisateurs, grâce à ce
qu’il appelle des Hooks (crochets). Les hooks permettent de connecter le produit avec
les problèmes de l’utilisateur à une fréquence telle que l’utilisation du produit devient
une habitude. Ces hooks s’enrichissent les uns les autres pour former une boucle infinie
qui enferme l’utilisateur au sein du produit. Le framework de Eyal comporte 4
composantes :
1. Des triggers, ou déclencheurs : des éléments internes au produit (boutons…) ou

externes (emails, push notification…) qui incitent l’utilisateur à passer à l’action
2. Une action : ce qu’on attend de l’utilisateur au sein du produit. Utilisation d’une
fonctionnalité, ajout d’amis ou envoi d’un message dans un réseau social, clic sur
un résultat de recherche, achat in-app… Pour qu’un comportement soit effectué,
l’utilisateur doit être motivé à le faire et compétent pour le faire.
3. Des rewards, ou récompenses : des éléments motivant l’utilisateur pour passer à
l’action et générateurs de fidélisation. Eyal les classe en 3 catégories :
○ Récompense de tribu : la communauté à laquelle appartient l’utilisateur
reconnaît la valeur de son action (un like ou un partage sur un réseau
social par exemple)
○ Récompense de chasse : l’utilisateur est récompensé par un bien ou la
satisfaction d’un besoin, comme une promotion sur un produit, ou le fait
de trouver une information pertinente lors d’une recherche.
○ Récompense de soi : l’utilisateur ressent un plaisir, un sentiment
d’accomplissement personnel, pour avoir réalisé l’action, comme un gain
94
WIVOO. Product Therapy - REX sur la mise en place d'un framework Produit chez Canal + par
Damien Delautier. Youtube : 12 mai 2020. [vidéo]
ttps://www.youtube.com/watch?v=jmXuvN2x4vM
95
EYAL, Nir. Hooked : comment créer un produit ou un service qui ancre des habitudes. Eyrolles :
2018.
120
/
de productivité personnel (le produit peut afficher le temps gagné), ou un

record battu sur une application de coach sportif.
4. Un investissement : plus l’utilisateur utilise un service, plus ce service lui
apporte de valeur, et donc plus il est susceptible de lui être fidèle. Par exemple,
plus j’ajoute de contacts sur un réseau social, plus je reçois d’informations et plus
je peux diffuser d’information à un nombre important de personnes. Mieux le
produit me connaît, plus il peut me fournir de services qui me sont utiles.
Chaque investissement permet aussi de déterminer les prochains triggers, qui
vont m’attirer encore vers le produit.
4.4 - La maturité du produit

A un moment donné, le produit cessera d’être en phase d'hyper-croissance. Les parts
de marché seront plus difficiles à gagner, les nouveaux utilisateurs plus difficiles à
capter.
Le centre d’attention se portera sur la conservation des parts de marché, sur la lutte
contre la concurrence, sur la réputation du produit et sur la conservation de sa base
client. L’organisation cherche de nouveaux moyens pour accroître les revenus avec une
base d’utilisateurs relativement stable. De nouveaux segments jusqu’ici ignorés peuvent
être envisagés. Des opportunités technologiques ou partenariales peuvent
éventuellement permettre de trouver de nouveaux moteurs de croissance.
Les efforts des équipes produits ne doivent pas être relâchés, au contraire, en
particulier dans les environnements très compétitifs. L’organisation doit chercher à
disrupter son modèle, avant que d’autres ne le fasse à sa place. La vision produit doit
être revue : est-ce qu’elle a été atteinte ? Si non, est-elle toujours pertinente et que
manque-t-il pour la réaliser. Si oui, faut-il effectuer un pivot, et se projeter dans l’avenir
d’une façon différente ?
Si l’organisation ne prend pas garde, le produit amorcera une phase de déclin. Une
partie de ses utilisateurs quitteront le produit pour un autre. Une rupture
technologique qui n’aura pas été envisagée à temps pour le produit le rendra obsolète.
Les revenus baisseront, les prix devront être baissés pour rester compétitifs. En cas de
déclin confirmé, deux grandes options sont possibles :
● Tenter de changer fondamentalement le produit. Opérer un pivot en repartant

sur des phases de recherche, sur une nouvelle quête de problem/solution fit, sur
la validation de nouvelles hypothèses.
● Se résoudre à tuer le produit, au profit d’un autre produit de l’organisation qui
pourrait prendre le relais sur le même type de besoin, ou en se concentrant sur
un type d’activité tout à fait différent dans l’organisation. Les dépenses sur le
produit seront plus ou moins rapidement réduites, les équipes produit
réaffectées à d’autres produits. L’organisation devra penser à la stratégie à
mettre en place pour accompagner les utilisateurs vers une autre solution,
surtout si elle souhaite garder cette base de clients loyaux.
121
/
IV - Product Discovery : identifier quel produit développer
Partie IV
Product Discovery :
identifier quel
produit développer
Le product discovery est un processus itératif qui permet de réduire l’incertitude autour
d’un problème ou d’une idée, afin d’être certain que l’organisation va développer le bon
produit, pour la bonne audience. Le product discovery permet de réduire au maximum
les risques de valeur, d’utilisabilité et de faisabilité.
Le discovery comporte deux grandes étapes : la validation que le problème est

pertinent dans un premier temps, puis la validation de la solution que l’organisation
souhaite apporter à ce problème. Ces deux étapes s’entrecroisent tout au long du
processus.
Le principe du discovery est le même à chaque étape du processus : d’abord poser des
hypothèses, puis valider ou rejeter ces hypothèses en menant des expérimentations
avec de vrais utilisateurs (potentiels ou actuels) de votre produit, afin d’obtenir des
122
/
insights. Ce qui change à chaque étape est le type d’hypothèse et le type

d’expérimentation.
Le discovery permet essentiellement de prendre des décisions sur la direction que doit
prendre le développement produit en se basant sur des faits, des observations
validées, plutôt que des intuitions. Les insights que vous obtenez permettent de
convaincre les parties-prenantes que la direction que vous prenez est la bonne, que les
initiatives produit priorisées sont pertinentes, et que les options que vous choisissez
dans le cadre de ces initiatives permettent de répondre aux problèmes auxquels
l’organisation cherche à répondre.
Le product discovery est une étape essentielle parmi les tâches du product manager, et
elle est malheureusement souvent sous-estimée, en particulier dans les organisations
qui ont déjà scalé, et pratiquement tout le temps dans la plupart des projets des
corporates. L’absence de discovery est la cause la plus criante des projets qui ne
fonctionnent pas. Quand l’organisation est sous pression, que les ressources manquent,
qu’il faut délivrer rapidement, le discovery est souvent la première étape à être
supprimée. C’est l’assurance de livrer rapidement quelque chose qui ne sert à rien.
Le product manager et le product designer doivent sans cesse alterner entre product
discovery et product delivery. Au sein d’une équipe “normale”, il n’est pas
envisageable d’arrêter le travail de l’équipe de réalisation pendant deux semaines le
temps que le product manager sache quoi faire. Trouver le temps pour paralléliser les
deux peut être un challenge pour l’équipe, et l’organisation doit leur donner les moyens
pour le faire : dédier du temps au discovery, créer des postes de Product Researcher ou
de ProductOps pour aider les équipes…
Discovery et delivery, deux processus en parallèle et qui s’alimentent l’un et l’autre96
96
HERBIG, Tim. Product Discovery : A Practical Guide for Agile Teams (2020).
https://herbig.co/product-discovery
123
/
Le product discovery est tellement important pour les organisations les plus innovantes
que certaines ont décidé de mettre deux product managers au sein d’une équipe
produit97 : pendant qu’un des product managers est occupé sur des phases de delivery
avec l’équipe de réalisation, l’autre PM a le temps de creuser la prochaine initiative dont
il a la charge en phase de discovery. Chaque PM alterne ainsi entre discovery et delivery,
en gardant l’équipe de réalisation occupée à livrer de la valeur en production.
Dans les organisations les plus matures et les plus innovantes, le discovery concerne
tous les pans du développement produit, de la vision produit et la stratégie à adopter
pour l’atteindre, jusqu’à la couleur d’un bouton sur une page. Mettre en place du
discovery peut parfois être coûteux. Choisissez vos combats, soyez d’abord certains de
traiter le bon problème, et progressez pas à pas.
97
PAROLA, Christopher. Deux Product Managers par Impact Team. 24 décembre 2019.
https://medium.com/meilleursagents-engineering/deux-products-managers-par-impact-team-26
4aacd74a91
124
/
1 - Le cadre conceptuel du
discovery : Design Thinking et Lean
Le product management moderne et en particulier la phase de discovery sont
profondément influencés par les approches centrées utilisateurs issues du Design
Thinking et la culture test and learn du Lean Startup.
1.1 - Une approche Design Thinking

Le Design Thinking est une approche de l’innovation centrée sur l’humain et des
méthodes propres au design. Le Design Thinking peut s’appliquer à la résolution de
problèmes dans tout type de secteur et s’applique particulièrement bien à la conception
de nouveaux produits ou services, et en particulier au product management.
Le Design Thinking a d’abord été théorisé par Rolf Faste, professeur de design à
Stanford et popularisé notamment par l’agence de design IDEO basée à Palo Alto, dans
la Silicon Valley. Plusieurs versions du processus existent, mais toutes se basent sur un
ensemble de valeurs communes : empathie, créativité, co-création, itération et droit à
l’erreur. Le Design Thinking met en avant les problèmes des utilisateurs et cherche à
trouver les bonnes solutions par l’expérimentation et en assumant l’erreur, en en tirant
des enseignements pour réussir au plus vite. Ça vous rappelle quelque chose ?
Le processus Design Thinking
modèle de Design Thinking en 5 étapes de la d.school de Stanford
125
/
De nombreuses écoles existent pour théoriser le design thinking et définir les

différentes étapes. Penchons-nous sur les 5 étapes de la d.school, première école de
Design Thinking basée en Californie :
1. Comprendre (Empathize) : se mettre à la place de l’utilisateur pour comprendre

en profondeur son mode de vie, ses besoins profonds. Inclut des méthodes
d’entretiens non invasives et sans préjugés, l’immersion, le shadowing (suivre un
utilisateur sans le perturber dans son activité). Cette phase fait notamment appel
à des techniques d’ethnographie et de psychologie.
2. Définir : synthèse des enseignements de la phase précédente, décryptage de la
complexité du sujet, explicitation des problèmes à résoudre
3. Proposer des idées (Ideate) : phase de co-création et de brainstorming, pour
récolter des idées de la part de toutes les parties prenantes en encourageant les
débats. Les idées sont ensuite priorisées collectivement dans une phase de
convergence.
4. Prototyper : co-création de réalisation de mockups, de proof of concept, de
parcours utilisateurs ou de maquettes visant à tester les idées
5. Tester : tester les prototypes auprès d’utilisateurs réels. Les premières
maquettes comportent nécessairement des erreurs qu’il faut identifier au plus
vite et dont il faut ensuite tirer des enseignements.
L’objectif est d’itérer rapidement entre les phases 4 et 5 en multipliant les prototypes.
En cas d’insights venant remettre en cause les étapes précédentes, le processus permet
de retourner en arrière à tout moment (remise en cause du problème, nouvelle phase
d’idéation…).
Le processus de Design Thinking est également fréquemment représenté sous forme

de double diamant :
Design Thinking en double diamant98
98
Transform Your Business Through Design Thinking. Service Innovation & Design, 28 septembre
2014. https://sidlaurea.com/2014/09/28/transfer-your-business-through-design-thinking/
126
/
Le processus est découpé en 4 phases alternant divergence et convergence : Lors des

phases de découverte / empathie, on part sans préjugé et on diverge. La phase suivante
est convergente, pour tirer des enseignements de la phase précédente et définir le
problème. Une nouvelle phase de divergence correspond à l’idéation et la convergence
correspond au prototypage et au test. L’intégralité du processus est itérative et
circulaire, jusqu’à parvenir à une solution considérée comme répondant au problème
défini.
Le product management moderne inspiré du Design Thinking

Le design d’innovation est défini par le croisement de 3 critères qui permettent de
définir la pertinence d’une solution :
Les 3 critères du design d’innovation d’après IDEO99
● Désirabilité : Les utilisateurs désirent-ils la solution ? Résout-elle un problème

pour eux ? Leur apporte-t-elle de la valeur ?
● Viabilité : La solution apporte-t-elle de la valeur au business ?
● Faisabilité : La solution est-elle réalisable d’un point de vue technique ?
Ces 3 critères correspondent aux 4 risques théorisés par Marty Cagan auxquels le
product management doit répondre : risque de valeur et d’utilisabilité (désirabilité),
risque de faisabilité, risque de viabilité business.
On s’aperçoit également que cette démarche correspond exactement au

positionnement du product manager à l’intersection de l’UX (utilisateur), du business et
de la tech, schématisé par Martin Eriksson :
99
Qu’est-ce que le Design Thinking ?. Usabilis, 24 avril 2018.
https://www.usabilis.com/quest-ce-que-le-design-thinking/
127
/
Le product management est fondamentalement inspiré du Design Thinking. On

peut définir le product management comme la combinaison des 4 éléments suivants :
● une vision et une stratégie produit

● une démarche de discovery inspirée du Design Thinking appliqué aux
produits digitaux
● de l’analyse de données quantitatives (data)
● des techniques de réalisation et de déploiement produit communément
appelées méthodes agiles.
1.2 - Lean Startup

Le Lean Startup est un modèle de création d’entreprise ou de lancement produit
théorisé et popularisé par Eric Ries à partir de 2008 et décrit dans son livre The Lean
Startup. Le Lean Startup est inspiré du modèle Lean popularisé dans les industries
manufacturières dans les années 1990, lui-même fortement inspiré du système de
production Toyota (TPS). Le Lean Startup est de facto devenu le modèle de
management de la plupart des startups et des organisations innovantes qui réussissent.
Eric Ries part du constat que la plupart des modèles traditionnels de management
ne fonctionnent pas pour la création de produits digitaux innovants. Énormément
de temps passé au développement de ces produits est gâché, soit parce que le produit
ne sert à personne, soit parce qu’il faut énormément de temps, de remaniements et
d'itérations avant que le produit n'atteigne son objectif.
● Les grosses entreprises construisent des plans à long terme, construisent des
stratégies basées sur des études de marché et passent des centaines ou des
milliers d’heures à perfectionner un produit avant de le lancer. Il s’agit de la
méthode décrite par Marty Cagan que je reprends dans le premier chapitre de
cette thèse. Cette méthode ne peut fonctionner que sur un marché parfaitement
connu et dans un environnement stable, qui ne s’applique à aucun produit se
voulant innovant.
● A l’inverse, les startups tendent à ne rien prévoir, partir directement dans la
construction de leur produit dans une approche “just do it” et évaluer ensuite s’il
y a un marché. Il y a très peu de chances que la première version trouve son
128
/
marché, et la startup risque de se trouver à court de financements avant de

pouvoir ajuster.
Eric Ries propose aux startups une méthode pour avancer de façon scientifique
dans un environnement incertain en évitant au maximum de produire des
déchets (waste, concept cher au Lean). Eric Ries décrit une startup comme “une
institution humaine conçue pour créer quelque chose de nouveau dans des conditions
d’incertitude extrême”100. Autrement dit, n’importe quelle organisation souhaitant
réellement innover peut se reconnaître dans le modèle, que ce soit au sein d’une
startup de 3 personnes ou un groupe de 200 000 personnes.
La boucle de feedback Build Measure Learn

L’approche Lean Startup est basée sur un processus itératif et incrémental en 3 étapes :
Build, Measure, Learn ; construire, mesurer, apprendre.
1. L’organisation commence par formuler des hypothèses sur ce que souhaitent

les clients potentiels.
2. Elle construit (build) ensuite un premier produit, destiné uniquement à tester
ces hypothèses auprès clients potentiels réels
3. Elle mesure (measure) la validité des hypothèses de départ grâce aux données
recueillies en testant ce premier produit auprès de clients potentiels réels.
4. Grâce à ces mesures, l’organisation peut en tirer des enseignements, appelés
validated learnings, soit des enseignements validés avec une méthode
scientifique reposant sur de la donnée. Ces validated learnings permettent de
changer ou d’affiner les hypothèses, et de repartir dans une nouvelle boucle
build-measure-learn.
100
Talks at Google. The Lean Startup | Eric Ries | Talks at Google. Youtube : 7 avril 2011.
https://www.youtube.com/watch?v=fEvKo90qBns
129
/
Avant même de savoir quel produit il faut construire, la première question est de savoir
s’il faut construire un produit. Ou, autrement dit, si le problème vaut la peine d’être
résolu. D’où l’importance de savoir poser les bonnes questions.
“If you do not know how to ask the right question, you
discover nothing.” - W. Edwards Deming
Les hypothèses de départ ont toutes les chances d’être fausses. Le cycle a donc d’autant
plus d’intérêt qu’il peut être effectué rapidement, en quelques jours au maximum, au
départ au moins. D’où l’intérêt de mettre en place une démarche lean : supprimer tout
ce qui ne sert à rien, tout ce qui n’est pas utile à l’acquisition de ces validated learnings.
Le concept de MVP : Minimum Viable Product

Le concept de MVP est souvent mal compris, notamment dans les grands groupes
prétendant adopter une démarche de développement agile. Le MVP n’est pas la
première version d’un produit qui va être lancé en production, en faisant plus ou moins
de compromis sur la demande initiale. Le MVP est le plus petit produit qui permette
d’obtenir ces validated learnings pour valider ou rejeter les hypothèses de départ.
Il n’existe donc pas un unique MVP du produit, mais un MVP à chaque boucle
Build-Measure-Learn : à chaque fois que les hypothèses changent, un nouveau MVP est
créé, ou à minima le MVP précédent est modifié pour être adapté aux nouvelles
hypothèses.
Il existe plusieurs types de MVP, en fonction du contexte, du type de produit et de la

maturité des hypothèses formulées sur le produit.
Le MVP “écran de fumée”
Il s’agit d’un MVP utilisé pour tester un concept de départ, alors que le produit n’existe
pas du tout. C’est un test basé sur une simple campagne marketing. Le concept est
simple : afin de tester l’appétence de clients potentiels pour un produit, on crée une
simple landing page décrivant le produit, contenant un simple formulaire d’inscription
(pour une newsletter, une liste d’inscription en précommande ou simplement une
alerte). On fait ensuite de la publicité pour le produit auprès des cibles envisagées, en
utilisant des techniques classiques et peu coûteuses de marketing digital (Google Ads,
social ads, posts sur des forums spécialisés…).
Si les visiteurs viennent en nombre et s’inscrivent sur le formulaire, il y a des chances

pour que le concept intéresse et vaille la peine d’être creusé. Sinon, il faut revoir les
hypothèses de départ.
130
/
Le MVP Dropbox, ou MVP Vidéo
Le MVP de Dropbox est un cas d’école documenté par Eric Ries101 : alors que les équipes
fondatrices, essentiellement des ingénieurs, démarraient les développements du
produit, ils voulaient savoir si les clients potentiels avaient de l’appétit pour leur
concept, qui résolvait un problème dont les gens n'étaient pas conscients : la
synchronisation des fichiers entre différentes plateformes et devices.
Le CEO du Dropbox a donc créé une vidéo de démo de 3 minutes102 montrant un

produit… dont le développement commençait à peine ! Il a partagé la vidéo sur le forum
Digg, un site de curation fréquenté par des geeks. La vidéo était d’ailleurs pleine
d’easter eggs reprenant les codes de Digg. En 24 heures, le nombre de préinscriptions à
la bêta de Dropbox est passé de 5000 à 75000 personnes, preuve que le concept
pouvait trouver son public.
Le MVP concierge
Le MVP concierge consiste à d’abord répondre au besoin d’un client unique, ou d’un
petit groupe de client, complètement manuellement et sur mesure. Au fur et à mesure
que le concept prend, grâce à un peu de publicité et de bouche à oreilles, quelques
taches commencent à être automatisées, puis de plus en plus, jusqu’à devenir un
véritable produit digital.
DoorDash103 est un produit similaire à Uber Eats ou Deliveroo, leader américain de la

livraison de repas à la demande. En 2013, alors que les fondateurs peinaient à trouver
des clients pour une application qu’ils venaient de développer, ils ont entendu la
gérante d’une boutique se plaindre qu’elle recevait beaucoup de commandes et qu’elle
n’avait personne pour les livrer, qu’elle devait donc tout livrer elle-même. Sautant sur
cette idée, ils ont créé une simple page web statique décrivant leur service, les menus
de quelques restaurants de Palo Alto trouvés sur internet, sans prévenir les restaurants
concernés, et leur propre numéro de téléphone pour prendre des commandes.
Au bout de quelques jours, ils ont eu leur premier appel. Ils ont donc passé eux-mêmes
la commande auprès du restaurant concerné, sont allé la chercher pour la livrer
eux-mêmes au client. Grâce au bouche-à-oreille et à un peu de street marketing, ils ont
commencé à avoir plus de clients. Ils utilisaient Square pour facturer leurs clients,
Google Docs pour lister les commandes et Find My Friends pour suivre les chauffeurs.
Quand ils ont eu suffisamment de clients pour être convaincus que le concept délivrait
suffisamment de valeur, ils ont commencé à automatiser certaines tâches : créer leur
propre système de dispatch, créer une application mobile pour que les clients puissent
101
RIES, Eric. How DropBox Started As A Minimal Viable Product. Techcrunch : 19 octobre 2011.
https://techcrunch.com/2011/10/19/dropbox-minimal-viable-product/
102
Drew Houston. DropBox Demo. [Youtube]
https://www.youtube.com/watch?v=7QmCUDHpNzE
103
SCHMIDT, Will. How DoorDash started with a Concierge MVP. ProductDone.
https://www.productdone.com/doordash-concierge-mvp/
131
/
commander… Les investissements ont donc commencé uniquement après avoir validé
le concept, pour une prise de risque très faible !
Le MVP Magicien d’Oz
Le MVP “Wizard of Oz” est une variante du MVP Concierge. Il consiste pour la startup à
prétendre avoir développé une technologie sophistiquée, généralement un moteur
d’intelligence artificielle, alors que toutes les opérations de backoffice sont effectuées
manuellement, généralement par les fondateurs de la startup.
Lorsque la startup française Julie Desk, assistant virtuel de prise de rendez-vous, a été
créée, ses fondateurs ont prétendu avoir développé une IA capable de prendre des
rendez-vous automatiquement104. En réalité, le produit était composé uniquement
d’une landing page et d’une boite mail classique sur lesquels les fondateurs recevaient
les prises de rendez-vous pour leurs premiers clients, qu’ils traitaient manuellement. Ils
en ont profité pour contacter leurs premiers clients et comprendre plus en profondeur
leur besoin. Une fois confiant dans la validité du concept, ils ont pu débuter les
développements du vrai produit, du moteur d’intelligence artificielle à proprement
parler.
Le MVP Crowdfunding
De plus en plus populaire, le crowdfunding est un système permettant à des particuliers

de financer un projet sur la base d’un cahier des charges, d’une présentation marketing
et de la promesse d’une rétribution ou d’une récompense, en fonction de la somme
engagé, si le projet parvient à récolter les fonds nécessaires.
Dans le cas du lancement d’un produit, notamment digital, le crowdfunding permet de

tester l’appétence pour le produit sur la base de la description du concept, voir si les
gens sont concrètement prêts à payer pour un produit qui n’existe pas encore.
Exemple de plateformes de Crowdfunding : Kiss Kiss Bank Bank, Ulule, Indiegogo ou

Kickstarter.
Les 3 moteurs de croissance

Une fois les hypothèses de départ définissant la valeur du produit validées et quelques
clients acquis, l’organisation doit formuler des hypothèses de croissance, et les
éprouver via la même boucle de feedback.
Eric Ries définit 3 moteurs de croissance, chacun mesurés avec des KPI propres. Pour
croître, l’organisation doit se concentrer sur un moteur principal.
● Sticky engine of growth (moteur de croissance “collant”) : attirer les clients et les
garder à long terme. Les principaux KPI sont le taux d’acquisition de nouveaux
utilisateurs et le taux de churn (attrition). Il est particulièrement adapté aux
produits par abonnement, ou aux produits fonctionnant à l’upsell.
104
Voir FRENOVE, Anne-Sophie & FLAHAULT-FRANC, Emmanuelle. Into the French Tech. p. 53-54
132
/
● Viral engine of growth (moteur de croissance viral) : chaque client doit en attirer
de nouveaux. Le KPI principal est le coefficient viral, moyenne du nombre de
clients recrutés par chaque nouveau client. Il doit être supérieur à 1 pour croître.
C’est le moteur principal des réseaux sociaux.
● Paid engine of growth (moteur de croissance par le paiement) : les clients
paient pour le produit ou le service, arrivant essentiellement via de la publicité.
Le KPI principal est le Taux de Croissance : la différence entre la Customer Lifetime
Value (CLV), le revenu moyen généré par un client sur toute la période de
collaboration, et le coût d’acquisition client (CPA). Il s’agit notamment du moteur
principal des sites de e-commerce.
Les organisations doivent définir une cible pour les KPI correspondant au modèle choisi,
qui permettra à la startup de devenir viable. La cible atteint cette cible lorsqu’elle a
trouvé son product / market fit. La croissance devient généralement exponentielle.
Le bon moment pour faire un pivot
A force d’itérations, et lorsque l’organisation s’aperçoit qu’elle n’atteindra pas les

objectifs déterminés pour sa croissance, elle doit pouvoir pivoter. Un pivot est un
changement majeur dans la stratégie de la startup en croissance dans le but
d’atteindre sa vision105, en testant et validant de nouvelles hypothèses. En utilisant la
boucle de feedback build - learn - measure, la startup doit pouvoir réduire le temps
entre chaque pivot nécessaire, avant de tomber à cours de financement.
La complexité est d’identifier à quel moment pivoter : les dirigeants doivent être
suffisamment persévérants pour ne pas renoncer trop rapidement et modifier les
hypothèses pour améliorer le concept en cours ; mais être suffisamment lucides pour
identifier que les idées ne marchent pas aussi bien que prévues, et donc qu’un pivot est
nécessaire. Le pivot ne doit pas être considéré comme un échec : il consiste à tirer des
enseignements de ses erreurs pour améliorer et proposer un produit plus pertinent.
Le processus de croissance se fait en 3 étapes :
1. Établir une baseline grâce au MVP.

2. Expérimenter en ajustant le MVP et en itérant la boucle de feedback pour voir si
on peut améliorer les KPI par rapport à la baseline
3. Pivoter quand les expérimentations n’apportent plus d’amélioration suffisante
des KPI pour le moteur de croissance choisi.
105
Marty Cagan met en garde contre les pivots de vision (voir le chapitre dédié). Il est concevable
qu’une startup early stage puisse modifier sa vision. Pour un produit déjà partiellement établi, la
vision doit rester stable mais les pivots stratégiques permettent de changer de chemin pour
l’atteindre.
133
/
Eric Ries suggère 10 types de pivots différents :
Zoom-in pivot
Dans le produit testé, une fonctionnalité unique semble susciter l’intérêt des
utilisateurs. Le pivot consiste à construire un nouveau produit ne délivrant que cette
fonctionnalité.
Exemple : Burbn était une application de géolocalisation sociale similaire à Foursquare

mal exécutée. Parmi les très nombreuses fonctionnalités inutiles de l’application, une
seule était populaire : un système de partage de photos avec des commentaires et des
likes. Les fondateurs ont créé une nouvelle application en ne retenant que cette feature
et l’ont appelé Instagram.106
Zoom-out pivot
Le produit n’apporte pas assez de fonctionnalité et les tests suggèrent qu’il ne s’agit que
d’un maillon d’un concept plus grand qui peut générer de la valeur. De nouvelles
fonctionnalités doivent être développées pour changer le positionnement produit.
En 2003, Facemash était un site qui affichait 2 photos de personnes et l’utilisateur devait
en choisir une. L’algorithme permettait d’établir un classement des étudiantes les plus
“hot” de Harvard. Fermé au bout de moins de 24 heures, le concept est ressorti un peu
plus tard avec quelques fonctionnalités additionnelles. Et s’appelait Facebook.107
Customer segment pivot (pivot par changement de segment client)
Les hypothèses de base suggéraient de viser un segment particulier qui ne s’avère pas
intéressé, mais suscite l’intérêt d’un autre segment inattendu. Le produit est donc
adapté pour convenir parfaitement à ce segment.
Customer need pivot (pivot par changement de besoin client)
Les hypothèses considéraient un problème pour lequel pas assez de monde est prêt à
investir (du temps, de l’argent, un changement de comportement…). Mais un autre
besoin connexe est identifié et est beaucoup plus prometteur
A la fin des années 90, Confinity fournissait un système sécurisé pour envoyer de

l’argent entre utilisateurs de PDA. Le marché des PDA ne décollant pas, les fondateurs
106
GARBER, Megan. Instagram Was First Called ‘Burbn’. The Atlantic : 2 juillet 2014.
https://www.theatlantic.com/technology/archive/2014/07/instagram-used-to-be-called-brbn/373
815/
107
BARR, Sabrina. When did Facebook start? The story behind a company that took over the
world. Independent : 23 août 2018.
https://www.independent.co.uk/life-style/gadgets-and-tech/facebook-when-started-how-mark-zu
ckerberg-history-harvard-eduardo-saverin-a8505151.html
134
/
ont changé de concepts en conservant leur technologie pour faciliter le paiement en

ligne, et l’ont appelé Paypal.
Platform pivot
Passer d’une application délivrant un service à une plateforme de mise en relation, ou

l’inverse.
En 2004, Snowdevil était un site de e-commerce sans grand succès spécialisé dans le
snowboard. Mais la technologie créée pour développer le site était remarquable. Les
fondateurs ont donc proposé à d’autres boutiques d’utiliser leur plateforme pour
vendre en ligne, et ont créé Shopify.108
Value Capture pivot (pivot de monétisation)
Changer le business model, la façon dont la startup monétise son produit. Par exemple,
rendre gratuit un produit payant et mettre de la publicité… ou l’inverse.
La plupart des sites de média qui vivaient grâce à des contenus gratuits et de la
publicité passent à des modèles premium par abonnement pour accéder à un contenu
de plus grande qualité.
Engine of growth pivot (pivot de moteur de croissance)
Par exemple, une startup basée sur un modèle de croissance virale qui ne parvient pas
à attirer un nombre suffisant de nouveaux utilisateurs, mais dont la customer lifetime
value s’avère plus intéressante que prévue. Elle peut envisager de passer à un modèle
de croissance Paid.
Channel pivot (pivot de canal de distribution)
Changer de modèle pour distribuer le produit. Par exemple passer d’une vente en
magasin à une vente en ligne.
Canal+ a pendant longtemps été l’éditeur d’une chaîne de télévision accessible via un
décodeur dédié branché à la télévision, puis d’autres chaînes distribuées via des box
ADSL. Le modèle de distribution est en cours de changement profond pour se
concentrer sur une application myCanal permettant d’accéder à de nombreuses offres
(produites par Canal+ ou non) depuis n’importe quel device.109
108
How Shopify Grew From a Snowboard Shop to a $10B Commerce Ecosystem. Product Habits.
https://producthabits.com/shopify-grew-snowboard-shop-10b-commerce-ecosystem/
109
GROUSSARD, Véronique. Comment l'application myCanal est devenue le fer de lance de Canal+.
Challenges : 3 mars 2019.
https://www.challenges.fr/media/comment-mycanal-est-devenue-le-fer-de-lance-de-canal_64535
0
135
/
Technology pivot (pivot de technologie)
Une nouvelle technologie permet de mieux exécuter la vision produit, en étant moins
cher ou en délivrant de meilleures performances.
Netflix était le leader de la location de DVD à distance aux USA. Quand les technologies
réseau l’ont permis, ils ont construit la plus célèbre plateforme de streaming de films et
séries au monde.110
110
MEYER, Jule. Pivot success stories: Netflix. Nordantech.
https://www.nordantech.com/en/blog/transformation/pivot-success-stories-netflix
136
/
2 - Product Research : comprendre

les problèmes des utilisateurs
La première étape lorsqu’on veut créer un produit, ou une nouvelle fonctionnalité au
sein d’un produit, est d’abord de comprendre les problèmes utilisateurs auxquels
l’organisation souhaite répondre. En fait, cette approche n’est pas la bonne. Vous ne
devriez pas chercher à quel problème le produit devrait répondre. La situation devrait
être inversée : d’abord vous identifiez un problème, vous le comprenez, profondément.
Ensuite, quand vous avez évalué cette opportunité, vous décidez de créer un produit ou
une nouvelle fonctionnalité pour répondre au problème.
2.1 - Connaître les utilisateurs

Autrefois les organisations créaient des stratégies et des produits en commandant de
coûteuses études de marché auprès de cabinets spécialisés. Elles prétendaient créer
des produits pertinents pour les utilisateurs, sans les connaître directement. Les études
de marché sont toujours intéressantes, notamment pour obtenir des informations sur
un marché que l’organisation souhaite conquérir. Néanmoins, d’un côté elles sont
financièrement inaccessibles aux startups débutantes, d’un autre côté, elles sont loin
d’être suffisantes pour identifier les vraies opportunités d’innovation.
Pour identifier un problème à résoudre, il faut d’abord connaître les personnes que
vous souhaitez cibler. Pour obtenir des insights pertinents sur vos utilisateurs
potentiels, les organisations combinent deux disciplines :
● La recherche qualitative sur les utilisateurs, appelée User Research. Des user
researchers sont parfois dédiés à cette étape, en lien avec les équipes produit.
● La recherche d’insights quantitatifs, basé sur la data, en particulier l’activité de
vos utilisateurs dans votre produit, et autour de votre produit. C’est le domaine
des data analysts et des data scientists.
”Together, User Research and Data Science provide

complementary perspectives that mutually enhance each
other. By combining these disciplines, we can gain a holistic
understanding of multiple forms of data and mitigate the
blind spots of a single research method alone.” - Colette Kolenda, Research
Lead chez Spotify111
Les user researchers et les data analysts doivent collaborer pour obtenir un point de
vue complet sur un problème donné. Sans cette collaboration, les données qualitatives
111
KOLENDA, Colette. Simultaneous Triangulation: Mixing User Research & Data Science Methods.
Spotify Design : juillet 2019.
https://spotify.design/article/simultaneous-triangulation-mixing-user-research-and-data-science-
methods
137
/
et quantitatives risquent de fournir des insights contradictoires. Colette Kalenda

explique les principes que Spotify a mis en place pour la garantir :
● Clairement définir les objectifs de recherche, pour identifier les opportunités de

collaboration.
● Identifier des méthodes complémentaires dans les différents cadrans du
framework “What-Why”, pour contrebalancer les forces et faiblesses des
différentes méthodes.
● Implémenter ces méthodes simultanément, sur les mêmes groupes
d’utilisateurs, pour diminuer les risques d’insights contradictoires. Si des
contradictions apparaissent, elles font l'objet de recherches plus approfondies.
Le framework de discovery “What-Why” de Spotify exploitant des techniques qualitatives et

quantitatives.
Pour connaître vos utilisateurs, vous devrez sortir de votre bureau et aller sur le terrain.
Voyez l’environnement dans lequel ils évoluent. Essayez de discuter informellement
avec eux. Comprenez comment ils vivent, en particulier quand ils sont en prise avec le
type d’activité sur lequel vous souhaitez travailler. Identifiez leurs désirs, leurs pain
points, leurs objectifs, leurs motivations. Comprenez le contexte dans lequel ils
évoluent. Bref, développez de l’empathie pour votre audience. Mettez-vous dans la
position d’un design thinker.
Pour vous faciliter le travail, utilisez un type d’utilisateur précis. Ne ciblez pas “les
étudiants”, mais “les étudiants en sciences humaines de premier cycle qui habitent en
cité universitaire”. Si vous construisez une solution pertinente pour une niche, il est
probable qu’elle fonctionnera en partie pour les segments connexes. Ignorez toutes les
personnes qui ne correspondent pas exactement à votre cible idéale. Il sera largement
temps d’élargir le spectre plus tard. Concentrez-vous sur ce qui marche bien pour votre
cible, leurs besoins, et leurs challenges.
Ne négligez pas non plus d'interroger les équipes en contact avec vos clients : vendeurs,
customer success, marketing… Ils fourniront souvent des informations très utiles, que
vous irez valider sur le terrain avec les utilisateurs.
138
/
Les interviews utilisateur

Les interviews utilisateur peuvent prendre des formes très variées : interviews en
face-à-face, focus groups, interviews inopinées dans la rue…
Quelques points à prendre en considération :
● Définissez un objectif clair pour votre interview

● Mettez vos utilisateurs à l’aise, créez un rapport avec eux
● Informez-vous sur les participants avant l’enquête. Par exemple, proposez-leur
un court formulaire pour qu’ils vous fournissent des données
sociodémographiques
● Préparez vos questions à l’avance. Posez des questions ouvertes, qui provoquent
le dialogue. Anticipez les réponses possibles et préparez des questions
complémentaires, en lien avec votre objectif
● Evitez à tout prix d’induire des biais dans les réponses et les questions vagues
● Préparez plus de questions que vous pensez pouvoir en poser
● Prenez en compte les biais liés à l’environnement de l’interview
● Ne prenez pas les réponses pour argent-comptant
● Prêtez attention aux signaux faibles
● Entraînez-vous
Les enquêtes
Là encore, les enquêtes peuvent prendre des formes multiples : questionnaire par
email, enquête de rue, site intercept survey (questions posées pendant que vous
naviguez sur un site ou utilisez un produit).
Comme pour les interviews, définissez votre objectif, préparez bien vos questions,
évitez d’inclure des biais et prenez-les en compte dans l’analyse des résultats, préparez
des arbres de questions en fonction des réponses données. Privilégiez les questions
fermées, en laissant des questions ouvertes pour obtenir des verbatims. Veillez à garder
les enquêtes courtes pour éviter que les utilisateurs ne partent avant d’avoir fini.
Les journaux de bord (diary studies)

L’équipe sélectionne un panel d’utilisateurs cibles, qui acceptent de noter dans un
journal de bord pendant une période donnée (généralement une semaine) tout ce qui
concerne un sujet donné qui intéresse l’équipe, en fonction du secteur d’activité de
l’organisation. Par exemple, une entreprise de retail peut s’intéresser à tout ce qui
influence les prises de décision d’achat, en ligne et hors ligne. Une startup médicale
peut s’intéresser à toute activité qui peut avoir des conséquences sur la santé de la
personne. Le journal peut également concerner les activités autour du produit de
l’organisation, voire d’un concurrent potentiel.
L’équipe et les participants se mettent d’accord sur la forme que doit prendre le journal
de bord, la fréquence de la prise de note et sous quel format il sera fourni à l’équipe.
L’utilisateur note ses impressions, ses interactions, le contexte...
139
/
Cette phase est suivie d’une interview en face à face pour aborder toutes les questions
que l’équipe souhaite approfondir avec l’utilisateur. Une synthèse de l’étude met en
lumière les motivations des utilisateurs, leurs besoins, leurs problèmes, et tout autre
point saillant que l’équipe juge utile.
2.2 - Synthétiser la recherche utilisateur

Ces différents outils permettent de synthétiser d’une façon visuelle les insights acquis
sur les utilisateurs que cible l’organisation.
La carte d’empathie (empathy map)

L’empathy map est une synthèse visuelle de l’environnement d’un utilisateur (ou d’un
groupe d’utilisateur). Elle regroupe dans un seul tableau les informations essentielles
pour comprendre cet utilisateur :
● Son identité (en fonction des besoins) : rôle, données sociodémographiques...

● Son objectif : ses problèmes, ses activités, les décisions qu’il doit prendre…
● Ce qu’il voit : le marché, son environnement immédiat, ce qu’il lit…
● Ce qu’il dit (des verbatims)
● Ce qu’il fait : ses comportements
● Ce qu’il entend : ses relations, ses collègues, les rumeurs…
● Ce qu’il pense et ressent : ses pain points, ses peurs, ses frustrations, ce à quoi il
aspire, ses rêves, ses espoirs
140
/
La carte du parcours client (customer journey map)

Il s’agit d’un graphique détaillant les différentes étapes d’un parcours client. Il sert de
point de référence aux différentes parties-prenantes sur l’expérience du client avec un
produit, et met en lumière les difficultés que rencontre l’utilisateur, et donc les
opportunités d’amélioration.
Un exemple de customer journey map pour l’achat d’une voiture112
Chaque étape est caractérisée par plusieurs attributs :
● les points de contact du client avec le produit (publicité, boutiques, sites web…)
● les actions que le client effectue pour passer à l’étape suivante
● les motivations du client pour qu’il continue son parcours
● les questions que le client se pose lors de son parcours
● les freins qui l’empêchent de passer à l’étape suivante
● le temps qu’il passe sur chaque étape
SALAZAR, Kim. 7 Ways to Analyze a Customer-Journey Map. NN/g Nielsen Norman Group : 22
112
mars 2020. https://www.nngroup.com/articles/analyze-customer-journey-map/

141
/
Au sein de ces étapes, le parcours est représenté sous forme de courbe mettant en
lumière les étapes sans friction, et celles qui posent problèmes. Le parcours client est
souvent utilisé pour améliorer un produit existant d’une organisation. Il peut également
être utilisé par une startup, par exemple, pour identifier le moment où elle peut générer
de la valeur dans un parcours existant.
Les user personas

J’ai déjà évoqué les buyer personas dans le chapitre sur le product marketing. Le
principe ici est le même, avec des objectifs légèrement différents. Les équipes
marketing construisent des personas pour créer les bons contenus avec les bons
messages à adresser aux bonnes personnes sur les bons canaux, afin de vendre le
produit. Les équipes produit, elles, utilisent les personas pour synthétiser les
problèmes des utilisateurs potentiels ou actuels du produit, et apporter les meilleures
solutions possibles à ces problèmes au sein du produit. La différence est
particulièrement saillante pour les produits B2B : l’acheteur de la solution est rarement
la même personne que les utilisateurs de la solution. Dans la mesure du possible,
essayez tout de même d’utiliser les mêmes personas que le marketing et les équipes
produit. Chacun alimente avec les caractéristiques et les problèmes dont il a besoin.
Dans beaucoup d’organisations, les personas sont créés dans des ateliers de workshops
avec les équipes business qui projettent sur ces personnages fictifs leur vision de
l’utilisateur idéal. Évitez ces personas, ils ne servent à rien, si ce n’est à graver dans le
marbre des biais qui risquent de vous suivre pendant les phases de discovery.
Alimentez vos personas en vous basant sur les insights que vous obtenez grâce à la
recherche utilisateur et aux données produit. N’ajoutez des informations que
lorsqu’elles sont vérifiées. Inutile de préciser que Laure a 3 enfants et aime le rose, si
d’une part, ça n’apporte rien au produit (allez-vous designer des interfaces roses ?) et si
d’autre part ce ne sont pas des faits que vous avez constatés.
Utilisez les cohortes de vos outils de product analytics pour créer des personas qui ont
du sens. Les cohortes sont des groupes d’utilisateurs qui ont des comportements
communs sur un produit. Les personnes qui composent la cohorte peuvent avoir des
caractéristiques sociodémographiques très diverses, et des objectifs a priori très
différents, mais les données comportementales montrent qu’elles font sensiblement les
mêmes actions sur le produit.
Par exemple, Damien Delautier explique113 que les équipes de myCANAL ont utilisé
Amplitude pour identifier une cohorte des “amateurs de foot”. Il est probable que leurs
modes de vie soient assez disparates : urbains ou ruraux, CSP+ ou CSP-, 20 ans ou 70
ans, homme ou femme… En se contentant des personas classiques, il est probable que
l’amateur de foot n’aurait pas été identifié.
113
https://www.youtube.com/watch?v=jmXuvN2x4vM
142
/
3 - Trouver la bonne solution

Une fois que vous avez commencé à bien identifier les utilisateurs potentiels de votre
produit et cadré le problème que vous souhaitez résoudre, vous pouvez passer à la
recherche de solution. Notez que ces premières phases ne sont jamais finies. La
recherche de la bonne solution vous fournira de nouveaux insights sur les
consommateurs et vous améliorerez votre compréhension du problème, pour poser de
nouvelles hypothèses de solutions à tester.
Au fur et à mesure des itérations de discovery, les tests sont de plus en plus précis, et
les hypothèses concernent des risques différents. Au départ, l’équipe cherche
essentiellement à gérer le risque de valeur : est-ce que mon produit délivre de la valeur
au client ? Ensuite, le discovery s’attache à gérer les risques d’utilisabilité (est-ce que le
client comprend comment utiliser le produit ?) et de faisabilité (est-ce que l’équipe de
réalisation peut créer le produit ou la fonctionnalité avec les moyens à sa disposition ?).
3.1 - L’idéation : formuler des hypothèses sur la solution au

problème de vos utilisateurs
La première étape est de trouver des idées pour résoudre le problème que vous avez
identifié et le transformer en opportunité de création de valeur. Considérez chaque idée
que vous rassemblez comme des hypothèses : établissez clairement quel est l’impact
que vous souhaitez obtenir en mettant en place une idée, ainsi que des métriques qui
vont permettront d’évaluer si cet impact peut être atteint ou non.
Je vous renvoie aux chapitres sur la découverte des initiatives, et notamment à l’atelier
d’impact mapping, au design sprint, ainsi qu’à l’atelier de story mapping.
Pour formaliser les hypothèses liées à chaque idée, vous pouvez utiliser un template
comme la grille Validation Field de Tim Herbig114.
114
HERBIG, Tim. Product Discovery : A Practical Guide for Agile Teams (2020).
https://herbig.co/product-discovery
143
/
A ce stade, vous indiquerez :
● L’idée que vous souhaitez valider

● Les hypothèses (assumptions) qui doivent validées pour que votre idée puisse
fonctionner
● Les résultats business et utilisateurs (outcomes) que vous attendez de cette idée
● La priorité de cette idée (RICE, ICE…)
● Les premières expérimentations que vous comptez mener
● Les métriques que vous mesurerez dans le cadre de ces expérimentations
3.2 - Créer des prototypes pour tester vos idées

Pour tester vos idées, vous devez aller au contact des utilisateurs et tenter d’obtenir un
feedback le plus authentique possible pour pouvoir vérifier vos hypothèses. Montrer
des schémas, des wireframes et des post-its ne permet pas aux utilisateurs de se
projeter sur votre produit. C’est là qu’intervient le prototype : une simulation à moindre
coût de l’expérience que vous souhaitez fournir à vos utilisateurs.
Conformément aux principes du Lean Startup, votre prototype doit être construit sous
forme de MVP. Il s’agit d’une représentation de votre idée qui suffit à tester la validité de
vos hypothèses. Tous les efforts qui sont inutiles par rapport à ces hypothèses doivent
être évités.
Construisez votre prototype en accord avec les hypothèses que vous souhaitez tester.
Un prototype visant à tester la valeur délivrée par une idée ne prendra pas la même
forme qu’un prototype de faisabilité technique (également appelé proof of concept ou
POC), ou un prototype d’utilisabilité.
144
/
Il existe de nombreux outils pour créer des prototypes sophistiqués. Vous aurez
souvent besoin de faire appel à vos développeurs frontend pour les mettre en place.
L’avènement des outils NoCode

Une tendance nette ces dernières années est aux outils dits NoCode : un ensemble
d’outils SaaS qui permettent de créer des produits et d’automatiser des tâches
complexes sans avoir de compétences en développement, simplement en utilisant des
interfaces graphiques, de la configuration et des connecteurs natifs pour exploiter les
API proposées par ces différents outils.
Les outils de NoCode permettent de créer des produits à part entière. Par exemple la
startup Comet a créé sa marketplace de freelance avec utilisant Bubble, Zapier et
Google Sheets115.
Dans le cadre du product discovery, les outils NoCode permettent de créer des
prototypes qui fonctionnent de bout en bout. Plus question de simplement tester un
parcours utilisateur, vous pouvez également prototyper des processus internes,
générer des flux de données et des workflows qui auraient été bien trop coûteux à
développer pour un “simple” prototype.
Voici quelques exemples d’outils de NoCode. N’oubliez pas que tous ces outils
s’intègrent avec les autres, pour créer un environnement NoCode complet !
● Airtable est un des outils de NoCode les plus populaires. Il s’agit d’un outil
collaboratif hybride à mi-chemin entre tableur et base de données relationnelle,
permettant facilement de générer toutes sortes de vues et de formulaires très
simplement. Il permet de créer en quelques clics des workflows poussés grâce à
un système de triggers ingénieux, et de très nombreux templates
communautaires sont disponibles. Il peut être utilisé comme outil de gestion de
tâches (calendrier éditorial…), outil de gestion de projet, CRM… Google a
d’ailleurs récemment lancé en bêta US Tables116, un concurrent d’Airtable
parfaitement intégré à G Suite.
● Zapier, Integromat et IFTTT sont d’autres incontournables du NoCode. Ce sont
des outils qui permettent de connecter des applications entre elles en
définissant des workflows très évolués de façon très simple. En quelques clics,
Zapier vous permet de récupérer un email depuis Facebook Lead Ads (les
formulaires Facebook), stocker ces données dans une table Airtable, envoyer un
message sur un canal Slack prévenant du nouveau Leads et envoyer un email au
prospect avec Mailchimp.
● Bubble et Webflow vous permettent de créer des sites web très poussés
simplement avec une interface graphique.
● Carrd ou Landen vous permettent de créer une landing page en quelques clics.
115
Contournement audio : le podcast no-code. #3 : Charles Thomas, comet.co la success story du
no-code francophone. Spotify : novembre 2019.
https://open.spotify.com/episode/3QYRJJeNZ4PfL3E2DPEvrO
116
GLEASON, Tim. Make tracking your work easier than ever with Tables. Google Area 120 : 22
septembre 2020. https://blog.google/technology/area-120/tables/
145
/
● Adalo est le Webflow de l’application mobile. Vous pouvez créer votre propre
app sans code, et la distribuer directement sur les stores.
● Budibase est aux applications SaaS ce que Webflow est aux sites web. Grâce à
Budibase vous pouvez créer votre propre outil à destination des B2B ou de vos
utilisateurs internes, sans pratiquement avoir à coder.
● Memberstack est un outil qui permet de gérer des utilisateurs, à coupler avec
un outil comme Webflow ou Budibase.
● Mailchimp et Mailerlite sont des outils permettant de générer des mailing lists
et des campagnes marketing par email très simplement. En les connectant avec
d’autres outils, on peut se créer un écosystème de marketing automation à
moindre frais sans développeurs.
● Notion, Coda ou Miro sont des outils collaboratifs qui s’intègrent facilement
avec d’autres outils de NoCode.
● Typeform est un outil très populaire de création de formulaires, qui s’intègre
facilement avec les autres outils.
● D’autres outils de NoCode existent pour à peu près tous les usages : chatbot,
e-commerce, jeux video, intelligence artificielle, blockchain, assistants vocaux...
3.3 - Valider les hypothèses

Vous avez identifié vos utilisateurs cibles, cadré un problème auquel vous souhaitez
apporter une réponse, formulé des hypothèses (les idées) et créé un prototype pour
tester ces hypothèses. Voilà maintenant l’étape tant attendue : celle du test, pour
vérifier si vos hypothèses tiennent la route.
Reprenez la grille que vous avez élaborée à la fin de la phase d’idéation, et indiquez les
résultats et les prochaines étapes, les nouvelles expérimentations que vous souhaitez
mener.
Plusieurs méthodes qualitatives et quantitatives sont utilisées conjointement pour

valider des hypothèses.
Études d’utilisabilité
L’étude d’utilisabilité consiste à fournir à un utilisateur potentiel un prototype du
produit et à étudier la façon dont il interagit avec lui. Le processus est assez similaire à
celui des interview utilisateurs.
Une étude d’utilisabilité peut être menée dans un environnement dédié (un lab par
exemple) ou dans un environnement familier pour le participant, où le produit pourrait
être utilisé (son domicile, son lieu de travail…).
L’étude peut être modérée (une personne de l’équipe accompagne le participant dans
sa prise en main du prototype et lui pose des questions), ou non. Les études modérées
sont généralement effectuées dans l’environnement de l’utilisateur à sa convenance.
Les insights des études non modérées sont généralement beaucoup moins qualitatifs,
mais sont également plus simples à mettre en place et permettent de faire tester
beaucoup plus de monde. Ils sont souvent utilisés pour des tests d’interface. De
146
/
nombreux outils sont disponibles en ligne pour vous mettre en relation avec des
testeurs potentiels.
Dans tous les cas, les actions du participant doivent être enregistrées. L’enregistrement
permet de capter à la fois les actions de l’utilisateur avec le produit (enregistrement
d’écran par exemple) et les réactions orales et physiques de l'utilisateur.
Test concierge ou Guerilla Testing

Dans un test concierge, l’équipe choisit un lieu public dans lequel elle pense trouver des
personnes potentiellement intéressées par le concept du produit, correspondant à la
cible définie dans les phases de recherche.
Un interviewer trouve des personnes acceptant de participer au test. Il commence par

pitcher l’idée à valider, puis lui fournit le prototype à tester, pour recueillir ses réactions.
Dans un test concierge, l’entretien se termine en demandant au participant s’il serait

prêt à payer pour ce produit, et de comprendre les raisons de sa réponse.
A/B testing
L’A/B testing est une méthode d’optimisation de parcours utilisateurs qui permet
d’afficher une version différente d’un site, d’une application mobile ou d’un outil SaaS, à
des cohortes d’utilisateurs. Par exemple, la moitié des utilisateurs d’un site vont voir une
version, et l’autre moitié une deuxième version.
Pour mettre en place une démarche d’A/B testing, l’organisation doit avoir modélisé les
parcours utilisateur et être capable de mesurer les taux de conversion des éléments à
tester. Vous pouvez par exemple tester la forme, l’emplacement ou la couleur d’un
call-to-action (CTA) sur une page, et valider grâce à l’A/B test quelle version de ce CTA
convertit le mieux, celle pour laquelle une plus grande partie des utilisateurs effectue
l’action attendue. Veillez à considérer également la suite du parcours : si plus
d’utilisateurs cliquent sur un CTA pour s’inscrire à une newsletter, mais que le nombre
de personnes soumettant le formulaire reste le même, le test n’est pas concluant.
L’A/B testing est donc une technique qui permet très rapidement de formuler des
hypothèses sur l’UX et l’UI du produit, de mettre en place des tests et de les valider.
Cette technique se prête particulièrement bien à l’optimisation des interfaces front de

sites web. De nombreux outils SaaS permettent de surcharger votre site pour mettre en
place ces tests, comme AB Tasty, Optimizely ou Kameleoon. Les sites de leads ou les
sites de e-commerce font un usage extensif de l’A/B testing. Chaque changement
d’interface est A/B testé pour optimiser le parcours utilisateur.
Mettre en place de l’A/B test sur des applications mobiles, des outils de SaaS, des
systèmes embarqués (comme des bornes de tickets de transport ou des caisses
automatiques) ou même des API est plus compliqué, mais des solutions commerciales
commencent à être proposées pour n’importe quelle plateforme. Vous pouvez
147
/
également travailler avec vos propres équipes de réalisation pour mettre en place un
A/B test.
L’A/B test ne marche que si vous avez une masse critique de visiteurs sur votre produit,
et en particulier sur l’écran testé. Si vous mettez en place un test sur une page qui n’a
que 1000 visites par mois, il y a de grandes chances pour que vous ne puissiez tirer
aucun enseignement du test que vous mettez en place.
Le produit en bêta
Lorsqu’une nouvelle version majeure de votre produit est presque prête, vous pouvez
être tenté de vouloir la tester avec un nombre important d’utilisateurs : c’est l’intérêt
des versions bêta.
Les participants d’une bêta sont des utilisateurs volontaires. Ils acceptent de tester une
version potentiellement instable de votre produit. En échange, ils peuvent accéder en
avance à de nouvelles fonctionnalités qui peuvent les intéresser. L’équipe en charge de
cette bêta peut utiliser les données produit de cette version pour valider que les
fonctionnalités sont bien adoptées par les utilisateurs, et pour détecter et corriger
certains bugs compliqués à identifier sur une version de préproduction. Dans la plupart
des programmes de bêta, les clients sont incités à fournir un feedback sur leur
utilisation de cette nouvelle version. Une fois la bêta stabilisée, elle peut être déployée
comme version principale à tous les utilisateurs.
L’utilisation de versions bêta est particulièrement adaptée aux outils SaaS et aux
applications mobiles, et de façon plus générale, à tout produit au moment de livrer une
nouvelle version majeure du produit.
Tester en production
Les équipes les plus matures peuvent tester certaines idées directement en production.
Cette approche est rendue possible grâce aux techniques de continuous deployment et
aux feature toggles, qui permettent rapidement d'inhiber certains comportements qui
ne fonctionnent pas correctement, et de déployer un correctif dans les heures voire les
minutes qui suivent.
3.4 - Le Design Sprint : trouver une idée et valider un

prototype en 5 jours
Le Design Sprint est un processus de création d’innovation appliquant les principes du
Design Thinking en s’inspirant du Lean Startup. Le concept a été créé par Jake Knapp,
designer chez Google Venture, avec l’apport de ses collègues John Zaretsky et Braden
Kowitz, et formalisé dans le livre Sprint117. Il a été utilisé la première fois pour créer le
MVP de Google Hangouts.
KNAPP, James, ZERATSKY, John & KOWITZ, Braden. Sprint: How To Solve Big Problems
117
and Test New Ideas in Just Five Days.

148
/
Le Design Sprint est une méthode concrète qui permet de couvrir les étapes d’idéation,
de prototypage et de test en seulement 5 jours. Son objectif est de vérifier la validité
de concepts. Dans Sprint, les auteurs proposent des techniques pas à pas pour chaque
étape du sprint. Un facilitateur expérimenté peut essayer d’autres techniques qu’il juge
plus pertinentes, mais même un débutant peut s’essayer au design sprint en utilisant
Sprint comme un livre de recettes. Le Design Sprint est basé sur des principes de
co-création horizontale et d’intelligence collective, il favorise la créativité et l’émulation.
Cette méthode peut s’appliquer à n’importe quel sujet d’innovation, dans n’importe quel
type d’entreprise : startup ou corporate, industrie technologique ou non, services
publics… Pour la création de produits ou services, ou pour des évolutions majeures de
ces produits ou services.
Les prérequis du Design Sprint

Un vrai challenge
Le design sprint est fait pour résoudre des problèmes complexes. Apporter une
réponse à ce problème doit être un vrai bénéfice pour l’organisation. Le design sprint a
un coût important pour l’organisation : il faut mobiliser près d’une dizaine de personnes
à temps plein pendant une semaine, avoir un équipement et des locaux. Les
participants s’investissent énormément dans ce projet, il faut que le problème en vaille
la peine.
3 situations justifient particulièrement de faire un sprint :
● Un enjeu très important : un gros problème, dont la résolution va prendre du

temps et coûter cher. L’organisation ne peut pas se rattraper sur la solution à
apporter.
● Une deadline courte : le produit doit VRAIMENT sortir avant une date donnée,
qui arrive bientôt. La solution doit donc être trouvée très rapidement.
● L’équipe est bloquée : au démarrage ou plus tard dans le projet, personne ne
sait vraiment où aller, le design sprint peut permettre à tous de se redonner un
cap, voir les choses sous un angle différent.
Le problème justifiant le design sprint doit être préparé à l’avance, avant le sprint
lui-même. L’objectif est de fournir aux participants assez d'informations sur les
utilisateurs et sur le problème pour les aider dans la prise de décision : des verbatims,
des sondages, des analytics, des informations financières...
Les participants
Pour appliquer la méthodologie de façon efficace, plusieurs profils complémentaires

doivent participer au sprint. Les compétences et points de vue différents sont essentiels
pour apporter une solution globale au problème. La liste des participants dépend du
problème et de ses enjeux, et des parties-prenantes intéressées.
● Un décideur (voire plusieurs) : il faut une personne capable de prendre des

décisions qui vont engager l’entreprise ou le produit. Idéalement, le décideur
149
/
doit participer à tout le processus. S’il ne peut pas, il doit se faire représenter, et
doit vraiment être présent au moins le premier jour pour exposer sa vision du
problème, expliquer pourquoi il est important de le régler, aligner les
participants et répondre aux questions. Il doit également être présent lors des
tests, afin de voir la réaction des clients.
● Jusqu’à 7 participants incluant le décideur s’il est présent pendant tout le
processus. Il s’agit d’experts dans des domaines complémentaires qui peuvent
chacun apporter un point de vue différent sur le problème et les solutions
proposées : experts financiers, experts du client, experts techniques, experts du
design… Les profils doivent être suffisamment variés pour évaluer la pertinence
de la solution proposée par rapport aux 4 grands types de risques : valeur,
utilisabilité, faisabilité, viabilité business.
● Un facilitateur, aussi appelé Sprintmaster, responsable de l’application de la
démarche, garant des timings, résume les réunions, … Le facilitateur doit pouvoir
rester impartial. Son rôle n’est pas de proposer des idées ou de les challenger. Il
doit par contre être capable de challenger les participants sur la façon dont ils
participent au sprint, les inciter à remettre en cause leurs idées préconçues. Le
facilitateur ne peut pas être un des participants, et surtout pas le décideur. En
fonction de l’organisation, il peut être un scrum master, un facilitateur dédié, un
autre product manager, un productops, un consultant… Quelqu’un avec des
compétences en facilitation graphique est une bonne idée.
Exemples de participants : CEO, membre du Comex, CFO, business developer, designer,

développeurs, product manager,
Dans une organisation produit, le décideur est le product manager en charge du

produit (ou un Lead PM ou Product Strategist pour un nouveau produit), même s’il peut
être utile d’impliquer un membre du comité de direction en début et fin de processus.
Certains membres de la squad participent (un ou deux développeurs, le product
designer), ainsi que quelques parties prenantes externes à la squad, un PMM ou un
vendeur par exemple.
Le lieu et les équipements
En principe, le design sprint se déroule avec tous les participants dans une même pièce.
En dehors des participants, et de quelques invités, personne ne doit entrer dans cette
pièce. Un design sprint ne peut pas se tenir dans un open space ou un lieu de passage.
Les perturbations doivent être évitées au maximum. L’espace dédié doit être équipé en
outils permettant aux participant d’exprimer leur créativité, de prendre des notes, de
dessiner des schémas : tableaux blancs, post-its, feutres de plusieurs couleurs, feuilles
de papier et crayons, lego… utilisez ce qui pourra être utile à l’idéation et à la réalisation
du prototype.
Le processus requiert une participation active et une attention constante de tous les
participants, des horaires trop longs deviennent contre-productifs. Pour cette raison, les
ordinateurs et les téléphones sont interdits, pendant toute la session, dans l’espace où
se déroule le sprint. Sauf pour travailler sur les maquettes bien sûr. Si quelqu’un doit
prendre un appel urgent, vérifier ses mails, il doit sortir de la pièce.
Avec la crise du COVID-19, le paradigme change un peu… Il devient très compliqué de

réunir plusieurs personnes pendant 5 jours dans un même lieu confiné. De plus en plus
150
/
d’entreprises et de cabinets de conseil cherchent à adapter la méthode pour réaliser

des design sprints à distance118. Le plus difficile est de conserver l’attention des testeurs
et participants et percevoir les signaux faibles des autres participants.
La semaine de Design Sprint

Le design sprint est un processus contraint de 5 jours, dans la même semaine, du lundi
au vendredi, pour conserver le momentum. Les horaires et les sessions sont également
“timeboxed” : chaque jour dure 6 heures, 3 heures le matin et 3 heures l’après-midi, avec
une pause en milieu de session et une pause déjeuner.
Le Design Sprint, un processus codifié en 5 semaines
Lundi : Problem, Map, Experts and Target
Le premier jour sert à cadrer le problème, prendre connaissance des éléments clés et
décider de l’objectif du sprint.
1. Expliquer le concept du sprint et le déroulement de la semaine, faire les

présentations.
2. Se mettre d’accord sur le problème, définir un objectif à long terme. Dans une
organisation produit, cet objectif doit être aligné avec la stratégie produit. Cette
session doit être courte, 30 minutes maximum. Si l’objectif n’est pas clair, il
s’affinera pendant les sprints.
3. Définir les grandes questions auxquelles le sprint devrait répondre. Le
facilitateur challenge les participants qui doivent trouver les questions qui font
mal.
4. Faire une carte du problème : les clients, les acteurs clés, le parcours utilisateur
et comment il interagit avec le produit, jusqu’à atteindre l’objectif.
5. Interroger les experts : ceux qui participent au sprint, et d’autres experts invités
qui viennent fournir un éclairage. Cette session a pour objectif d’éclairer tous les
Les auteurs de Sprint proposent ici quelques idées, outils et méthodes pour animer un design
118
sprint à distance : https://www.thesprintbook.com/remote

151
/
participants sur la stratégie (et c’est LE moment où le décideur doit être présent),
les clients, le fonctionnement du produit, et toutes les pistes et travaux qui ont
déjà pu être étudiés sur le problème. Prendre des notes, corriger la carte ou les
problèmes si besoin, identifier les problèmes soulevés par les experts (sous
forme de post-its) et voter sur les problèmes les plus prometteurs.
6. Choisir une cible : un client et un évènement sur la carte. C’est le rôle du
décideur, et cette cible définit le point d’attention de tout le reste du sprint. Le
décideur peut demander de l’aide aux autres participants. Choisir ensuite une
des grandes questions, en rapport avec la cible. Vous avez l’objectif du sprint.
Un exemple de carte avec une cible choisie par le décideur119
Mardi : Sketch
Le 2e jour est celui de l’idéation : à l’aide de tous les inputs obtenus, chaque participant
réfléchit de son côté pour fournir une proposition pour gérer une des étapes de la
carte.
1. Démos éclairs : tous les participants doivent choisir et présenter quelques outils
inspirants pour la résolution du problème : sites web, applications, outils SaaS…
Les participants doivent essayer de sortir de leur industrie. Le facilitateur prend
des notes sur les bonnes idées identifiées par le candidat.
2. Sketch : Les participants se répartissent les différentes étapes de la carte qui
sont liées à la cible (plusieurs participants peuvent choisir le même élément).
Pendant l’après-midi, chaque participant crée une ébauche de l’étape qu’il a
choisie, selon un processus codifié :
○ Une première étape de prise de notes, en reprenant tous les éléments
déjà accumulés par l’équipe : l’objectif, la cible, la carte, les notes prises
durant les présentations des experts et les bonnes idées des démos.
○ Ensuite chaque participant commence à sketcher des idées, pendant 20
minutes
○ Il choisit son idée la plus forte, et la décline en 8 variations, en 8 minutes.
119
Sprint, p. 86.
152
/
○ Enfin il sketche sa proposition finale, pendant environ 1h à 1h30
Le sketching en 4 étapes120
Mercredi : Decide
Le 3e jour, les participants choisissent l’idée à prototyper
1. Grâce à un processus codifié les participants vont choisir les sketchs à utiliser
pour le prototype. D’abord, chaque participant indique silencieusement les
éléments qu’il aime dans chaque proposition, puis une très courte discussion a
lieu sur chaque sketch. Ensuite, les participants indiquent le sketch qu’ils
préfèrent, mais au final la décision revient au décideur, qui peut choisir de 1 à 3
sketchs. Ils seront utilisés comme base du prototype. Les autres ne sont pas
jetés à la poubelle, leurs bonnes idées peuvent toujours être utilisées.
2. Si plusieurs sketchs ont été choisis, l’équipe définit s’ils peuvent être rassemblés
dans un unique prototype, ou s’ils vont devoir créer plusieurs prototypes en
compétition. S’il y en a plusieurs, ils choisissent un faux nom de marque pour
chaque prototype.
3. Les participants créent ensuite le storyboard pour le futur prototype : un
enchaînement logique de 10 à 15 panneaux racontant une histoire cohérente.
120
Sprint, p.109
153
/
Le storyboard d’une fonctionnalité “bot team” de Slack121
Jeudi : Prototype
Le 4e jour est dédié à la création du prototype en tant que tel. L’objectif est de créer un
produit qui a l’air réel, en enlevant toutes les complexités possibles. Supprimez tous
les déchets (le waste du Lean), qui ne servent à rien dans l'acquisition de
connaissances : les business rules, les cas limites, le stockage d’information, les
écrans inutiles... Le prototype ne sera qu’une interface, l’objectif est vraiment de créer
un parcours utilisateur qui sera testé le jour suivant.
Les auteurs de Sprint dégagent 4 grands principes sur le prototype :
● N’importe quoi peut être prototypé : site web, logiciel, hardware, service,
packaging, recette de yaourt122…
Sprint, p.150
121
cf. Zenika TV. L’histoire du Design thinking chez Danone, une histoire de recette en évolution.
122
Youtube : 12 février 2020 [vidéo] https://www.youtube.com/watch?v=8kksFkOW3Rs sur la

démarche design thinking chez Danone, incluant du prototypage rapide de produits alimentaires
154
/
● Les prototypes sont jetables. Ne vous attachez pas, ne cherchez pas à faire
quelque chose que vous réutiliserez techniquement. Ils servent à valider une
idée.
● Construisez le minimum pour apprendre, rien de plus.
● Le prototype doit sembler réel. Plus les utilisateurs ont l’impression que le
produit testé est réel, moins ils ont besoin d’imaginer, plus leurs réactions seront
authentiques.
Le processus de prototypage suit 4 étapes :
1. Choisir le bon outil en fonction du prototype : un outil de type InVision ou

même Powerpoint pour des écrans, une mini-pièce de théâtre pour un service,
une imprimante 3D ou un faux packaging pour un objet...
2. Diviser pour régner : assigner les rôles aux membres de l’équipe :
○ 2 créateurs ou plus, qui vont créer chaque élément du prototype
(développeurs, designers…)
○ un “aggrapheur” (stitcher), dont le rôle est d’assurer la cohérence des
éléments du prototype entre eux
○ un rédacteur qui va s’occuper du messaging du produit (un profil
marketing par exemple)
○ un collecteur d’actifs ou (asset collector) ou plus, dont le rôle est de
rassembler les ’éléments qui vont être utilisés par les créateurs : photos,
typos, icônes… et tout élément déjà créé par l’entreprise qui peut être
réutilisé
○ un interviewer, qui va créer le script pour le lendemain, sans participer à
la création du prototype pour éviter d’être investi émotionnellement.
Idéalement quelqu’un à l’aise avec des techniques de nudge.
3. Assembler les éléments : la tâche principale du stitcher. Dès que les créateurs
finissent un élément, il l’assemble avec le reste en s’attachant aux détails :
s’assurer que les typos, les textes, les noms, les dates, les icônes... sont
cohérents. Plus le prototype est cohérent, moins les testeurs auront à l’esprit
qu’il n’est pas réel.
4. Galop d’essai : tester le prototype quand il est terminé, vérifier que tous les
éléments du storyboard sont bien inclus. Adapter et corriger si nécessaire. Le
test est présenté par le stitcher, et le public principal est l’interviewer, qui n’a pas
participé à la création du prototype. Il doit devenir familier avec le prototype.
S’il y a plusieurs prototypes, tout le monde participe à la création de chacun.
Vendredi : Test
Dernier jour, le grand jour ! L’équipe va pouvoir présenter le prototype à des utilisateurs
réels, observer leurs réactions et apprendre. L’objectif est bien de voir comment
l’utilisateur réagit, pas de lui demander du feedback, pas de lui demander ce qu’il
changerait.
Les interviews : prévoir 5 interviews d’une heure chacune dans la journée, les testeurs
auront été recrutés à l’avance. Ce sont des utilisateurs finaux, des clients existants ou
155
/
potentiels. Pas de faux clients internes. L’interviewer est à la manœuvre. L’interview se

passe dans un espace dédié, au calme, où le testeur pourra se sentir à l’aise. Les autres
membres de l'équipe y assistent sans perturber l’utilisateur, via une vitre sans teint, ou
une vidéo à distance par exemple, et prennent des notes. Chaque interview suit un
processus précis.
1. Accueil : mettre à l’aise l’utilisateur, expliquer le contexte et le processus de

l’interview. S’il y a des formalités juridiques, elles ont lieu à ce moment.
2. Connaissance de l’utilisateur : poser quelques questions sur le testeur, ce qui
l’intéresse, ses activités en lien avec le type de produit testé… Cette étape permet
de le mettre à l’aise, et de cerner certaines caractéristiques qui peuvent s’avérer
utile lors de l’interprétation des réactions.
3. Introduction du ou des prototype(s) : présenter rapidement le prototype en
incitant subtilement le testeur à fournir les feedbacks les plus honnêtes
possibles.
4. Prise en main détaillée du prototype : Laisser le testeur réagir avec le
prototype en le guidant le moins possible. Par contre l’interviewer doit poser des
questions pour amener le testeur à réagir : “qu’est-ce que c’est ?”, “que
pensez-vous de… ?”, “vous cherchez quelque chose ?”... Le testeur doit toujours
commenter ce qu’il fait, réagir. Cherchez aussi les signaux faibles.
5. Debrief rapide : Poser quelques questions finales pour avoir une réaction
globale de la part du testeur : son sentiment, comment décrire le produit à un
ami, des points de blocage.
Une équipe observant une interview de design sprint123
Pendant les interviews, le reste du groupe assiste au test ensemble, et tous participent
à la prise de note en commun, à l’aide de post-its, de feutres effaçables… Une fois les 5
interviews finies, toute l’équipe se retrouve autour du tableau avec toutes les notes, et
cherche individuellement des motifs qui se répètent, des patterns, puis partage ses
123
KNAPP, Jake. The product design sprint: validate (day 5). GV : 7 mars 2013.
https://library.gv.com/the-product-design-sprint-validate-day-5-761292b20d05
156
/
réactions. Ensuite elle revoit les objectifs long-terme et les questions définies le lundi et
cherche les réponses aux questions.
Et après le sprint ?
Le facilitateur doit fournir un compte rendu de la séance à tous les participants : photos,
vidéos, prototypes, prises de notes… Pour que les enseignements du sprint continuent
à servir.
Ensuite, au décideur de choisir les prochaines étapes. Vous pouvez refaire un design
sprint pour améliorer votre prototype et tester d’autres hypothèses, ou utiliser d’autres
techniques de discovery.
3.5 - Regrouper et affiner les résultats

Afin de synchroniser tous les acteurs intervenant sur le product discovery (PM, product
designer, équipe de réalisation, data analysts, product researchers, product ops,
marketing, ventes…), veillez à avoir un outil centralisé dans lequel vous indiquez ce que
vous connaissez de vos utilisateurs, le problème que vous avez choisi de traiter, les
idées sur lesquelles vous travaillez et les hypothèses que vous souhaitez tester, ainsi
que toutes les informations, insights ou validated learnings que vous avez déjà
obtenues.
Créez des cartes de votre problème, de vos parcours utilisateurs, les processus, les
réseaux... Détaillez le processus de discovery que vous souhaitez suivre, et indiquez là
où vous en êtes. Utilisez un tableau physique ou un outil de travail collaboratif, comme
Miro ou Notion par exemple.
Une fois que vous avez obtenu des insights sur vos hypothèses, définissez quelles sont
les prochaines étapes :
● Il y a de très grandes chances pour que vos premiers tests ne soient pas
concluants, que vos hypothèses ne soient pas vérifiées. Vous avez tout de même
appris énormément de choses, et vous avez évité de développer un produit ou
des fonctionnalités qui n’auraient pas marché. Retournez à la phase d’idéation.
Formulez de nouvelles hypothèses sur la base de ces enseignements et
testez-les.
● Certaines de vos hypothèses ont été vérifiées : itérez sur votre prototype,
cherchez à valider de nouvelles hypothèses. Si vous savez maintenant que votre
idée peut fournir de la valeur à vos utilisateurs, cherchez à vérifier si le produit
est faisable en élaborant un prototype plus complexe avec votre équipe de
réalisation. Cherchez également à rendre le produit utilisable en travaillant les
interfaces avec votre product designer.
● Une fois que vous avez validé suffisamment d’hypothèses, passez l’idée en phase
de delivery : travaillez sur le détail des fonctionnalités et ajoutez-les à votre
backlog.
157
/
Veillez à garder des cycles de discovery courts, et gardez à l’esprit que votre objectif est
de livrer un produit ou de nouvelles fonctionnalités en production.
Le discovery n’est jamais fini. Adoptez une approche de continuous discovery : lorsque
vous avez fini de traiter un sujet et que vous êtes prêts à passer en phase delivery,
amorcez une nouvelle phase de discovery en parallèle : continuez à trouver et tester de
nouvelles idées sur l’initiative en cours, afin d’atteindre vos objectifs, ou passez à la
découverte de l’initiative suivante.
158
/
V - Le Delivery : développement et déploiement du produit
Partie V
Le Delivery :
développement et
déploiement du
produit
Vous avez votre vision et vos objectifs produits. Ces objectifs ont été priorisés au sein
d’un roadmap basée sur les outcomes. Vous connaissez vos utilisateurs, vous avez
identifié et priorisé les initiatives que vous souhaitez poursuivre. Vous avez validé des
hypothèses grâce à des prototypes, et vous savez maintenant ce que vous souhaitez
mettre en place. Il est temps de construire le produit techniquement, créer les lignes de
code qui constituent le nouveau produit, ou les nouvelles fonctionnalités d’un produit
existant, puis les pousser en production pour que l’utilisateur puisse en bénéficier : il
s’agit du delivery.
159
/
Au sein des organisations utilisant Scrum par exemple, cette phase est celle pendant
laquelle le Product Owner travaille avec les équipes de réalisation. Rappelons que dans
une organisation produit, le rôle de product owner devrait être assuré par le product
manager.
Dans les faits, discovery et delivery ne sont pas deux phases strictement séparées dans
le temps. Les deux avancent en parallèle. Lorsque le product manager et le product
designer explorent les options possibles pour résoudre un problème, l’équipe de
réalisation est sollicitée pour construire des prototypes et donner leur avis sur la
faisabilité technique notamment. Lorsque les équipes de réalisation développent de
nouvelles fonctionnalités, le product manager et le product designer analysent les
retours utilisateurs grâce à des méthodes qualitatives et quantitatives, et ajustent leurs
hypothèses au fur et à mesure.
160
/
1 - Prioriser le backlog
Dans le chapitre sur les roadmaps, je vous ai donné quelques méthodes pour prioriser
les initiatives à mettre sur la roadmap. Lorsque l’initiative entre en phase de delivery
elle doit être découpée en éléments plus fins : epics, user stories, job stories, tâches,
etc. saisies dans un backlog et priorisées.
1.1 - Qu’est-ce qu’un backlog ?

Le backlog est la liste de toutes les tâches que l’équipe de réalisation doit effectuer
pour délivrer les initiatives produits. Il s’agit de l’outil principal du product manager
dans la phase de delivery.
Le backlog est l’endroit où le product manager va regrouper tous les besoins identifiés
pour mener à bien les initiatives en cours, et les prioriser de façon à ce que l’équipe de
réalisation sache clairement sur quelles tâches travailler en premier.
Il n’y a aucune règle sur la façon de représenter le backlog, ni sur ce qu’il doit contenir. A
l’équipe de choisir les outils et artefacts avec lesquels elle est le plus à l’aise. Souvent,
son organisation et son contenu dépendent de la méthodologie adoptée. Un backlog
Scrum et un backlog Kanban ne sont pas exactement les mêmes.
Les outils de backlog

Le backlog se matérialise généralement dans un outil de management visuel. Si tous les
membres d’une équipe se trouvent sur le même site, le backlog peut être un tableau
physique, dans lequel les différentes tâches sont représentées sous forme de post-its.
Le backlog physique a plusieurs avantages : il s’adapte parfaitement aux besoins de
l’équipe ; il peut être placé au milieu d’un espace partagé de l’équipe et devenir très
concret, notamment lors de réunions communes où toute l’équipe se réunit devant le
backlog.
un exemple de backlog physique
161
/
Le backlog peut également être virtuel, dans un simple outil de tableur pour les plus
basiques, ou grâce à des outils collaboratifs de gestion de tâche comme Trello, ou des
outils plus poussés comme Asana, Hive, Monday, Airtable, ou le très populaire JIRA. En
fonction de leur sophistication, ces outils permettent de mettre en place des vues et des
workflows adaptés aux besoins de l’équipe, de s’interfacer nativement avec d’autres
outils et de fournir des rapports agiles en standard.
Exemple de backlog dans JIRA
Que contient un backlog ?

Les équipes sont libres de gérer les éléments du backlog de la manière dont elles
l’entendent. L’essentiel est que ses différents membres s’entendent sur une définition
commune de ces éléments, et se mettent d’accord sur les prérequis pour qu’un
élément du backlog puisse être pris en charge par l’équipe de réalisation.
La plupart des équipes procèdent généralement à une estimation de la charge des

éléments du backlog : ils attribuent généralement un certain nombre de points à
chacun de ces éléments. Les points ne correspondent pas à un nombre de jours ou
d’heures de travail, mais permettent de comparer ces différents éléments. Si deux
éléments sont estimés à 5, la charge de travail globale de l’équipe pour les réaliser est
sensiblement la même. De la même manière, un élément à 8 points sera probablement
plus compliqué et long à développer qu’un autre élément à 2 points.
Cette estimation permet au PM d’avoir une estimation de ce qui peut être livré en un
temps donné, en considérant que sur une période donnée, le nombre de points délivrés
par l’équipe est sensiblement le même (voire s’améliore quand l’équipe gagne en
maturité). En estimant l’ensemble des éléments nécessaires à la réalisation d’une
première version d’une fonctionnalité, le PM peut avoir une bonne idée du moment où
cette version sera prête.
162
/
Certaines équipes plus matures se passent des estimations. C’est notamment le cas
lorsque l’équipe estime que l’impact prime sur le temps, et qu’un élément porteur de
valeur doit de toute façon être réalisé. A vous de voir comment vous organiser.
La description des fonctionnalités : les user stories
Les user stories viennent à la base de littérature sur l’Extreme Programming. Elles
étaient traditionnellement décrites sur un simple post-it décrivant un scénario que
l’équipe souhaite mettre en place dans le produit.
Elles sont généralement constituées d’une phrase courte, à laquelle s’ajoutent tous les
éléments essentiels à la réalisation de cette story : designs, business rules, scénarios
de test... Lorsqu’une user story entre dans le cycle de développements, ses détails
doivent être suffisamment précis pour que l’équipe sache ce qu’elle doit réaliser. La
rédaction d’une story est un travail collaboratif entre les différents membres de
l’équipe produit. Les QA en particulier interviennent généralement dans la phase de
rédaction pour travailler avec le product manager et le product designer pour décrire
les différents tests que les développements devront passer pour que la story soit
validée. Elle n’est pas nécessairement une spécification détaillée, le PM pouvant donner
une marge de manœuvre aux développeurs sur certains aspects de la réalisation.
La communauté agile préconise généralement qu’une user story suive les critères
INVEST :
● Indépendante : éviter au maximum les dépendances entre deux stories qui

doivent être traitées simultanément par l’équipe de réalisation.
● Négociable : les détails de la story doivent pouvoir être discutés et négociés avec
l’équipe de réalisation, notamment pour que l’équipe puisse proposer des
solutions techniques plus simples.
● Générer de la Valeur : une story doit être orientée outcome et apporter de la
valeur au business et/ou à l’utilisateur.
● Estimable : l’équipe de réalisation doit pouvoir fournir une estimation fiable de la
charge de travail pour réaliser la story
● Petite (Small) : les équipes de réalisation doivent pouvoir la finir dans un temps
suffisamment court pour obtenir un feedback rapide sur le travail réalisé et
ajuster dans une itération suivante si besoin.
● Testable : l’équipe doit pouvoir déterminer des cas de test pour valider que la
story a été correctement réalisée.
La user story est généralement décrite sous la forme suivante :
As a <type d’utilisateur> I want to <action> so that <résultat espéré>

En tant que <utilisateur> je veux <action> afin de <résultat espéré>
Exemple : en tant que client, je veux avoir le choix dans le mode de paiement afin
d’utiliser celui qui me convient le mieux.
163
/
Dans certains cas, la job story, plus orientée sur une situation dans le produit, peut
s’avérer plus pertinente.
When <situation> I want to <action> so I can <résultat espéré>

Quand <situation> je veux <action> afin que je puisse <résultat espéré>
Exemple : quand une commande est soumise, je veux voir un message d’alerte afin que
je puisse éviter de passer une commande deux fois.
Dans une logique behaviour-driven development, la story peut être décrite sous
forme de parcours utilisateur, dans un langage appelé gherkin.
Given <situation initiale> when <évènement> then <résultat>

Etant donné <situation initiale> quand <évènement> alors <résultat>
Exemple : étant donné un client qui vient de passer une commande, quand le client
essaye de passer la commande une nouvelle fois dans la minute qui suit, alors un
message d’alerte s’affiche pour demander au client de confirmer s’il souhaite passer la
commande une nouvelle fois.
Les Epics pour organiser le backlog
Lorsque le backlog est complexe, les stories sont généralement regroupées au sein de
grandes user stories appelées epics. Là où les stories doivent être assez petites pour
être réalisées rapidement, une epic peut être bien plus grosse et nécessiter plusieurs
itérations pour être livrée. Une epic est une sorte de macro-story, un découpage
intermédiaire entre l’initiative produit et la story.
Par exemple, dans le cadre d’un atelier de story mapping, les epic peuvent
correspondre à chaque étape du parcours client sur le produit.
Les autres éléments du backlog
Les bugs font généralement partie du backlog. Le rôle du PM est de prioriser le travail
de l’équipe de réalisation pour livrer le plus de valeur : si la correction d’une anomalie a
plus de valeur que la création ou l’amélioration d’une fonctionnalité, alors c’est à lui de
la remonter dans le backlog pour que l’équipe de réalisation s’en empare.
Les tâches techniques font généralement également partie du backlog. Néanmoins, il

peut parfois être compliqué pour le PM de prioriser certaines tâches techniques. Le
risque est que le PM néglige ces éléments pour privilégier des éléments qui portent une
valeur business ou client plus directe, compromettant à moyen terme la stabilité du
produit ou sa maintenabilité. Il existe principalement deux grandes stratégies pour
gérer ces tâches techniques :
● L’équipe de réalisation explique clairement la valeur de ces tâches techniques,

par exemple en décrivant le risque à ne pas faire. Si le PM est suffisamment
sensible à ces problématiques, cette méthode peut fonctionner.
● La seconde méthode est d’allouer un temps défini à l’équipe de réalisation pour
travailler de façon continue sur ces améliorations techniques. Ce n’est plus le PM
164
/
qui priorise ces tâches, mais le Lead Dev, ou bien l’équipe de réalisation
collectivement.
Dans certains cas, la réalisation d’une fonctionnalité comporte des inconnues :

faisabilité technique, utilisation d’une nouvelle technologie, découpage d’une story trop
grosse pour être traitée en une seule fois… Pour pallier ce problème, certaines équipes
ont recours à des spikes : des tâches de recherche technique par l’équipe de réalisation,
qui servent généralement à apporter les précisions nécessaires pour qu’une story
puisse être réalisée. Plutôt que d’estimer un spike sur la base de points nécessaires à sa
réalisation (une recherche peut durer très longtemps), l’équipe “timeboxe” cette tâche,
en définissant un nombre d’heures ou de jours qu’elle va passer pour effectuer cette
recherche.
Certaines équipes ajoutent également au backlog les tâches effectuées par l’équipe de
réalisation dans le cadre du discovery (participation à des interviews utilisateurs,
création de prototypes, ateliers d’idéation…). Avant d’ajouter un élément au backlog,
réfléchissez simplement à la raison pour laquelle vous le faites. Un backlog n’est pas
une liste exhaustive de ce que les membres de l’équipe doivent faire, ce n’est pas un
planning d’équipe ! Tout ce qui est dans le backlog doit pouvoir être priorisable par le
PM (ou le Lead Dev pour les tâches techniques). N’allez surtout pas y ajouter vos rituels
agiles, ou les vacances des développeurs...
1.2 - Quels outils pour prioriser le backlog ?

En ayant mené des ateliers de discovery, le PM a généralement une bonne idée des
fonctionnalités à développer, des hypothèses à tester en production, et des options à
prioriser. Néanmoins, il arrive qu’il ait besoin de faire intervenir d’autres personnes
dans cette priorisation, soit parce qu’il a un doute et souhaite obtenir d’autres avis, soit
parce qu’il doit emporter l’adhésion de parties-prenantes par exemple.
Il existe de nombreuses méthodes pour prioriser les éléments d’un backlog, certaines
pouvant être communes avec la priorisation d’une roadmap. J’en expose ici
quelques-unes, sans prétendre être exhaustif. Dans tous les cas, le PM reste
responsable de l’atteinte des objectifs de la squad, et c’est lui qui doit pouvoir prendre
la décision finale sur les priorités.
Le story mapping
Le story mapping est un outil du product management qui permet de valider des
parcours clients et de classer et prioriser les fonctionnalités d’un produit grâce à un
atelier dédié, inventé par Jeff Patton et documenté dans le livre éponyme124. Le story
mapping a été créé pour cadrer la création d’un nouveau produit, mais il peut
également être utilisé pour cadrer les nouvelles fonctionnalités à créer dans le cadre
d’une ou plusieurs initiatives produit.
User Story Mapping : Story mapping is a better way to work with agile user stories. Jeff Patton &
124
Associates. https://www.jpattonassociates.com/user-story-mapping/
165
/
L’atelier de story mapping est généralement animé par un facilitateur neutre (scrum
master, coach agile…) et fait intervenir tous les membres de la ou des squad(s)
concernée(s), ainsi que les parties-prenantes business du produit.
Au début de l’atelier, le PM présente le problème que l’organisation cherche à résoudre,

les personas concernées par l’atelier, et l’objectif de chacun des persona dans le cadre
du produit à travailler.
● L’atelier commence par la création de la “big picture”. Pour chaque persona, en

commençant par le plus important, les participants définissent les grandes
activités qu’il doit effectuer pour atteindre son objectif, sous forme de flot de
narration.
○ Dans le cadre d’un site de e-commerce, ces activités peuvent par exemple
être “aller sur le site web”, “identifier un produit”, “ajouter un produit au
panier”, “valider le panier”, “recevoir le produit”.
● Ces activités sont ensuite divisées en tâches de haut niveau.
○ Par exemple l’étape “valider le panier” peut être divisée en “accéder au
panier”, “valider le panier”, “saisir les informations de livraison”, “saisir les
informations de paiement” et “paiement”.
● Chaque tâche de haut niveau est à son tour divisée en tâches plus simples. Les
participants cherchent des variations possibles pour chaque tâche,
commencent à penser aux données et aux sources de données concernées et
aux éléments de l’interface, pensent aux exceptions et erreurs de parcours
possibles.
○ Par exemple concernant l’étape “saisir les informations de livraison” les
participants vont penser aux différents champs de formulaire nécessaires
(et aux éventuelles variations entre formulaire simple ou plus complexe),
à la possibilité d’avoir plusieurs adresses de livraison enregistrées dans
un compte client, à la gestion des différents modes de livraison et des
différents fournisseurs…
● Les participants priorisent ensuite les différentes tâches relatives à chaque
initiative, et les classent en releases cohérentes. Toutes les tâches de haut niveau
ne sont pas nécessairement représentées dans chaque release.
○ La première release en particulier doit contenir toutes les étapes
nécessaires pour pouvoir lancer le produit ou la fonctionnalité concernée,
et ne contenir que ces étapes.
○ L’objectif ici est de délivrer la fonctionnalité minimum pour fournir de la
valeur à l’utilisateur et obtenir du feedback aussi vite que possible pour
améliorer le produit. On parle de minimum marketable feature (MMF).
En fin d’atelier, on obtient un livrable sous forme de tableau de ce type :
166
/
exemple de livrable d’un atelier de story mapping.125
Le story map permettra d’alimenter facilement le backlog : les initiatives ou les tâches
de haut niveau constitueront les epic du backlog, tandis que les tasks seront converties
et détaillées en user stories. Les releases pourront être alignées avec ce qui a été défini
dans pendant l’atelier, reste aux équipes à prioriser l’ordre de développement au sein
d’une release.
Avantages du story mapping
Le story mapping permet de s’assurer que le développement produit est orienté sur la
production de valeur aux utilisateurs et la constitution de releases logiques pour
délivrer cette valeur. Cet outil permet d’identifier les user stories les plus pertinentes
pour le périmètre envisagé, en travaillant sur les différentes variations possibles pour
répondre à un besoin donné et en sélectionnant celles que l’organisation souhaite
expérimenter en premier. Si l’atelier est bien fait, l’approche MMF permet de
développer un produit avec une approche semblable à celle du Lean Startup, qui
consiste à délivrer des expériences minimales pour valider des hypothèses grâce à des
cycles de développement très courts. En impliquant l’ensemble de l’équipe et les
parties-prenantes, cet atelier permet également d’emporter l’adhésion de tous les
acteurs sur les releases à venir.
Inconvénients du story mapping
L’atelier prend du temps, au moins une demi-journée, à mobiliser équipe et business.

Le story mapping est essentiellement centré sur la valeur utilisateurs, et ignore de
nombreuses autres contraintes que le PM doit prendre en compte : complexité de
125
Comment organiser des ateliers de Story Mapping ? Hubvisory : 14 janvier 2020.
https://hubvisory.com/blog/comment-organiser-des-ateliers-de-story-mapping/
167
/
réalisation, valeur business, impact sur les objectifs stratégiques… Le story mapping est
un exercice à mi-chemin entre la priorisation de la roadmap et la priorisation du
backlog, et peut ne pas être adapté en fonction des processus mis en place pour la
gestion du produit. Dans tous les cas, le PM doit garder à l’esprit l’atteinte des objectifs
stratégiques, et les résultats du story mapping peuvent parfois diverger avec ces
objectifs.
La méthode MoSCoW
MoSCoW est l’acronyme de “Must, Should, Could, Won’t”. Le principe est très simple : il
suffit de réunir les différents stakeholders du produit, et de les faire voter pour répartir
collectivement les initiatives dans 4 groupes :
● Must : ce sont des initiatives obligatoires, qui sont indispensables pour atteindre
l’objectif business donné.
● Should : ces initiatives ont un intérêt moindre, mais restent importantes. Elles
sont prometteuses pour la livraison de valeur, mais peuvent éventuellement
attendre une release suivante.
● Could : la valeur de ces initiatives est incertaine. Elles pourraient éventuellement
être creusées si elles sont simples à implémenter et si elles ne présentent aucun
risque.
● Won’t : ces initiatives ne semblent pas présenter un intérêt suffisant pour qu’on
investisse des ressources, elles ne permettent pas d’atteindre l’objectif
déterminé par le management. Elles sont soit écartées, soit reportées à plus
tard, pour servir un objectif différent.
Les avantages de MoSCoW
Cette méthode très simple permet de formaliser l’alignement des stakeholders pour
des sujets simples, sans consacrer trop de temps à la priorisation. Elle permet
également de déterminer des éléments obligatoires en laissant de la marge de
manœuvre aux équipes produit pour implémenter ou non tout ce qui n’est pas “Must”.
Les inconvénients de MoSCoW
Cette méthode ne convient pas dès que le sujet à traiter est un peu complexe, ou
lorsque les stakeholders ne sont pas alignés sur les objectifs business. Un autre risque
classique de MoSCoW est de se retrouver uniquement avec des Must et des Should,
tout étant considéré comme important. Enfin MoSCoW ne permet pas de prioriser entre
2 éléments ayant une même priorité.
168
/
L’atelier Buy a Feature

Cette méthode issue des Innovation Games126 est un jeu qui permet de définir les
fonctionnalités les plus importantes en prenant en compte l’effort associé à chaque
fonctionnalité. Le principe est très simple.
Dans un premier temps, et préalablement à l’atelier, les différentes stories ou

fonctionnalités associées à un produit sont listées et l’effort pour les réaliser est plus ou
moins grossièrement estimé par l’équipe de réalisation. Cet effort est ensuite traduit en
prix pour la feature.
Le jour de l’atelier, vous réunissez les participants (entre 4 et 7), idéalement des
utilisateurs ou des clients potentiels dans le cadre d’un focus group, à défaut des
stakeholders du produit.
Une somme d’argent est allouée à chaque participant, de sorte que les plus grosses
features ne peuvent pas être achetées par une personne seule. Prévoyez une somme
d’argent total en fonction de la capacité de l’équipe sur une période donnée. Par
exemple, si vous souhaitez prioriser sur un trimestre et que l’équipe a une capacité de
production équivalente à 500€ dans le jeu, répartissez environ 400€ entre les
participants (pour conserver une marge de manœuvre).
Les participants doivent ensuite négocier entre eux et mettre tout ou partie de leur
argent en commun, pour pouvoir acheter les fonctionnalités qu’ils désirent.
A la fin de l’atelier, vous avez une liste des features ou des stories les plus importantes
pour vos utilisateurs. Mais plus que les fonctionnalités priorisées, l’intérêt de ce jeu
pour le product manager réside dans les échanges lorsque les joueurs négocient :
comprendre leur raisonnement pour choisir une fonctionnalité plutôt qu’une autre,
quel argument convainc d’autres personnes, quel type de personne est sensible à telle
ou telle fonctionnalité et pourquoi…
Les avantages de Buy a feature
Cette méthode permet de faire intervenir les utilisateurs ou les parties-prenantes dans
la priorisation du backlog. L’aspect ludique permet de casser des barrières et de
générer des discussions au contenu très utile. En réunissant les utilisateurs en groupe,
le PM évite certains biais qu’il pourrait induire dans des entretiens en face-à-face.
Les inconvénients de Buy a feature
L’atelier est un guide pour prioriser les développements, mais il ne prend en compte
que la valeur client (si les joueurs sont des utilisateurs) ou les intérêts des stakeholders
(s’ils sont les participants), en fonction de l’effort à fournir. Le PM doit prendre en
compte d’autres priorités, comme les contraintes business, l’impact sur les objectifs
stratégiques. Si un des participants est particulièrement charismatique, il risque de
126
HOHMANN, Luke. Buy a Feature. https://www.innovationgames.com/buy-a-feature/
Voir aussi le livre du même auteur : Innovation Games : Creating breakthrough products through
collaborative play.
169
/
convaincre les autres participants d’acheter des fonctionnalités qui l’intéressent et qui
ne seraient pas forcément les plus appréciées pour un groupe plus grand.
La méthode WSJF - Weighted Shortest Job First

La méthode WSJF est préconisée par le framework SAFe127 pour prioriser les éléments
de la roadmap (ou du backlog produit). Le principe du WSJF est de donner un score à
chaque fonctionnalité en divisant le “cost of delay”, ou coût à ne pas faire, par l’effort à
fournir pour livrer la fonctionnalité. L’objectif du WSJF est de prioriser les fonctionnalités
en mettant l’accent sur celles qui livrent le plus de valeur en un minimum de temps.
Le score WSJF est évalué selon la formule suivante :
Les 3 éléments en dividende de l’équation représentent le Cost of Delay (CoD), ce que

l’organisation perd si la fonction n’est pas livrée :
● User-business value : que rapporte la fonctionnalité au business et à

l’utilisateur ?
● Time Criticality : est-ce que la valeur diminue dans le temps ?
● Risk reduction and/or opportunity enablement : est-ce que la fonctionnalité
réduit des risques business et techniques, ou ouvre la porte à de nouvelles
opportunités ?
Le CoD est divisé par le Job duration, l’effort pour délivrer l’initiative (durée, coût…)
Chaque élément du WSFJ est estimé par un collège déterminé de membres, qui évalue
le score concerné pour toutes les fonctionnalités à comparer. Chaque élément est
mesuré en utilisant une suite de Fibonacci (1, 2, 3, 5, 8, 13 et 21). Afin de pouvoir
comparer les différentes features, il doit y avoir au moins un 1 pour chacun des aspects
(la fonctionnalité livrant le moins de valeur aura 1 en value, la fonctionnalité la plus
simple à implémenter aura 1 en Job duration...). Les autres fonctionnalités sont
évaluées en comparant avec cette baseline.
Une fois le score WSJF de chaque fonctionnalité déterminé, il suffit de les classer pour
avoir une bonne idée de la priorité de chaque fonctionnalité.
Les avantages de WSJF
En impliquant les parties-prenantes dans l’attribution des scores, les WSJF permettent
de rationaliser la prise de décision et d’emporter plus facilement l’adhésion. Cette
127
Weighted Shortest Job First. Scaled Agile Framework.
https://www.scaledagileframework.com/wsjf/
170
/
méthode collaborative peut être utile quand des parties-prenantes intervenant dans le
processus de décision ont des objectifs divergents (mais devrait être inutiles si l’objectif
attribué à l’équipe a été défini préalablement). En se concentrant sur la livraison de
fonctionnalités à bas coût et forte valeur, le WSJF force également à supprimer tout ce
qui est inutile, ou moins utile, dans une fonctionnalité pour ne garder que l’essentiel,
dans un esprit MMF (minimum marketable feature).
Les inconvénients de WSJF
En mettant l’accent sur la livraison de petites initiatives à forte valeur, le WSJF néglige les
initiatives complexes et longues mais pouvant apporter une valeur critique à long
terme. Elle est faite pour prioriser le développement d’un produit en l’absence de vision,
mais ne convient pas pour un vrai produit innovant. Enfin, même si cette méthode a le
mérite de mettre un score pour rationaliser la prise de décision, elle est fortement
tributaire de l’utilisation de l’échelle de notation (que veut dire une valeur de 3 ou de 8
?) et repose sur les impressions des parties-prenantes plutôt que sur des faits chiffrés.
171
/
2 - L’agilité et les frameworks

agiles
S’il n’est pas obligatoire d’utiliser un framework agile pour faire du product
management, force est de constater que les valeurs de l’agilité telles que l’adaptation au
changement, la collaboration client et les interactions sont parfaitement compatibles
avec la culture produit. L’agilité du développement logiciel a été popularisé grâce au
manifeste agile, et à ses 4 valeurs :
“Nous découvrons comment mieux développer des logiciels par la pratique

et en aidant les autres à le faire. Ces expériences nous ont amenés à
valoriser :
● Les individus et leurs interactions plus que les processus et les
outils
● La collaboration avec les clients plus que la négociation
contractuelle
Nous reconnaissons la valeur des seconds éléments, mais privilégions les
premiers.”
12 principes ont été ajoutés pour guider les pratiques de développement logiciel :
Les 12 principes du manifeste agile - Wikiagile CESI
172
/
De nombreuses méthodes, principes et frameworks ont été formalisés à partir de ces

principes, souvent regroupées sous le nom de “méthodes agiles”.
2.1 - Agilité et product management

Entre l’esprit du manifeste agile et l’application dans les grandes entreprises ou dans la
plupart des ESN, il y a un grand écart. Elles se contentent d’appliquer quelques
éléments empruntés à Scrum, Kanban ou XP : elles mettent en place des cycles de
développement itératifs qu’elles appellent sprint ; elles utilisent Jira ou Trello avec
quelques colonnes pour y placer des requirements ; elles font développer quelques
tests unitaires. Mais elles perdent de vue, si elles l’ont jamais compris, le but du
manifeste. Elles pensent appliquer une méthodologie, quand l’agilité est d’abord un état
d’esprit. Alistair Cockburn, un des signataires du manifeste agile, résume l’esprit de
l’agilité à 4 principes qu’il appelle le Heart of Agile128 : collaborer, délivrer, réfléchir,
améliorer. Si vous ne mettez pas en place ces 4 principes au quotidien, vous n’êtes pas
agile.
Matt LeMay définit 4 étapes129 pour mettre en place une vraie démarche d’agilité dans
une organisation produit :
1. Démarrez avec un guide, une North Star, pour vous imprégner des principes de
l’agilité. Matt LeMay conseille de lire et vraiment comprendre le Manifeste Agile
ou le Heart of Agile, avant de commencer à s’intéresser aux frameworks. Toutes
les pratiques que l’organisation ou la squad va mettre en place doivent être
guidées par ces principes.
2. Choisissez un framework agile existant. N’essayez pas de fabriquer votre
propre méthodologie dès le départ. De préférence, prenez une méthodologie
très encadrée, pour donner un point de départ commun à tout le monde.
Assurez-vous que toute l’équipe comprend intimement les principes de ce
framework.
3. Evaluez régulièrement les spécificités de la méthodologie au regard de votre
North Star. Par exemple : la façon dont vous menez les réunions (ou
cérémonies) vous aide-t-elle à collaborer ? Les processus mis en place
permettent-ils de livrer de la valeur aussi souvent que possible ?
4. Améliorez les processus et les pratiques pour tendre davantage vers les valeurs
de votre North Star. Adaptez la méthodologie choisie à votre contexte, en
essayant d’être toujours plus agiles. Documentez les changements que vous
apportez, pour qu’ils soient clairs pour tout le monde, et expliquez-les.
Un product manager doit être familier avec l’agilité dans le développement logiciel et
avec les différents frameworks. La meilleure des idées produit n’est rien sans une
excellente exécution, le PM passe donc généralement la majeure partie de son temps à
travailler avec l’équipe de réalisation. Le cadre dans lequel cette collaboration s’effectue
est souvent primordiale. Certaines organisations imposent un framework défini,
d’autres laissent les équipes s’organiser en utilisant le framework qu’elles jugent le plus
128
COCKBURN, Alistair. Heart of Agile. https://heartofagile.com/lets-begin/
129
LEMAY, Matt, Product Management in practice. p. 138, Four Steps to Future-Proof Agile.
173
/
opportun. Les organisations les plus matures adaptent généralement ces différents
frameworks à leurs besoins. Dans tous les cas, comprendre comment ces frameworks
fonctionnent, et pourquoi les différents principes existent est un enjeu majeur pour
permettre à l’équipe de sortir un produit de qualité.
2.2 - Zoom sur Scrum

En développement logiciel, Scrum est le framework le plus utilisé au monde, de loin. Il
est parfois utilisé comme synonyme de développement agile. Lorsque quelqu’un parle
abusivement de “la méthode agile”, il parle souvent de Scrum. D’après le rapport Annual
State of Agile de 2020 de Digital AI130, 58% des organisations ont mis en place le
framework Scrum dans le développement agile de logiciels.
Scrum est un framework qui préconise une approche itérative et incrémentale du

développement produit basée sur des cycles à durée fixe appelés sprints. Il s’agit
d’une approche reposant sur l’amélioration continue. Scrum repose sur 3 piliers : la
transparence (et la mise en place de standards de travail communs comme incarnation
de cette transparences) ; l’inspection (c’est à dire le contrôle fréquent et régulier que
tout se passe comme prévu) ; l’adaptation (soit prendre des mesures de correction
quand quelque chose ne se passe pas comme prévu). Ses principes sont détaillés dans
le Scrum Guide131.
Les rôles de Scrum

Scrum définit 3 rôles au sein de ce qui est appelé l’équipe Scrum :
● Le Product Owner, dont j’ai déjà parlé. Dans le product management moderne,
ce rôle est assumé par le PM. Le product owner est le responsable du backlog,
son rôle est de maximiser la valeur produite par l’équipe.
● L’équipe de développement, que j’appelle ici équipe de réalisation. Il s’agit de
l’ensemble des personnes en charge de réaliser les développements de
l’incrément produit. Scrum insiste sur l’auto-organisation de l’équipe de
développement, qui rappelle l’autonomie des équipes produit.
● Le Scrum Master, à la fois garant de l’application de la théorie Scrum par les
membres de l’équipe, coach méthodologique de l’équipe, et “leader-serviteur”
des autres membres de l’équipe et de l’organisation. Le rôle du Scrum Master est
à la fois d’évangéliser l’organisation à l’agilité et de faciliter la vie de l’équipe
Scrum en leur permettant de se concentrer sur leurs tâches, plutôt que d’être
parasités par des obstacles externes. En fonction des organisations, le rôle du
SM peut être très varié : facilitation de workshops, administration du logiciel
utilisé pour la gestion du backlog, rédaction de comptes-rendus et de reportings,
interface avec les équipes techniques pour fournir les socles applicatifs ou même
l’équipement informatique du nouveau venu… Scrum Master n’est pas
130
14th annual state of agile report. Digital.ai : 2020.
https://explore.digital.ai/state-of-agile/14th-annual-state-of-agile-report
131
SCHWABER Ken & SUTHERLAND, Ken. Le Guide Scrum.
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-French.pdf
174
/
nécessairement un poste en soi, et peut être assuré par un membre de l’équipe

(un des développeurs), voire un membre extérieur à l’équipe (un coach, un
delivery manager…)
Le processus de Scrum
Le processus défini par Scrum est le suivant :
1. Le product owner gère et priorise le backlog, qui est la liste de toutes les tâches
nécessaires à la réalisation du produit (développements de nouvelles
fonctionnalités ou d’amélioration, correction de bugs, études de faisabilité,
tâches techniques diverses et variées…). N’importe qui peut ajouter des
éléments au backlog, mais le PO est responsable de leur priorisation et de leur
complétude.
2. Au début de chaque sprint, le product owner définit un objectif qui va servir de
guide pour le travail des prochaines semaines (le sprint). Dans une organisation
produit, cet objectif doit être un pas vers l’atteinte des objectifs donnés à la
squad dans le cadre de la stratégie produit.
3. Le sprint démarre avec un événement appelé Sprint Planning. Il s’agit d’une
négociation entre le PO et l’équipe de développement sur les éléments du
backlog qui seront réalisés pendant le sprint. Il s’agit de la liste des éléments
priorisés par le PO, qui répondent à l’objectif du sprint. Les développeurs doivent
s’engager à la réalisation de ces éléments pendant le sprint. Afin de pouvoir
s’engager, les développeurs estiment entre eux la charge de travail (par exemple
sous forme de “points”) et la liste des tâches associés à chaque élément du
backlog (plusieurs techniques existent pour ces estimations). La charge de travail
admissible d’un sprint à l’autre est censée être la même, de sorte que le PO
puisse à peu près prédire ce qui pourra entrer dans les sprints futurs. Seuls les
éléments sur lesquels les développeurs peuvent s’engager sont intégrés au
sprint. La liste des éléments retenus pour le sprint s’appelle le Sprint Backlog.
L’engagement des développeurs permet à l’organisation de prévoir avec une
grande certitude ce qui sera livré à l'issue du sprint.
4. Ensuite, le sprint commence, pour une durée définie à l’avance, qui est la même
à chaque fois. En théorie, le contenu du sprint est fixe : il n’est pas possible
d’enlever ou d’ajouter des éléments, afin de ne pas perturber l’engagement pris
par les développeurs, et donc la prévisibilité de ce qui sera livré. Dans les faits, il
arrive souvent que le contenu du sprint change à la marge, et l’équipe doit
trouver des standards qui permettent de le faire (par exemple s’assurer que
seuls les éléments non modifiés peuvent être changés, remplacer un élément
par un autre de même charge, pouvant être réalisé par les mêmes personnes…)
5. Chaque jour pendant le sprint, un évènement court a lieu appelé Daily Scrum
(ou parfois stand-up meeting ou daily meeting). Durant cet événement, chaque
membre de l’équipe de réalisation donne un statut sur ses tâches en cours. Le
but intrinsèque de cette réunion est de la gestion de risque : identifier au plus
vite d’éventuels points de blocage, afin de prendre les mesures appropriées et
éviter de mettre en péril l’engagement pris pour le sprint.
175
/
6. A chaque fin de sprint a lieu une Sprint Review. Généralement l’équipe de

réalisation montre au PO et aux stakeholders du produit ce qui a été réalisé
pendant le sprint, puis une discussion s’engage sur ce qui a été fait pendant le
sprint : qualité des développements, éléments du sprint backlog qui n’ont pas pu
être finis, éventuels besoins de modification sur certains éléments, dates de mise
en production, objectif sprint suivant… Ce sprint review permet notamment
d’alimenter le backlog.
7. L’ensemble des éléments finis dans le cadre du sprint constitue un incrément
produit, c'est-à-dire une version du produit potentiellement livrable (shippable)
en production. Les éléments finis ne doivent donc pas être dépendants d’autres
éléments à venir, risquant de compromettre le caractère shippable de
l’incrément.
8. Le sprint se finit par une Sprint Retrospective, pendant laquelle le PO, le Scrum
Master et les membres de l’équipe de développement discutent de ce qui a bien
fonctionné et mal fonctionné pendant le sprint, et définissent des actions à
mettre en œuvre pour améliorer le travail de l’équipe Scrum, dans une démarche
d’amélioration continue.
9. Ensuite le sprint suivant commence
Avantages et inconvénients de Scrum

Au sein d’une organisation produit, Scrum n’est pas sans poser de problèmes. Les
équipes trouvent généralement des parades pour les résoudre, mais ces parades
nuisent généralement à l’équilibre de Scrum et génèrent elles-mêmes des problèmes.
Voici quelques défauts généralement attribués à Scrum :
● Le Product Designer et les autres membres de la squad doivent pouvoir interagir

avec l’équipe de développement. Scrum ne propose pas de cadre pour cette
collaboration, la squad doit donc trouver des bonnes pratiques pour les intégrer.
176
/
● Scrum est basé sur des cycles à durée fixe. Un nouveau besoin urgent doit donc
attendre le prochain sprint pour commencer à être développé. Par exemple,
dans une squad fonctionnant en sprint de 3 semaines, si une nouvelle
opportunité business arrive la première semaine du sprint, elle doit attendre 2
semaines de plus pour que l’équipe commence à travailler dessus, et la fin du
sprint suivant pour qu’elle soit potentiellement mise en production, donc au
moins 5 semaines.
● L’ensemble des éléments du sprint doivent être connus au démarrage du sprint.
Cette approche peut entrer en conflit avec la démarche exploratoire propre au
product management et nécessaire à l’innovation. L’équipe peut être amenée à
faire des choix entre prédictibilité du sprint et place pour l’innovation.
● L’obligation dans Scrum de devoir livrer des incréments finis, potentiellement
livrables peut également nuire à la qualité et à l’innovation. A la qualité, car elle
favorise la génération de dette technique, en prenant des raccourcis pour finir
dans les temps. A l’innovation, car elle empêche de prendre le temps de
résoudre un problème complexe.
● La démarche Scrum est difficilement compatible avec la participation de
membres de l’équipe produit aux phases de discovery, dont la charge de travail
n’est par définition pas prédictible.
● Dans Scrum, le test et la validation de la réalisation des éléments revient
implicitement au Product Owner, qui peut se retrouver à ne plus avoir de temps
entre la rédaction des stories, la priorisation du backlog, les échanges avec les
développeurs pendant le sprint et la validation des développements.
L’intégration des QA au sein de l’équipe de réalisation, afin de tester et valider les
éléments de l’incrément, est fondamentale pour donner du temps au PM/PO sur
les aspects discovery et stratégie de son travail.
Avantages de Scrum Inconvénients de Scrum
● Les contraintes fortes de Scrum ● Le Scrum Master doit veiller à

permettent à une équipe l’application du processus. Une
inexpérimentée de rentrer dans mauvaise application de Scrum
l’agilité facilement, si elles sont mène généralement à des
correctement coachées. résultats déceptifs.
● Impose une culture de ● Finir dans les temps peut se faire
transparence et de visibilité. au détriment de Scrum.
● La standardisation permet à ● Les demandes urgentes peuvent
toutes les équipes de travailler de ne pas être traitées à temps.
la même façon. ● Moins adapté au continuous
● Force l’équipe de réalisation à delivery.
s’engager, sur des sujets à court ● L’accumulation de cérémonies
terme. peut devenir chronophage.
● Les sprints sont basés sur
l’atteinte d’un objectif.
177
/
2.3 - Kanban, ou le développement produit par le flux

Kanban est une méthode de gestion inventée par Toyota dans les années 50 en tant
que partie du processus Lean. Elle est basée sur des processus à flux tendu, l’absence
de stocks et le just-in-time. Sans reprendre les détails de la méthodologie industrielle,
l’état d’esprit de Kanban a été adapté au développement logiciel.
Contrairement à Scrum et à beaucoup d’autres frameworks agiles, Kanban n’est pas

basé sur des itérations fixes, mais sur un flux continu. Le product manager priorise son
backlog en plaçant en haut de la pile les éléments à traiter. A chaque fois qu’un élément
est terminé, l’équipe prend l’élément suivant par ordre de priorité.
Kanban est basé sur 4 principes qui doivent guider le flux de travail des équipes :
● Commencez par ce que vous faites maintenant : ne pas commencer une

tâche sans en avoir terminé une autre.
● Cherchez un changement incrémental et évolutif : le processus est évolutif et
doit être amélioré quand il y a une opportunité
● Respectez les processus, les rôles et les responsabilités : les normes définies
par l’équipe ont une vraie raison d’être. Elles ne doivent pas être contournées,
mais peuvent être changées si un besoin se fait sentir.
● Encouragez le leadership à tous les niveaux : chaque partie-prenante du
processus doit chercher l’amélioration continue et se sentir à l’aise dans la prise
de parole et de décision.
En plus de ces 4 principes, Kanban est basé sur 5 pratiques fondamentales132.
Visualiser le flux de travail

Le workflow doit être compris par tous les acteurs du kanban, donc en product
management par tous les membres de la squad. Il doit être représenté visuellement,
sous forme d’un tableau comprenant une colonne pour chaque étape du workflow. Le
workflow le plus simple peut être représenté en 3 colonnes : à faire, en cours, fait.
Il est souvent beaucoup plus complexe, pouvant intégrer des phases de préparation des
requirements, de design, de test et de validation, de revue de code, de passage entre
différents environnements (environnement de développement, d’intégration, de test…).
Et éventuellement une colonne “bloqué”.
Lorsque plusieurs équipes utilisent le même tableau Kanban, ou lorsqu’on veut séparer
visuellement le travail effectué par certains membres de l’équipe (back vs. front, dev iOS
et Android…), ou encore pour séparer les bugs des évolutions, on utilise généralement
des swimlanes, lignes horizontales qui permettent de découper le travail en cours.
132
Kanban Fundamentals. Kanban Tools.
https://kanbantool.com/kanban-guide/kanban-fundamentals
178
/
exemple de tableau Kanban avec un workflow à 6 étapes et 3 équipes133
Les conditions de passage d’une étape du workflow à la suivante doivent être comprises
par tous les membres de la squad. En particulier, l’ensemble des critères permettant de
définir qu’un élément est prêt à rentrer dans le workflow, et l’ensemble des critères
permettant de définir que l’élément est “fini” ou “done” doivent être parfaitement clairs.
Limiter le travail en cours

Kanban est basé sur la limitation stricte du work in progress ou WIP, c'est-à-dire du
nombre d’éléments sur lesquels l’équipe peut travailler en même temps. La limitation
du WIP permet de diminuer le multitasking et donc l’éparpillement des ressources, de
réduire le TTM en s’assurant que les éléments les plus importants sont finis aussi
rapidement que possible, d’affronter les difficultés plutôt que de laisser un ticket bloqué
indéfiniment. L’équipe doit trouver l’équilibre du WIP : il faut éviter les goulots
d’étranglement, éviter que des éléments s’accumulent à une étape du workflow.
Dans une logique Kanban, lorsque le WIP est atteint et que certains membres de
l’équipe de réalisation n’ont plus de tâches disponibles dans leur champ d’expertise, ils
doivent venir aider les autres membres de la squad sur les tâches qui posent
éventuellement problème, afin de finir les éléments en cours le plus rapidement et
libérer de la place dans le WIP. Par exemple, un développeur peut aider un autre
développeur sur un problème complexe, ou aider la QA pour automatiser certaines
parties.
Mesurer et gérer le flux

L’équipe doit être capable de mesurer l’efficacité de son travail, sa productivité, afin
d’identifier des points d’optimisation et prendre des mesures appropriées dans une
optique d’amélioration continue.
133
SIDEROVA, Sonya. Improve Task Organization: Kanban Swimlanes. Nave : 2018.
https://getnave.com/blog/kanban-swimlanes/
179
/
Le flux peut par exemple être mesuré avec un diagramme de flux cumulatif (CFD), qui
permet de mesurer l’évolution du temps que met chaque élément pour passer du
début à la fin du workflow (d’un statut “ready for development” à un statut “done”), ainsi
qu’à chaque étape du workflow. Ce diagramme permet de mesurer l’évolution globale
de la productivité, et d'identifier quelques goulots d’étranglement récurrents.
L’équipe Kanban peut également utiliser les notions de lead time et cycle time. Le lead
time est la période entre l’entrée d’un élément dans le workflow et sa sortie, c’est à dire
entre le moment où l’élément est prêt à être développé, et le moment où il est arrivé à
un statut fini (en fonction des équipes, ça peut être la validation par le product manager
ou la mise en production par exemple). Le cycle time représente la période entre le
moment où un membre de l’équipe commence à travailler sur l’élément, et le moment
où il arrive à un statut fini. La différence entre les deux représente le temps d’attente
d’un élément dans le backlog.
Ces différentes métriques permettent à l’organisation de prévoir à l’avance le temps

moyen que mettra une requête à être livrée, et prendre des mesures appropriées.
exemple de CFD avec lead time et cycle time134
Expliciter les normes du processus

Les règles régissant le workflow doivent être claires, explicites, connues de tous et
affichées clairement. Chaque membre de l’équipe doit connaître les critères qui
permettent de considérer qu’une étape du workflow est terminée et que la suivante
peut commencer, afin d’éviter les surprises, les ralentissements dans le flux d’activité et
les éventuels conflits.
Les normes doivent également permettre à l’équipe de savoir clairement réagir face à
certains problèmes : un bug est détecté lors du workflow, comment l’élément est-il géré
? Est-ce qu’il revient en arrière ? Une urgence arrive en priorité tout en haut du backlog,
comment la traiter ? Faut-il arrêter le travail en cours ? Ces normes doivent pouvoir
évoluer en fonction des échanges au sein de l’équipe.
134
Kanban: Lead Time vs Cycle Time - Details Explained. Kanbanize.
https://kanbanize.com/kanban-resources/kanban-software/kanban-lead-cycle-time
180
/
Identifier les opportunités d’amélioration

L’équipe doit chercher en permanence à l’amélioration des processus et des normes
afin d’augmenter la productivité et l’efficacité du travail de l’équipe. Cette amélioration
continue doit exploiter des théories scientifiques sur les flux de travail, la gestion des
risques ou les processus, partagées par toute l’équipe, afin de permettre à tous de
comprendre les problèmes et de trouver collaborativement de bonnes solutions. Ces
théories incluent la théorie des contraintes135 (étude des goulots d’étranglement) ou le
Lean IT136 (et le concept de déchets).
Avantages et inconvénients de Kanban

Kanban est particulièrement adapté aux équipes matures, qui savent déjà travailler
ensemble et ont une bonne connaissance théorique et pratique de l’agilité. Le cadre
donné par Kanban est très léger et incite chaque équipe à adapter les processus et les
normes de travail à ses besoins. Elle peut également s’adapter à d’autres méthodes ou
frameworks utilisés par l’organisation. Le travail en flux permet facilement d’intégrer
des urgences et fonctionne bien dans une démarche d’exploration, aux problèmes
complexes et à la livraison en continu (continuous delivery). Kanban s’adopte également
bien aux produits matures avec des évolutions constantes.
Étant peu contrainte, cette méthodologie est par contre peu indiquée pour des squads
débutantes, peu expérimentées dans l’agilité. Elle n’est pas non plus indiquée lors du
démarrage des développements d’un produit, après les phases exploratoires lorsque
l’équipe doit se concentrer sur le développement et la livraison d’un premier produit qui
fonctionne. Elle peut également poser problème pour un PM qui doit sans cesse être
capable de prioriser le backlog et valider les tâches en cours. Si un PM part pendant 2
jours sur des phases de discovery, il risque de devenir le goulot d’étranglement de
l’équipe. Pour un produit ou une équipe non mature, un framework plus cadré, centré
sur des itérations fixes comme Scrum peut s’avérer plus simple à prendre en main.
135
MARRIS, Philip, La Théorie des Contraintes : accélératrice du Lean et génératrice de croissance.
Marris Consulting.
https://www.marris-consulting.com/points-de-vue/la-theorie-des-contraintes-accelerateur-du-lea
n
136
JUGE, Frédéric, Les 10 clefs du Lean IT. Black Belt Story : 4 mars 2017.
https://blackbeltstory.com/2017/03/04/les-10-clefs-du-lean-it/
181
/
Avantages de Kanban Inconvénients de Kanban
● Peu de contraintes : l’équipe peut ● Peu de contraintes : une équipe

adapter les processus et les inexpérimentée peut être perdue
normes à ses besoins ● Requiert une présence
● Le management visuel permet un permanente du PM
alignement de toute l’équipe. ● Pas d’engagement sur la fin du
● Permet une vue holistique sur le développement, donc peu de
cycle de vie des demandes. prédictibilité
● Force les membres de l’équipe à ● Demande une revue permanente
finir ce qu’ils ont commencé. des processus et des normes
● Favorise une culture ● Les processus du workflow
d’amélioration continue. doivent être scrupuleusement
● Permet le continuous delivery. respectés au risque de bloquer
● Adapté à la résolution de toute la chaîne.
problèmes longs et complexes ● Le framework n’est pas centré sur
● Permet de concilier phases les objectifs. Le PM est
exploratoires et delivery entièrement garant de l’utilisation
● Peut être combiné à d’autres de Kanban dans l’atteinte d’une
méthodes et frameworks vision.
● Permet d’identifier rapidement les ● Kanban est difficile à maîtriser.
points de blocage.
● Kanban est facile à comprendre.
2.4 - Et les autres…

Il existe un nombre immense de méthodes et de frameworks agiles : RAD (Rapid
Application Development), DSDM (Dynamic Software Development Method), Unified Process,
Lean IT… Je vais me contenter d’en mentionner 2. Scrumban, qui est une des
méthodologies les plus utilisées après Scrum, et XP, qui est la source de la plupart des
pratiques de programmation modernes.
Scrumban
Scrumban est né comme une méthodologie de transition entre Scrum et Kanban, pour
les équipes qui souhaitent expérimenter une approche plus “lean”. Elle est devenue une
méthodologie à part entière.
Scrumban est basé sur des itérations de durée variable. Plutôt que d’être basé sur une
charge de travail fixe (de “points”) par itérations, Scrumban est basé sur un WIP fixe au
démarrage de chaque sprint. Dès que le WIP descend en dessous d’une certaine limite,
les membres de l’équipe peuvent organiser un nouveau planning à la demande
(on-demand planning), afin de réalimenter le WIP.
Scrumban introduit la notion de Bucket Size Planning : un système de priorisation à

long terme qui permet d’organiser le backlog avec 4 niveaux de priorisation : Les
182
/
objectifs à long terme sont accumulés dans le seau “1 an”. Lorsqu’un objectif est
priorisé, il est déplacé dans le seau “6 mois” dans lequel les principaux besoins sont
détaillés. Avant l’implémentation, les différentes tâches ou stories liées à chaque besoin
sont détaillées dans le bucket “3 mois”. Ce bucket 3 mois constitue le backlog priorisé
des éléments dans lequel l’équipe peut piocher dans le planning.
De Scrum, Scrumban reprend les itérations et le planning.
De Kanban, Scrumban reprend : le WIP et le fait de se concentrer sur une tâche à la fois,
les lead & cycle times, le management visuel.
XP (Extreme programming)
XP est une méthode de développement logiciel inventée dans les années 90 par de
futurs auteurs du manifeste agile. Il est basé sur 5 valeurs (communication, simplicité,
feedback, courage et respect) et sur 13 pratiques :
● conception simple : la solution technique la plus simple doit être implémentée

pour faciliter l’évolution de l’application et sa maintenance.
● développement piloté par les tests (test-driven development, TDD) : les tests
unitaires sont développés avant le code de la fonctionnalité. La fonctionnalité est
prête quand elle passe le test.
● tests fonctionnels : le client (en l'occurrence le PM) participe à l’écriture des
tests de recette pour préciser le besoin. A la fin des développements, tous les
tests sont exécutés, pour vérifier que la solution répond au besoin.
● refactorisation du code : pour améliorer la qualité du code en permanence,
sans modifier le comportement.
● peer programming : 2 développeurs travaillent en binôme sur la même
machine. Un des développeurs saisit les lignes de code et l’autre vérifie la qualité
(peer review) en temps réel. Les binômes changent en cours de projet. Permet
aux développeurs de bien connaître tous les pans de l’application, et de garantir
une excellente qualité de code.
● standards de codage : les développeurs définissent des standards qu’ils doivent
tous respecter pour faciliter les interventions croisées.
● propriété collective du code : tous les développeurs sont susceptibles de
travailler sur n’importe quelle partie du code, il n’y a pas de chasse gardée.
● utilisation de métaphores : métaphores et analogies permettent aux
développeurs de se faire comprendre des parties prenantes fonctionnelles
● intégration continue : le code développé par chaque membre de l’équipe doit
être fusionné au moins une fois par jour sur une machine dédiée pour identifier
d’éventuelles anomalies croisées.
● client sur site : le client (le PM) est intégré à l’équipe de développement,
physiquement, dans les mêmes bureaux, pour favoriser la communication,
préciser les besoins, arbitrer les priorités et visualiser les résultats des
développements directement sur la machine des développeurs.
● planning poker : les besoins sont fréquemment priorisés lors d’une séance
réunissant le client (le PM) et les développeurs. Le client définit les éléments
183
/
prioritaires. Les développeurs détaillent les tâches techniques et les estiment de

façon unanime pour s’engager sur leur réalisation.
● livraisons fréquentes : les versions du code doivent être livrées en production
le plus souvent possible. Ceci est rendu possible grâce aux tests et à l’intégration
continue.
● rythme soutenable : l’équipe doit adopter un rythme de travail que ses
membres sont capables de soutenir tout au long du projet. Les heures
supplémentaires sont proscrites. Un développeur fatigué travaille mal.
La plupart de ces principes établis il y a 25 ans sont devenus des standards de

développement, et ont posé les bases de l’agilité et du continuous delivery, qui tiennent
une place centrale dans le product management moderne. Si vous souhaitez améliorer
votre time-to-market et la qualité du code, donc la maintenabilité du produit,
assurez-vous que ces bonnes pratiques sont appliquées par les équipes de réalisation.
184
/
3 - Mettre le produit en production

L’équipe de réalisation a développé le nouveau produit ou de nouvelles fonctionnalités,
reste maintenant l’essentiel : pousser en production, rendre les changements
accessibles aux utilisateurs. C’est un des points sur lequel bon nombre d’organisations
dites “agiles” échouent : elles créent rapidement de nouvelles fonctionnalités, mais ne
parviennent pas à livrer rapidement ces fonctionnalités à l’utilisateur final. Tout l’intérêt
de la feedback loop est perdu. Comment faire pour être agile jusqu’au bout et livrer de
la valeur aux utilisateurs le plus souvent possible ?
3.1 - La culture DevOps

Le DevOps est un mouvement culturel dans la communauté du développement logiciel,
apparu à la fin des années 2000. Le premier à utiliser le terme DevOps en 2007 est
Patrick Debois, à l’époque, consultant pour un projet de migration de données pour le
gouvernement belge. Avec d’autres membres de la communauté des administrateurs
systèmes (Ops), il organise le 30 octobre 2009 à Gand la première conférence
DevOpsDays137 relayée sur les réseaux sociaux par le hashtag #DevOps qui devient
viral.
Le mouvement DevOps cherche à réfléchir aux problèmes posés par les relations entre
équipes de développement et équipes de production, et notamment le manque d’agilité
des équipes de production.
Dans les organisations traditionnelles, les rôles sont bien séparés entre équipes de
développement (Dev), également appelés équipes de Build, qui réalisent le code du
produit, et équipes de production (ingénieurs systèmes, Prod ou Ops) également
appelées équipe de Run, dont le rôle était d’une part d’assurer les mises en production
du code fourni par les développeurs, et d’autre part d’assurer le maintien en conditions
opérationnelles des systèmes de production (monitoring des applicatifs et des serveurs,
gestion des flux de données et des systèmes d’ordonnancement de traitements,
administration des bases de données…). La séparation de ces deux rôles a pour effet de
limiter le time-to-market : d’un côté les équipes de build veulent livrer de nouvelles
fonctionnalités le plus rapidement possible et au moindre coût, quand l’équipe de run a
pour objectif de garantir la qualité et la stabilité du système. Les deux équipes sont en
partie dépossédées de leurs objectifs, l’équipe de développement étant freinée par les
processus imposés par l’équipe de production (documentation, disponibilité des
ressources, transfert de connaissances…), et les Ops reprochant aux Dev les bugs qui
nuisent à la stabilité de la production.
Avec l’introduction de l’agilité dans le développement logiciel, les équipes de

développement se mettent dans une position de pouvoir délivrer du code fonctionnel
beaucoup plus rapidement, afin d’optimiser la boucle de feedback et améliorer de façon
continue leurs processus et la qualité du code. Mais, sans outils et processus agiles
137
Devopsdays Ghent 2009. Devopsdays.org. https://legacy.devopsdays.org/events/2009-ghent/
185
/
côté Ops, l’organisation IT se retrouve avec une bulle agile évoluant au sein d’une
structure toujours figée, qui peut difficilement suivre le rythme.
Dans une structure appliquant les principes DevOps, les rôles et responsabilités sont
complètement changés : l’équipe de réalisation (et non plus seulement équipe de
développement) ne s’occupe plus seulement des développements, elle est responsable
de son produit du début jusqu’à la fin. Elle assure les développements et les tests bien
sûr. Elle s’occupe également du déploiement de l’application dans les différents
environnements, jusqu’à la production. Enfin, elle est également responsable de la
maintenance du système applicatif : s’il y a un incident de production, les membres de
l’équipe de réalisation sont d’astreinte et c’est à eux de corriger le problème.
Les Ops, eux, sont chargés de fournir aux dev les outils qui leur permettent de devenir
autonome dans l’ensemble de la chaîne produit. Ils fournissent notamment des
infrastructures et des plateformes “as a service” (IaaS et PaaS), c'est-à-dire des serveurs,
des bases de données, des plateformes d’intégration ou des outils applicatifs que les
développeurs peuvent consommer en self-service. Par exemple, ils mettent en place
des systèmes d’abstraction qui permettent aux développeurs de ne pas avoir à se
soucier des mises à jour de serveurs ou des systèmes d’exploitation.
L’ingénieur DevOps
Au delà de la culture de collaboration entre développeurs et ingénieurs systèmes, le
mouvement DevOps a abouti à la création d’un rôle à part entière : l’ingénieur DevOps,
d’ailleurs appelé la plupart du temps simplement “DevOps”. Son rôle est de faciliter
cette mise en relation entre les équipes de réalisation et les équipes en charge des
systèmes sous-jacents.
Ils sont en particulier responsables de fournir aux équipes de réalisation les moyens et
les processus de mise en production, pour qu’ils n’aient plus à se soucier que de la
qualité du code. Ils sont les garants de la robustesse de ces processus, et ils
construisent la CI/CD pipeline, c'est-à-dire la chaîne qui permet l’automatisation des tests
et des déploiements pour mettre en place l’intégration continue (CI) et le déploiement
continu (CD).
Voici un éventail non exhaustif des outils du DevOps138 :
● Les outils de gestion de code source, qui permettent à tous les membres de
l’équipe de versionner et partager le code qu’ils produisent.
Exemples : Github, Gitlab, Sourceforge, Bitbucket...
● Les outils de CI/CD pour automatiser les tests et les modifications du code
source, ou provisionner de l'infrastructure “as code” (IaC)
Exemples : Jenkins, GitlabCI, Bamboo, Ansible, Terraform, Puppet… Les
plateformes de Cloud fournissent généralement leurs propres solutions
● Les conteneurs, qui permettent d’isoler une application, et l’abstraire de la
notion de serveur sur lequel il est installé. Les orchestrateurs permettent
DAVID, Clément. DevOps : quels sont les outils DevOps les plus utilisés aujourd'hui ?. Padok : 16
138
mai 2019. https://www.padok.fr/blog/outils-devops

186
/
d’automatiser le déploiement des conteneurs et les règles d’interaction entre ces

conteneurs.
Exemples : Docker ou RKT (conteneurs), Kubernetes (orchestrateur)
● Les fournisseurs de solution Cloud, qui permettent de s’abstraire
d’infrastructures physiques.
3 acteurs se partagent l’essentiel du marché du cloud public (IaaS et PaaS) :
Amazon Web Services (AWS), Microsoft Azure et Google Cloud Platform.
● Les outils de monitoring et d’alerting, qui permettent d’avoir une vue d’ensemble
sur l’infrastructure et les applicatifs, en détectant tous les dysfonctionnements et
en alertant les bonnes équipes.
Exemples : Prometheus, ELK (Elasticsearch, Logstash et Kibana), Splunk...
● Outils de gestion de projet agile, type JIRA
● Gestion des secrets, pour stocker de façon sécurisée tous les identifiants et
codes d’accès techniques entre les différents applicatifs
Exemples : Vault ou Secrets.
Le rôle du Site Reliability Engineer (SRE)

Né chez Google et créé par Ben Treynor139 dès 2004, le Site Reliability Engineering140 est
une approche de la gestion des opérations informatiques comme un problème logiciel,
opéré par des développeurs. Concrètement, ce sont des développeurs qui jouent le rôle
d’ingénieurs systèmes. L’objectif est d’utiliser les compétences de développement pour
automatiser le plus de tâches possibles, plutôt que de les faire manuellement. Chez
Google, le temps passé par un SRE sur des sujets de “prod” (interventions manuelles,
gestion d’incidents…) doit être limité à 50% maximum. Le reste du temps doit être passé
à développer des processus d’automatisation pour rendre le système plus scalable, plus
résistant, ou capable de se réparer de lui-même.
Le SRE s’attache plus particulièrement à résoudre des problèmes complexes, sur des
systèmes à grande échelle massivement distribués. Leur rôle est fondamentalement de
faire en sorte que les systèmes tournent 24/7, tout en diminuant le plus possible le
nombre de tâches manuelles.
Même si le SRE est né avant l’introduction du DevOps, les deux concepts sont largement
compatibles. Ils visent à automatiser le plus de processus possibles. De nombreuses
organisations ayant adopté une approche DevOps ont confié la maintenance de leurs
systèmes à des rôles de SRE.
3.2 - Déployer les nouvelles versions en continu

Composante essentielle d’un processus agile de bout en bout, le continuous deployment
(livraison continue, CD) est une approche de la publication de logiciels dans laquelle le
code produit par les équipes de réalisation est poussé en production le plus souvent
139
Google Cloud Platform. The History of SRE. Youtube : 15 juillet 2020. [vidéo]
https://landing.google.com/sre/
140
What is Site Reliability Engineering (SRE)?. Google Site Reliability Engineering.
187
/
possible. L’objectif est de raccourcir au maximum la boucle de feedback pour améliorer

la qualité logicielle et réduire le time-to-market.
A titre d’exemple, en 2014 Amazon effectuait 50 millions de mises en production par an

sur l'intégralité de ses produits141… soit environ une par seconde. En 2018, Google a
effectué 3234 mises à jour et 654 680 tests, uniquement pour l’algorithme de son
moteur de recherche, soit 9 mises en production par jour142 !
Dans une approche Scrum, le continuous deployment a lieu idéalement à la fin de

chaque sprint, lorsque l’incrément est validé par le product owner (product manager).
Dans des approches plus agressives, chaque élément autonome du backlog est publié
en production dès qu’il est prêt, validé là encore par le product manager. C’est d’ailleurs
une des raisons pour lesquelles Scrum est délaissé par les équipes les plus matures.
Comparaison entre intégration continue, livraison continue et déploiement continu143
Pour mettre en place le CD, l’organisation doit se doter d’outils automatisés et de

processus permettant aux équipes de réalisation de déployer le code sur différents
environnements et de le tester de façon automatique, jusqu’à la mise en production. De
nombreux prérequis sont nécessaires.
L’architecture logicielle du produit doit être modulaire pour permettre de livrer des
parties du code indépendamment les unes des autres. La plupart des architectures
141
VOGELS, Wemer. The Story of Apollo - Amazon’s Deployment Engine. All Things Distributed : 12
novembre 2014.
https://www.allthingsdistributed.com/2014/11/apollo-amazon-deployment-engine.html
142
ANDRIEU, Olivier. Google a fait 9 modifications de son algorithme PAR JOUR en 2018. Abondance :
18 juin 2019.
https://www.abondance.com/20190618-39952-google-a-fait-9-modifications-de-son-algorithme-
par-jour-en-2018.html
143
PITTET, Sten. Continuous integration vs. continuous delivery vs. continuous deployment. Atlassian.
https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-
deployment
188
/
anciennes sont monolithiques, et les transformer peut demander un investissement

très important.
L’intégration continue : tester le code aussi tôt que possible

Les développeurs adoptent une démarche de continuous integration (intégration
continue, CI). Les développeurs adoptent des principes de l’extreme programming (XP),
notamment en développant des tests unitaires pour chaque fonctionnalité (test-driven
development) et des pratiques de revue de code (le code produit par un développeur est
revu par un autre développeur avant le commit).
Le code du produit est géré dans une unique source. Chaque développeur partage son
code le plus régulièrement possible (au moins une fois par jour, mais beaucoup plus
souvent dans les équipes matures) avec les autres développeurs dans un logiciel de
gestion de versions, comme Github ou Gitlab et l’intègre au code commun du produit :
le commit. Chaque commit est déployé sur un environnement d’intégration, sur lequel
l’intégralité des tests développés par l’équipe de réalisation est exécutée (tests unitaires,
tests d’intégration, test de qualité du code) : le build.
Bénéfices de l’intégration continue :
● Les bugs et les régressions sont détectés extrêmement rapidement grâce à

l’automatisation des tests.
● Les problèmes d’intégration sont résolus le plus tôt possible.
● Les développeurs gagnent en productivité, en évitant de revenir sur du code
plusieurs jours ou semaines plus tard.
● Le coût des tests est largement diminué, notamment pour l’équipe de QA.
La livraison continue : déployer le code en appuyant sur un bouton

Le continuous delivery (livraison continue) est une extension du continuous integration :
en plus d’automatiser la fusion du code de chaque développeur et les tests
d’intégration, la livraison du code sur les différents environnements est elle-même
automatisée.
Pour caricaturer, un simple bouton permet de déployer une nouvelle version applicative
du produit sur un environnement d’intégration ou de préproduction. Les équipes sont
automatiquement alertées si le déploiement échoue, pour pouvoir, là encore, corriger
aussi rapidement que possible.
Le code est automatiquement livré en environnement de préproduction, copie plus ou

moins fidèle (et anonymisée) de la production. Divers tests sont effectués sur cet
environnement avant de pouvoir pousser en production : tests d’interface utilisateur,
tests de sécurité (penetration tests), tests de performance, tests d’acceptance
utilisateurs… Une fois ces tests passés avec succès, le code peut également être
automatiquement livré en production.
Bénéfices de la livraison continue :
189
/
● La complexité pour déployer chaque version du produit est drastiquement

réduite. Les développeurs n’ont plus besoin de créer des procédures de release
compliquées expliquant pas-à-pas à un ingénieur de production comment
installer cette nouvelle version.
● Les équipes de réalisation sont autonomes pour pousser le code dans les
différents environnements. Elles n’ont théoriquement plus besoin des ingénieurs
de production pour faire les mises en production.
● Le déploiement du code peut être effectué beaucoup plus souvent, améliorant
ainsi la boucle de feedback agile et le time-to-market.
● Comme le déploiement est simple, prend peu de temps et n’introduit que très
peu d’indisponibilité du produit (voire pas du tout), c’est une étape qui met
beaucoup moins de pression sur les équipes, ce qui encourage à itérer de plus
en plus rapidement.
Le déploiement continu : livrer une nouvelle version aux utilisateurs

sans intervention manuelle
Enfin le continuous deployment va un cran plus loin, en automatisant le déploiement
jusqu’en environnement de production, c’est-à-dire l’environnement sur lequel évolue
l’utilisateur final du produit. Plus qu’une problématique technique, le déploiement
continu est une question de culture, de qualité et d'exhaustivité des tests. L’organisation
doit être confortable dans le fait de ne rien tester manuellement.
Tous les tests fonctionnels créés par les QA sont automatisés, par exemple grâce au
Behaviour-driven development. Les tests de performance et de sécurité sont également
automatisés. Le business et/ou le product manager ont participé à l’écriture des tests
fonctionnels de bout en bout et les ont validés, et n’ont donc pas besoin de valider
manuellement les développements réalisés. Tous les tests d’interface sont également
automatisés grâce à des outils dédiés, le product designer n’a pas non plus besoin de
valider que la UI est fidèle à ses spécifications.
Pour prendre en compte la sécurité, adoptez une démarche dite de DevSecOps pour
automatiser la prise en compte des normes de de sécurité, au niveau de
l’environnement et des données, et tout au long des processus de CI/CD144.
Dans une démarche de continuous development, la mise en place de feature toggles

(aussi appelés feature flags ou feature switchs) devient essentielle : chaque nouvelle
fonctionnalité livrée en production peut être activée ou désactivée via un simple
paramètre applicatif, sans avoir à modifier le code. L’intérêt des feature toggles est
multiple145 :
144
Qu'est-ce que le DevSecOps ?. Red Hat.
https://www.redhat.com/fr/topics/devops/what-is-devsecops
145
SALTHUN-LASSALLE, Mathilde. Les Feature Toggles : Activer / Désactiver dynamiquement une
fonctionnalité d’un logiciel. Docdoku : 13 janvier 2019.
https://www.docdoku.com/blog/2019/01/13/les-feature-toggles-activer-desactiver-dynamiqueme
nt-une-fonctionnalite-dun-logiciel/
190
/
● Si un incident survient lors d’une livraison, la fonctionnalité peut être désactivée

pour supprimer l’incident sans avoir à re-livrer, laissant le temps à l’équipe de
réalisation pour corriger le problème.
● Si une fonctionnalité est en dépendance avec d’autres fonctionnalités,
notamment livrées par d’autres équipes de développement, elle peut être
déployée en production désactivée, et activée quand cette dépendance est
remplie. Il n’y a donc plus besoin de synchroniser les déploiements entre les
équipes.
● Si une fonctionnalité nécessite de nombreuses itérations pour atteindre une
qualité suffisante pour être livrée à l’utilisateur final, le feature toggle permet de
livrer et tester la fonctionnalité non finie en environnement d’intégration et de
pré-production, sans avoir à modifier le code en production.
● Si une anomalie est identifiée tardivement sur une fonctionnalité et qu’elle est
embarquée dans la même version que d’autres fonctionnalités, elle peut être
livrée en production désactivée, plutôt que de retarder la livraison entière de la
version.
● Le feature toggle permet également d’activer une fonctionnalité pour une partie
des utilisateurs uniquement, afin de procéder à des tests. On peut par exemple
utiliser le feature toggle pour pousser une version bêta d’un produit à certains
utilisateurs.
Les bénéfices du déploiement continu :
● Le time-to-market est optimisé à son maximum, en supprimant les lourdes

phases de recette manuelle.
● Les développeurs ne se concentrent que sur la qualité de leur code, sans avoir à
s’arrêter régulièrement pour effectuer des mises en production.
● Le risque des releases est réduit au maximum : en livrant le plus souvent
possible des petits lots, les problèmes sont plus simples à identifier et à corriger.
En cas de besoin, un retour-arrière (rollback) à la version précédente est plus
simple en supprimant de la production un volume faible d’évolutions.
Les Agile Release Trains pour synchroniser les mises en production

Dans certains cas, il n’est pas possible de laisser les équipes déployer leur code en
production quand elles le souhaitent. C’est par exemple le cas lorsque le produit
possède une architecture trop monolithique, ou que le produit en question doit être
installé par l’utilisateur final : vos clients ne veulent pas faire dix updates de leur
application mobile chaque jour, et les stores ne vous permettent pas de le faire de
toutes façons.
Le framework SAFe a introduit la notion d’Agile Release Trains (ART), dont une partie du
principe de fonctionnement a été repris par des équipes n’utilisant pas SAFe. Le
principe est relativement simple : l’organisation met en place un cadencement régulier
de ses mises en production. Par exemple, toutes les semaines, le vendredi à 18h, le
code du composant (par exemple l’application mobile Android) est déployé.
191
/
Tout le code des différentes équipes qui aura été fusionné et validé sera embarqué
dans cette release. Tout ce qui n’est pas prêt devra attendre le train suivant. Si le
rythme des ART est suffisamment élevé, la pression pour livrer le code à temps est
largement diminuée. Bien sûr, si les ART ont lieu tous les trimestres, la situation est
différente et livrer un code en retard peut devenir une catastrophe… mais les
organisations qui livrent si rarement ne se mettent certainement pas en condition d’être
ni innovantes ni agiles.
L’utilisation conjointe de release trains fréquents et de feature toggles permet aux

équipes de ne pas se soucier du rythme des releases, tout en étant assurées que les
fonctionnalités sont livrées rapidement aux utilisateurs.
192
/
VI - Le produit à l’échelle
Partie VI
Le produit à l’échelle
Au début de la vie du produit, une seule équipe pluridisciplinaire suffit pour gérer
l’intégralité du produit et des systèmes sous-jacents. Au bout d’un moment, le produit
prend de l’ampleur ; la startup grandit ; certains systèmes alimentent plusieurs produits
; unique product manager ne parvient plus à alimenter les équipes et néglige les phases
de discovery ; les développeurs sont trop nombreux et peinent à se répartir le travail
sans dépendances entre eux… : la création de plusieurs équipes produit se posent.
Comment répartir les prérogatives des différentes équipes ? Comment gérer les
relations et les dépendances entre ces équipes ? Que faire des rôles transversaux ?
Je vous donne quelques pistes dans ce chapitre. Gardez en tête qu’il n’y a pas de recette
miracle. Chaque organisation possède son lot d’avantages et d’inconvénients, et
résoudre un problème revient souvent à en créer d’autres. N’essayez pas de définir une
organisation supposée fonctionner pendant plusieurs années, vous n’y arriverez pas.
Votre organisation doit être en amélioration continue. Pensez votre organisation
comme un produit : identifiez les problèmes organisationnels, testez des solutions à
petite échelle, et déployez ce qui fonctionne, sans considérer à un moment que vous
avez fini.
193
/
1 - Comment découper le produit

entre différentes équipes
Marty Cagan définit quelques principes146 qui permettent de guider la réflexion quand
vient le moment de penser au découpage des équipes. Ces principes sont parfois
contradictoires, à chaque organisation de définir le meilleur équilibre en les gardant à
l’esprit :
● Aligner les équipes avec la stratégie d’investissement : si une équipe est

responsable d’un sujet qui n’est plus dans la stratégie de l’entreprise, il faut
assigner l’équipe à un nouveau sujet stratégique, ou réallouer les ressources.
● Minimiser les dépendances, pour permettre aux équipes de délivrer plus vite
● Créer des équipes autonomes, responsables de leurs succès et de leurs échecs,
avec les moyens de les accomplir.
● Maximiser la réutilisation de ce qui a déjà été fait dans d’autres équipes, en
fournissant par exemple des services partagés. Il faut trouver le bon équilibre
entre leverage d’un côté, autonomie et indépendance d’un autre côté.
● Aligner les équipes avec la stratégie produit. Les équipes doivent pouvoir
efficacement livrer les objectifs stratégiques.
● Garder les équipes petites : plus les équipes sont grosses moins le PM pourra
alimenter tout le monde, et plus les échanges et la communication entre les
membres de l’équipe seront compliqués. Amazon est célèbre pour avoir
popularisé la pizza teams147, soit une équipe d’environ 8 personnes maximum.
● Aligner les équipes avec l’architecture technique : tous les développeurs ne
peuvent pas être experts en tout, en particulier dans les grandes organisations.
Pour éviter que les équipes se battent contre l’architecture technique en place,
que des interdépendances techniques bloquent le travail des squads, certaines
équipes peuvent être dédiées au socle technique qui sera utilisé par les autres.
● Aligner les équipes avec les clients et les utilisateurs : découper les équipes
en fonction des types d’utilisateurs du produit leur permet de concentrer leurs
efforts d’acquisition de connaissance client sur un segment plutôt que de
s’éparpiller, et de développer leur expertise.
● Aligner les équipes avec le business : les grandes entreprises ont souvent des
lignes business qui fournissent des services différents aux clients. Il peut être
utile dans une certaine mesure d’aligner certaines équipes avec ces lignes
business, en prenant garde à ne pas créer d’incohérence sur les socles
techniques, et sur les parcours utilisateurs si les clients de ces business lines
sont les mêmes. Ce découpage peut également avoir du sens si vous intégrez les
produits à usage interne à cette organisation produit (finance, RH...)
146
CAGAN, Marty. Inspired. Chapitre 20, Principles of Structuring Product Teams. p.93-97.
147
CINQUIN, Ludovic. Les Patterns des Grands du Web – 2-Pizza Team. Octo : 18 juin 2012.
https://blog.octo.com/2-pizza-team/
194
/
● Garder à l’esprit que la structure n’est pas figée. Les périmètres sur lesquels
investir changent régulièrement en fonction de la maturité du produit, des
fonctionnalités et des problèmes et opportunités rencontrées.
Dans le livre blanc Les organisations orientées produit148, Thiga propose 4 modèles de
découpage pour définir le périmètre d’action des squads : un modèle historique,
horizontal, centré sur la technique, le découpage en component teams, et 3 modèles
verticaux, plus adaptés à une organisation produit, centrés sur l’utilisateur et la
génération de valeur : les feature teams et 2 modèles dérivés, les impacts et les persona
teams.
Il n’y a pas de recette miracle qui fonctionne pour toute organisation. C’est à chaque
entreprise d’adapter le découpage en fonction de ses besoins. Le découpage ne doit
pas non plus être figé dans le temps. Il dépend de la croissance des équipes : un
découpage qui fonctionne dans une startup avec 2 équipes ne fonctionnera pas
forcément quand celle-ci grossira et devra passer à 5 ou 6 équipes.
Enfin, ces modèles ne sont pas exclusifs. Il est tout à fait possible d’avoir une
component team en charge d’un système backend complexe nécessitant des
spécialistes techniques, une équipe en charge d’un persona, 3 feature teams se
répartissant le parcours d’un autre persona et une impact team transverse sur un OKR
particulier.
La direction produit de myCANAL, un mix entre impact teams,

feature teams et component teams149
1.1 - L’organisation en component team

L’organisation en component teams est souvent l’organisation historique d’une DSI. Il
s’agit d’un découpage horizontal en fonction de problématiques techniques, chaque
THIGA. Les organisations orientées produit. Chapitre 3 : comment découper les

148
équipes.
149
https://www.youtube.com/watch?v=jmXuvN2x4vM
195
/
équipe est responsable d’un socle applicatif cohérent. Elle est généralement composée
d’experts dans la solution.
Dans ce modèle, les équipes ne produisent pas de valeur en soi. Le rôle du responsable
de ces équipes (Head of Product ou Directeur Produit) est critique : il est le seul à avoir
une vision d’ensemble cohérente de la valeur qui sera livrée, et il est chargé de
coordonner les phases de travail des équipes pour qu’elles puissent ensemble fournir
des fonctionnalités. Dans ce modèle, les product managers ont typiquement un rôle de
product owner uniquement. N’ayant pas de vision globale sur la valeur livrée, elles se
contentent pratiquement de gérer un backlog technique et de détailler les spécifications
de chaque besoin, en se coordonnant avec le PO des autres équipes.
Par exemple, pour livrer une fonctionnalité d’avis sur un site e-commerce, l’équipe
backend devra d’abord développer le traitement et le stockage de l’information et
fournir les API qui vont permettre aux développeurs front d’exploiter ces traitements.
Ensuite chaque équipe front (web, iOS, Android…) développera les interfaces propres à
son périmètre technique. Avec le risque que les équipes avancent à des rythmes
différents, ou qu’il y ait des différences dans les expériences utilisateurs en fonction des
plateformes.
Un découpage classique en 4 component teams pour un produit web et mobile
Dans une organisation en component teams, il est compliqué d’avoir des product
designers et des QA par équipe. Afin de construire une expérience client cohérente, les
designers doivent intervenir de manière transverse avec chaque équipe. De même, les
QA peuvent partiellement tester le résultat du développement de chaque équipe, mais
un test de bout en bout sur le code produit par l’ensemble des équipes est nécessaire
pour valider le comportement global de la fonctionnalité.
Les component teams sont de manière générale mal adaptées à la logique produit, qui
vise à donner aux équipes l’autonomie et la responsabilité nécessaires pour délivrer
196
/
directement de la valeur aux utilisateurs et aux business. On peut toutefois trouver

deux cas principaux où la component team a sa place dans une organisation produit :
● Les composants de type plateforme qui seront utilisés par plusieurs équipes,
peuvent être gérés par une équipe dédiée à cette plateforme. Cela permet aux
autres équipes, avec une responsabilité verticale, d’utiliser un système robuste,
cohérent, sans se soucier des dépendances avec les autres équipes verticales.
● De façon temporaire, lorsqu’un domaine technique est en retard sur le reste de
l’environnement produit, il peut être utile d’y dédier une équipe jusqu’à ce que ce
composant soit suffisamment mature pour que l’évolution de ce composant et
les ressources associées soient réinjectées dans les autres équipes. Ainsi,
Alexandre Takacs, ancien directeur produit de Viadeo, m’a expliqué qu’ils avaient
fondé une équipe dédiée aux mobiles dans la première moitié des années 2010,
à une époque où les applications mobiles étaient très peu matures. Une fois le
retard rattrapé, le mobile a été réinjecté dans les autres features teams.
Avantages de la component team Inconvénients de la component team
● Haut niveau d’expertise technique ● Pas de responsabilisation des

des membres équipes : elles ne produisent
● Collaboration technique favorisée, aucune valeur en soi.
et interchangeabilité des membres ● Pas possible de donner des
(peu de dépendance aux objectifs business
personnes) ● Pas d’orientation client
● Mutualisation du code entre les ● Modèle typique du Build Trap (les
membres de la squad équipes ne savent pas pourquoi
● Modèle adapté à des problèmes elles travaillent)
techniques complexes ● Génère du déchet
● Facilement adaptable en termes ● Très forte dépendance
de taille (rajouter ou enlever des fonctionnelle entre les équipes
développeurs ne met pas en péril ● Les équipes risquent de rejeter la
le composant) faute des échecs sur les autres
● Time-to-market élevé, la
production de chaque équipe
n’étant pas autonome
● Pas de discovery dans la squad
● Place les équipes dans une
relation client-fournisseur vis-à-vis
du business
1.2 - L’organisation en feature teams

Dans un modèle en feature team, les équipes suivent un découpage vertical en fonction
des grandes fonctionnalités du produit. Chaque équipe est pluridisciplinaire, réunissant
toutes les compétences nécessaires à la réalisation de ses objectifs de façon la plus
autonome possible. Ainsi chaque équipe produit est dotée de son product manager, de
ses développeurs back et front, de son product designer, ses QA… et tous les profils
197
/
nécessaires pour atteindre ses objectifs sur son périmètre. Il s’agit de l’archétype du
modèle de l’équipe produit que j’ai déjà détaillé dans cette thèse.
Par exemple, au sein d’une entreprise de e-commerce, chaque feature team est
typiquement en charge des étapes du parcours client : acquisition et onboarding,
navigation, fiche produit, panier et paiement, post-sales…
le découpage en feature teams chez Veepee150
Dans ce modèle, chaque équipe est relativement indépendante, même s’il reste
quelques adhérences, lors des transitions d’une fonctionnalité à l’autre ou sur des
socles techniques communs. Par exemple, la plupart des équipes intervenant sur un
parcours client e-commerce vont être amenées à toucher au CRM.
Une organisation en feature teams sur un parcours d’achat e-commerce
150
198
/
Dans ce modèle, le rôle du Head of Product est d’assigner des objectifs à chaque équipe
et de s’assurer que les différents product managers communiquent sur les éventuelles
adhérences fonctionnelles. D’un point de vue technique, il faut également une personne
chargée de la cohérence pour définir des normes d’architectures que les différentes
équipes doivent utiliser et éviter d’accumuler de la dette technique.
Avantages de la feature team Inconvénients de la feature team
● Équipes responsabilisées sur des ● Les développeurs doivent être

objectifs business capables de s’adapter à plusieurs
● Autonomie et empowerment de la types de technologies
gestion du backlog et de la ● Plusieurs équipes touchent aux
roadmap mêmes composants techniques :
● Équipes orientées client par besoin de règles transverses
nature ● Moins d’expertise technique :
● Peu de dépendance entre les moins adapté à la complexité
squads ● Certains développements peuvent
● Possibilité de se projeter sur le être guidés par la nécessité de
long terme nourrir une feature team.
● L’équipe peut faire son propre ● Si certains profils spécialistes sont
product discovery uniques dans une squad, leur
● Les idées peuvent être testées absence peut créer des goulots
avant d’être mises en place d’étranglement
● Time to market accéléré si ● Possibilité de code redondant
l’architecture technique est bien entre les équipes
organisée ● Parfois un challenge pour scaler
● Le périmètre de la squad reste ● Peut générer des coûts
restreint techniquement, même supplémentaires (profils dans
s’il est multi-technologies chaque squad)
● Les développeurs fullstack
peuvent être intervertis sur des
tâches similaires
● Favorise l’amélioration continue
1.3 - L’organisation en impact teams

Le modèle en impact team est une variante de la feature team, destiné à être plus
flexible pour délivrer de la valeur. Comme je l’ai expliqué, l’objectif des équipes produit
doit toujours être de délivrer de la valeur client et business. Les fonctionnalités que ces
équipes produisent ne sont que la solution pour délivrer cette valeur. Dans le modèle
en feature team, chaque équipe doit être pilotée par des KPI ou des OKR, qui
matérialisent cette valeur produit.
Le découpage en grandes fonctionnalités peut parfois être contreproductif : maintenir

une équipe chargée d’une fonctionnalité, là où il n’y a plus de levier de croissance à
exploiter ou de point de friction majeur à couvrir. Imaginons un site de e-commerce
avec un tunnel d’achat sans point de friction ; le nombre d’utilisateurs qui abandonnent
leur panier à cette étape est faible. L’équipe peut trouver des points d’amélioration,
optimiser le parcours client, proposer de nouveaux modes de paiement… des
199
/
fonctionnalités qui peuvent plaire aux utilisateurs. Si ces nouveautés n’agissent que
marginalement sur les KPI du produit, ces actions ne servent pas la stratégie produit.
Le modèle en feature team peut également poser problèmes lorsqu’il faut créer une
nouvelle fonctionnalité majeure dans un produit, voire un nouveau produit : par
définition, aucune feature team existante n’est en charge de cette nouveauté, il faut
donc créer une nouvelle équipe. Mais si la feature envisagée s’avère être une fausse
bonne idée, que se passe-t-il ? L’équipe peut-elle remettre en question l’existence même
de cette feature, ou la transformer en quelque chose de totalement différent ?
Pour résoudre ce problème, certaines organisations ont inventé un modèle en impact

team. Plutôt que d’être responsable d’une fonctionnalité, et d’être piloté par des
objectifs associés à cette fonctionnalité, l’impact team est responsable d’un objectif
stratégique, pilotée par les OKR associés à cet objectif. La squad est susceptible
d’intervenir sur n’importe quelle partie du produit pour délivrer cet objectif. Une fois
l’objectif atteint, l’impact squad peut être assignée à un nouvel objectif.
Le découpage en feature teams peut être fait selon n’importe quel OKR donné par le
management : augmentation du chiffre d’affaire sur un segment, diminution du churn,
lancement du produit sur un nouveau marché, voire la prise en compte d’une nouvelle
contrainte réglementaire. L’important est que cet OKR soit vraiment basé sur des
objectifs business, et pas des outputs.
Le modèle en impact team : un découpage similaire aux feature teams

mais une responsabilité différente.
Christopher Parola, Directeur Produit et Nicolas Baron, CTO de MeilleursAgents,

expliquent151 que ce modèle a permis de se concentrer sur les priorités, d’augmenter
l’autonomie et la productivité des équipes et d’abandonner bien plus vite les initiatives
vouées à l’échec. Ils soulignent notamment le fait de devoir restreindre le nombre d’OKR
151
La Product Conf. Piloter les équipes Produit par l'impact. Youtube : 8 août 2018. [vidéo]
https://www.youtube.com/watch?v=VqdUA3bhW38
200
/
que les équipes doivent couvrir sur une année, ce qui permet de vraiment choisir les
sujets : ce qui ne vise pas à atteindre un des OKR ne sera pas fait dans l’année.
Avantages de l’impact team Inconvénients de l’impact team
● Équipes extrêmement ● Les développeurs doivent être

responsabilisées sur des objectifs capables de s’adapter à plusieurs
business types de technologies
● Autonomie et empowerment au ● Besoin de règles communes ou
plus haut d’équipe supplémentaire pour
● Tous les efforts de développement gérer l’interaction entre les 2
sont concentrés sur les sujets les parcours (backend)
plus importants ● Moins d’expertise technique :
● Peu de dépendance entre les moins adapté à la complexité
squads ● Buy-in plus compliqué à obtenir
● Possibilité de se projeter sur le du management (savoir renoncer)
long terme ● Si certains profils spécialistes sont
● L’équipe peut faire son propre uniques dans une squad, leur
product discovery absence peut créer des goulots
● Les idées peuvent être testées d’étranglement
avant d’être mises en place ● Possibilité de code redondant
● Time to market accéléré si entre les équipes
l’architecture technique est bien ● Peut générer des coûts
organisée supplémentaires (profils dans
● Le périmètre de la squad reste chaque squad)
restreint techniquement, même
s’il est multi-technologies
tâches similaires
1.4 - L’organisation en persona teams

Comme pour les features teams et les impact teams, l’organisation en persona teams
est un découpage vertical avec des équipes pluridisciplinaires et autonomes. Ici, les
équipes sont en charge de l’intégralité du parcours d’un type d’utilisateur.
Ce découpage fonctionne particulièrement bien pour les plateformes : pour un produit

fournissant un service de véhicule avec chauffeurs, une équipe s’occupe de l’expérience
clients (ceux qui cherchent à se déplacer), et une autre équipe fournit l’expérience des
chauffeurs eux-mêmes. Sur une marketplace, une équipe gère le parcours acheteur,
tandis que l’autre équipe gère le parcours vendeur.
201
/
Une organisation en 2 persona teams : acheteurs et vendeurs
Avantages de la persona team Inconvénients de la persona team
● Équipes responsabilisées sur des ● Les développeurs sont

objectifs business susceptibles d’intervenir sur
● Autonomie et empowerment toutes les technologies produit :
● Optimise les parcours clients nécessite une grande expérience
● Peu de dépendances entre les ● Les impact teams prennent plus
squads de temps à devenir matures
● Possibilité de se projeter sur le ● Plusieurs équipes touchent aux
long terme mêmes composants techniques :
● L’équipe peut faire son propre besoin de règles transverses
product discovery ● Possibilité de code redondant
● Les idées peuvent être testées entre les équipes
avant d’être mises en place ● Ne scale pas bien seul (on ne peut
● Time to market accéléré si pas multiplier les personae)
l’architecture technique est bien
organisée
tâches similaires
● Intègre facilement des experts
techniques sur un des parcours
1.5 - La place des équipes transverses

Idéalement, tous les profils nécessaires à la réalisation des objectifs produit doivent être
réunis au sein d’une même équipe, afin de minimiser les dépendances et renforcer une
position de “missionnaires” pour l’équipe.
202
/
Dans certains cas, les organisations sont amenées à regrouper tous les profils d’une
même spécialité au sein d’une équipe unique. Certaines personnes sont donc amenées
à travailler avec plusieurs équipes produit en même temps.
Certains rôles sont transversaux par nature. Les rôles de type “Ops” ont pour mission
d’harmoniser les outils et les processus entre les différentes équipes : ProductOps,
DevOps, DesignOps… Les Product Researchers centralisent les besoins de recherche
utilisateurs et sont particulièrement utiles lorsque l’organisation a besoin d’identifier
des problèmes qui concernent plusieurs équipes produit, pour éviter que plusieurs
équipes aient à effectuer les mêmes études chacun de leurs côtés. Côté technique, des
architectes urbanistes peuvent être amenés à réfléchir à une vue d’ensemble de
l’écosystème tech, pour l’optimiser et éviter certaines redondances.
Dans d’autres cas, ces équipes agissent en tant que pools de compétences, et
regroupent des personnes qui travaillent avec une ou plusieurs équipes produit, mais
ne sont pas assignées de façon durable à ces équipes, par exemple des product
designers ou des data analysts. Essayez d’éviter ça, si possible. Privilégiez une approche
matricielle de type Spotify : chaque spécialiste est bien rattaché à une équipe produit de
façon durable, et contribue à l’atteinte des objectifs de cette équipe, mais est
hiérarchiquement rattaché à un “Head of” spécialiste, au sein d’un chapitre, d’une guilde
(appelez cela comme vous voulez) qui permet de partager les pratiques spécifiques au
métier. Si vous devez tout de même créer des pools, créez-les au niveau de chaque
ligne produit, pour que les membres de ces pools interviennent sur des sujets
cohérents.
Parfois vous devrez tout de même partager certaines ressources entre plusieurs
équipes. Soit pour des raisons budgétaires (vous ne souhaitez pas recruter autant de
product designers qu’il y a d’équipe), ou parce qu’il n’y a pas de besoin (des équipes
avec une forte composante backend qui n’ont pas assez de besoins pour alimenter un
product designer à temps plein), ou encore parce que les ressources sont manquantes
(certains profils sont rares sur le marché, et vous devez donc partager une ressource).
Veillez à bien définir à l’avance comment cette collaboration avec deux équipes doit se
passer : répartition du temps de travail, objectifs personnels par rapport aux OKR…
Dans tous les cas, si vous devez créer des équipes transversales, définissez clairement
le mode d’interaction entre les équipes et les responsabilités de chacune. L’approche
Team Topologies peut vous y aider.
203
/
2 - Les interactions entre équipes

2.1 - Le “modèle” Spotify
En 2012, Henrik Kniberg et Anders Ivarsson, coachs agiles Spotify ont exposé un modèle
organisationnel matriciel dont l’objectif était de mettre en place les principes de l’agilité
à l’échelle dans une entreprise comptant de très nombreuses équipes produit152.
Avant de continuer sur ce chapitre, quelques mises en garde, le sujet faisant souvent
polémique : les auteurs n’ont jamais prétendu présenter un “modèle” d’organisation. Ils
exposent des principes intéressants qui donnent matière à réflexion pour les autres
organisations qui cherchent à optimiser l’organisation de leurs équipes produit à
l’échelle. Les auteurs insistent sur le fait que l’organisation de Spotify n’est pas figée et
que celle qu’ils présentent n’est qu’une prise de vue à un moment donné. D’ailleurs,
Spotify n’utilise plus cette organisation, et ne l’a même jamais vraiment utilisée.153
Reste que l’organisation matricielle de Spotify est intéressante à étudier, et a été

adaptée avec succès dans bon nombre d’organisations produit (et avec beaucoup
moins de succès ailleurs). Spotify a également introduit un certain nombre de termes
devenus iconiques dans l’agilité et le product management, même si la réalité qu’ils
représentent existait déjà ailleurs sous d’autres noms.
L’organisation proposée par Spotify
Le “modèle” Spotify exposé par Kniberg et Ivarsson.
152
KNIBERG, Henrik & IVARSSON, Anders. Scaling Agile @ Spotify : with Tribes, Squads, Chapters and
Guilds. Octobre 2012. https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf
153
LEE, Jeremiah. Failed #SquadGoals : Spotify doesn’t use “the Spotify model” and neither should
you. 19 avril 2020. https://www.jeremiahlee.com/posts/failed-squad-goals/
204
/
Dans l’organisation décrite par Spotify, le produit est développé par des équipes produit
autonomes appelées Squads, essentiellement sur le modèle des feature teams, d’autres
squads étant en charge des clients applicatifs (iOS, Android, desktop...) ou de
l’infrastructure154. Le terme a depuis largement été repris par les communautés agiles et
product, et je l’utilise moi-même largement dans cette thèse. Chaque squad est
constituée d’un product owner, d’un UX designer et d’un ensemble d’ingénieurs afin de
développer, tester et livrer leurs réalisations de façon autonome. Chaque squad est
libre d’utiliser les outils qu’elle souhaite et d’appliquer le framework agile qu’elle
préfère.
Les squads qui travaillent sur des parties communes du produit sont regroupées dans
une Tribe (tribu). Chaque tribu est dirigée par un Tribe Lead, qui correspond au rôle de
Head of Product ou directeur produit. Chaque tribe doit être constituée de moins de
100 personnes. Les product owners et les UX designers rapportent hiérarchiquement
au Tribe Lead. Dans l’organisation décrite par Spotify, les interactions entre tribus sont
limitées au maximum.
Les ingénieurs d’une même tribu sont regroupés horizontalement dans des Chapters
(chapitres). Par exemple, il existe un chapitre pour les développeurs backend, un autre
pour les développeurs frontend web, un chapitre pour les développeurs iOS, un pour
les QA… Chaque chapter est dirigé par un chapter lead, qui est le manager hiérarchique
de tous les membres du chapitre. Il est également supposé faire partie d’une squad. Les
membres d’un chapitre sont réunis régulièrement pour discuter de sujets spécifiques à
leurs métiers (nouveautés techniques, problèmes communs à résoudre…)
Enfin, Spotify propose également la mise en place de Guilds, communauté d’intérêts

transverses aux différentes tribus. Par exemple, il peut y avoir une guilde sur le test, qui
regroupe tous les membres de chapitres de test de chaque tribu, mais également
toutes les personnes de l’organisation qui sont intéressées par le test. Les guildes
peuvent être organisées par langage ou framework de programmation (PHP, Java,
Javascript, React…), par compétences (SEO, web analytics, expérience utilisateur…). Les
guildes définissent généralement des standards communs, organisent des workshops,
des formations, des présentations de nouveaux outils, définissent des bonnes
pratiques…
Les pratiques de développement et de mise en production de Spotify sont entièrement

tournées pour maximiser l’autonomie des équipes et réduire les dépendances. Des
operation squads sont mises en place pour fournir des outils et des processus aux
équipes leur permettant d’être autonomes.
Afin de garder une cohérence des systèmes techniques communs à plusieurs squads,
Spotify introduit un rôle de System Owner. Travaillant généralement par pairs, ces
system owners coordonnent le travail des équipes sur le système en veillant à ce que la
documentation et la qualité du code soient assurées, que la dette technique soit
minimisée et prise en compte par les squads, les processus de release soient assurés…
154
KNIBERG, Henrik. Spotify engineering culture (part 1). Spotify R&D Engineering : 27 mars 2014.
https://engineering.atspotify.com/2014/03/27/spotify-engineering-culture-part-1/
205
/
Enfin, un Chief Architect est responsable d’assurer une cohérence du système

d’information dans son ensemble, notamment entre les différents systèmes.
Les problèmes de cette organisation

Henrik Kniberg et Anders Ivarsson ont toujours insisté sur le fait que cette organisation
n’était qu’un snapshot à un moment donné. Chaque organisation et chaque processus
pose des problèmes, et chaque solution à un problème crée de nouveaux problèmes.
L’essentiel est de parvenir à identifier ces problèmes et être en constante évolution.
Jeremiah Lee, ancien PM chez Spotify, également passé chez Fitbit et InVision, a
récemment publié un article155 sur ce qui ne marchait pas dans cette vision, et pourquoi
Spotify a abandonné ce modèle :
● Le modèle matriciel résolvait un problème qui n’existait pas. Un des objectifs de

cette organisation matricielle était de pouvoir facilement changer d’équipe sans
changer de manager, mais la plupart des équipes étaient stables sur le long
terme. Le rôle des chapter leads étant essentiellement de gérer la carrière des
membres de son équipe, ils n’avaient que peu de responsabilité. Ils n’avaient pas
non plus assez de contexte pour pouvoir trancher les éventuels conflits au sein
de l’équipe.
● Au sein de la squad, tous les membres de l’équipe de réalisation avaient le
même niveau de responsabilité. En cas de conflit, personne n’avait l’autorité
pour arbitrer en cas de désaccord technique. Et comme les différents ingénieurs
dépendaient de chapitres différents, il fallait que les différents chapter leads se
mettent d’accord entre eux, ou remonter d’un niveau encore pour avoir enfin
une décision.
Pour résoudre ce type de problème, la plupart des organisations produit mettent
en place un rôle de Tech Lead dans chaque équipe produit. Sans nécessairement
avoir l’ascendant hiérarchique sur les autres membres de l’équipe, ils sont
responsables de prendre les décisions quand le consensus est impossible.
● L’organisation Spotify posait comme principe fondamental l’autonomie des
squads. En scalant, Spotify a augmenté le nombre d’équipes sans remettre en
cause ce principe d’autonomie, alors que les dépendances entre équipes
devenaient de facto de plus en plus importantes. L’autonomie reste une vertu
fondamentale pour le succès d’une organisation produit, mais elle doit être
cadrée par des processus clairs :
○ Le rôle du leadership est de définir les priorités et la façon dont est
mesuré le succès. L’équipe peut être autonome dans la façon d’atteindre
ces objectifs prioritaires.
○ Les processus de collaboration entre les équipes doivent être clairement
définis et partagés. L’approche Team Topologies propose un modèle
intéressant.
○ Le corollaire de l’autonomie est la responsabilité. Si l’équipe n’est pas
assez mature pour être vraiment responsable, son autonomie doit être
réduite. Les équipes les plus matures sont celles qui peuvent bénéficier
155
LEE, Jeremiah. Failed #SquadGoals. https://www.jeremiahlee.com/posts/failed-squad-goals/
206
/
du plus haut degré d’autonomie, et les équipes les moins autonomes

doivent être formées et acculturées.
● La collaboration était une compétence considérée comme acquise, alors que
beaucoup de membres des équipes n’avaient qu’une connaissance basique des
principes agiles. Chaque équipe essayait d’itérer aveuglément sur ses processus
pour tenter d’améliorer le delivery, sans voir un langage commun pour tenter de
résoudre les problèmes ensemble.
Il faut former les équipes à l’agilité et en comprendre les principes sous-jacents.
Être formé à l’agilité ne signifie pas obtenir une certification Scrum. Oubliez
Scrum, comprenez le manifeste agile dans un premier temps.
En scalant, les organisations doivent se doter de personnes et d’équipes
chargées d’harmoniser les processus et de mettre en place un cadre de
collaboration efficace entre les membres d’une équipe et entre les équipes. C’est
notamment le rôle du Product Ops.
L’organisation matricielle de Veepee

Veepee a également mis en place une organisation matricielle assez différente de celle
de Spotify, qui résout certains des problèmes qui lui sont fréquemment reprochés. Là
encore, pas question de copier l’organisation de Veepee, chaque entreprise doit trouver
la bonne façon de procéder, et ne surtout pas considérer une organisation comme
figée.
Le modèle matriciel théorique de Veepee156
156
Voir aussi : La Product Conf - LPC & LPCx. Vente Privée : "Quelle est l'organisation Produit au sein de
VP?". Youtube : 21 mai 2018 [vidéo]. https://www.youtube.com/watch?v=PT0trP1oiIk
207
/
Chez Veepee, chaque équipe produit est organisée de façon autonome pour livrer son
périmètre, avec des objectifs business. Elle comporte un product owner (ayant le rôle
d’un PM), un UX, éventuellement un lead business et une équipe de réalisation (dev, QA,
infra…) avec un Lead Dev, pendant technique du PO capable de prendre les décisions
sur la partie réalisation et release.
L’ensemble des PO d’une ligne produit est hiérarchiquement rattaché à un Lead PO. De
même, tous les techs d’une ligne produit sont rattachés à un Lead IT, tous les UX à un
Lead UX et tous les business à un Lead Business, de sorte que les conflits au niveau de
la ligne produit (la tribu de Spotify) peuvent être tranchés au bon niveau hiérarchique,
au lieu d’avoir à escalader les problèmes techniques chapitre par chapitre.
Veepee conserve un management horizontal, en mettant en place des communautés de

pratique (les guildes), tant au niveau technique qu’au niveau business. Ce management
horizontal ne possède pas d’autorité hiérarchique sur ses membres, mais permet de
coordonner les approches entre les équipes produit. Par exemple, le Lead iOS
coordonne les pratiques de développement ainsi que le release de l’app. Côté business,
un Lead CRM animant les compétences dans plusieurs produits.
2.2 - Organiser la collaboration entre les équipes :

l’approche Team Topologies
Matthew Skelton et Manuel Pais157 ont réfléchi à la meilleure manière d’organiser les
équipes au sein d’une entreprise, et en particulier au sein des départements chargés de
développer les produits digitaux.
Leur point de départ est la loi de Conway, qui dit que le design des systèmes créés
par les organisations est le reflet de la structure de communication interne de
cette organisation158. Pour créer un système complexe, les membres de l’organisation
ont besoin de communiquer fréquemment. Appliqué au développement logiciel, une
organisation monolithique produira une architecture monolithique quand une
organisation en petites équipes produira une architecture plus modulaire. Une
organisation structurée en silos fonctionnels (architecture, infrastructure, exploitation,
réseau, maintenance…) produira un système d’information siloté non adapté à la
création de valeur globale.
Skelton et Pais préconisent la mise en place d’une organisation interne pensée

comme un système vivant centré sur des équipes autonomes et durables, de taille
réduite. L’objectif est de minimiser le plus possible la dépendance entre les équipes,
réduire la charge cognitive de chaque équipe pour leur permettre de se concentrer sur
157
SKELTON, Matthew & PAIS, Manuel. Team Topologies: Organizing Business and Technology Teams
for Fast Flow
Voir aussi l’intervention des auteurs au DevOps Enterprise Summit de 2019 : IT REVOLUTION.
Monoliths vs Microservices is Missing the Point—Start with Team Cognitive Load - Team Topologies.
Youtube : 8 juillet 2019 [vidéo] https://www.youtube.com/watch?v=haejb5rzKsM
158
CONWAY, Melvin E.. How do committess invent? Avril 1968.
http://www.melconway.com/Home/pdf/committees.pdf
208
/
la valeur qu’elles doivent délivrer et améliorer les structures de communication dans

l’organisation.
Les responsabilités et les interactions entre les équipes sont nécessairement amenées à
évoluer au cours du temps, en fonction des objectifs et des besoins. L’organisation du
département IT doit être mouvante, dépendant de ces besoins changeants. Les équipes,
elles, doivent rester le plus stable possible.
Les auteurs définissent 4 types d’équipes destinés à maximiser la valeur produite et

minimiser les dépendances :
● Stream-Aligned team : équipe pluridisciplinaire autonome chargée de créer de la

valeur par le développement d’un produit. Ce type d’équipe correspond aux
squads produit verticales que j’ai décrites : feature team, impact team, persona
team. Elles doivent être très largement majoritaires dans l’organisation (au
moins 80% des équipes). Les autres types d’équipes ont pour objectif d’aider ces
équipes verticales à maximiser la valeur.
● Enabling team : équipe chargée d’aider une ou plusieurs équipes stream-aligned
à devenir autonome(s). Ses rôles sont divers : conseil, adoption de frameworks,
coaching, équipement en outils, facilitation des interactions avec les autres
équipes... Une fois l’équipe verticale considérée comme suffisamment
autonome, l’enabling team a vocation à se retirer (et aider une autre équipe).
C’est dans ce type d’équipe qu’on retrouvera notamment des architectes
solution, des devops, des scrum masters…
● Complicated-subsystem team : il s’agit d’équipes de type “component team” qui
prennent en charge les systèmes les plus complexes du système d’information.
En effet, il serait contreproductif de demander à des squads pluridisciplinaires
composées de profils assez généralistes de s’attaquer à des systèmes
demandant un très haut niveau d’expertise. Il n’est pas non plus souhaitable ni
possible d’intégrer des experts d’une technologie dans toutes les squads
verticales susceptibles d’intervenir sur ce système.
● Platform team : les équipes plateforme sont en charge de livrer les couches
basses du système d’information, qui vont être utilisées par les autres équipes.
Leur objectif est de livrer des plateformes “as a service” qui peuvent être utilisées
de façon autonome par les autres. Il est critique pour ces équipes de s’assurer de
livrer uniquement les services qui seront utilisés par les autres, éviter de
s’éparpiller (concept de Thinnest Viable Platform - TVP).
Dans ce modèle, il n’y a plus d’équipe opération ni support, dont la présence contribue
fortement à limiter la production de valeur dans un environnement de continuous
delivery. Chaque équipe est responsable de bout-en-bout de son périmètre : phases
exploratoires, construction de la solution, livraison de la solution et maintenance, de
façon continue.
Skelton et Pais conseillent également de formaliser le mode d’interaction entre deux

équipes, afin de clarifier le rôle de chaque équipe dans la production de valeur. Ils
définissent trois types d’interaction :
209
/
● Collaboration : co-développement de la solution, essentiellement en phase de

discovery.
● Facilitation : une des équipes aide l’autre à supprimer des obstacles.
● X-as-a-service : une équipe fournit un service clé-en-main à l’autre.
Le mode d’interaction entre deux équipes peut changer dans le temps, en fonction de la
maturité des équipes. Par exemple, en phase de discovery, une équipe
complicated-subsystem et une équipe stream-aligned pourront travailler en
collaboration, pour ensuite passer sur une interaction X-as-a-service.
210
/
VII - Mettre en place le Produit dans votre organisation
Partie VII
Mettre en place le
Produit dans votre
organisation
Vous êtes convaincus par l’intérêt du product management ? Mais par où commencer ?
Vous devrez d’abord convaincre le top management de la pertinence de cette
démarche, en prenant un projet pilote et en en démontrant les bienfaits. Ensuite, vous
devrez pouvoir mettre en place une fonction produit dans l’organisation et œuvrer pour
changer profondément les pratiques et la culture.
211
/
1 - Comment convaincre le top

management ?
Le premier challenge est de convaincre le top management de l’intérêt de l’organisation
produit. Sans appui au plus haut niveau de l’entreprise, cette démarche est vouée à
l’échec : le business et le comité de direction continueront à pousser des projets sous
formes d’outcome (créer une application mobile, migrer le CRM vers une nouvelle
technologie, ajouter une nouvelle fonctionnalité au site web…) sans réellement se
préoccuper de savoir si le projet générera de la valeur pour le business et pour ses
clients, et en tout cas, sans être capable de le valider avant la fin du projet. Les projets
priorisés le sont généralement en fonction de l’intérêt des HIPPOs (highest paid
person’s opinion), plutôt qu’en fonction du ROI que l’organisation est en droit
d’attendre.
Comment les entreprises traditionnelles prennent des décisions.159
159
DUNARY, Enric. HiPPO’s (Highest Paid Person’s Opinion): Letting Data Drive Decisions. 25
novembre 2015.
https://www.enricdurany.com/agile-startup-entrepreneur/hippos-highest-paid-person-opinion-d
ata-driven-decision-making/
Illustration issue de : SCHMIDT, Eric & ROSENBERG, Jonathan, avec Alan Eagle, préface de Larry
Page. How Google Works. John Murray : 12 mars 2015. 304 p.
212
/
Le département chargé de délivrer ces projets restera un exécutant preneur d’ordres.

L’organisation continuera à produire énormément de déchets et à livrer très peu de
valeur au regard des investissements. Finalement, les équipes de réalisation risquent de
se démotiver rapidement.
Alors, par où commencer ?
Essayez quelques-unes de ces méthodes, en fonction de votre contexte, pour

convaincre le management d’essayer l’approche product management :
● Jouez sur le sentiment d’urgence : L’environnement est incertain et vous devez

être agile. Que vous soyez une entreprise B2B ou B2C, un service public ou une
association, les clients sont habitués à des expériences utilisateurs excellentes.
Des startups arrivent dans tous les domaines, et si vous ne vous disruptez pas
vous-même, quelqu’un d’autre le fera.
● Benchmarkez la concurrence : Si dans votre secteur d’activité des concurrents
directs ou indirects ont pris une vraie approche centrée utilisateurs, jouez sur
cette corde pour inciter à faire la même chose. Prenez notamment des exemples
aux USA, où la plupart des entreprises ont déjà pris conscience de la nécessité
de ce genre d’organisations et l’ont déjà au moins partiellement mise en place.
● Faites venir une star : organisez une rencontre ou une conférence avec des
leaders d’opinion susceptibles de faire comprendre l’intérêt d’une telle
démarche. Pensez aux CEO ou CPO de startups et scale-ups, aux VCs, ou à des
leaders de corporates ayant mis en place une démarche produit dans un secteur
d’activité connexe à celui de votre organisation.
● Démontrez ce qui ne va pas dans la façon de gérer les projets actuellement : le
manque d’alignement entre les attentes business et le résultat de ce qui est livré,
le coût et le délai exorbitants de certains projets (un site web à 3 millions, quand
des startups arrivent à sortir des sites plus performances pour 10 fois moins).
● Identifiez les gains que le management peut espérer de cette démarche :
aligner les livrables projet avec la stratégie business, prendre une autre
approche pour délivrer des projets qui n’avancent pas depuis des années,
améliorer le time-to-market, augmenter la qualité du produit, réduire les coûts
en évitant le gaspillage, améliorer la motivation des équipes, être vu comme une
personne “innovante” dans l’organisation…
Au final, votre objectif est d’obtenir la confiance du top management, pour qu’il ne
ressente plus le besoin de contrôler à chaque étape comment le budget de l’entreprise
est dépensé, pour se concentrer sur les objectifs stratégiques que l’organisation doit
atteindre.
1.1 - Identifiez un projet pilote

Pour convaincre le management, la meilleure méthode est de montrer que ça
fonctionne. Donc prendre un projet, et mettre en œuvre les méthodes que j’ai décrites
dans cette thèse.
213
/
Comment identifier le bon projet pilote ? Partez d’un problème, pas d’une solution.
Identifiez une opportunité externe (une valeur ajoutée que vous pourriez apporter à vos
clients), ou un problème interne (un processus trop compliqué que vous pourriez
digitaliser par exemple). Proposez de traiter ce problème en adoptant une démarche
centrée utilisateurs itérative, sans définir la solution dès le départ.
Quel type de projet pilote ?

Vous avez concrètement deux grandes options pour démarrer.
La première est de commencer par un projet d’innovation, qui n’est pas traité par
l’organisation. Votre objectif est d’apporter de la valeur au business en cas de succès,
sans compromettre d’activité existante en cas d’échec.
Choisissez un sujet relativement simple techniquement. Si l’initiative implique de

toucher à de lourds systèmes legacy, ou d’accéder à des données internes qui ne sont
pas exposées grâce à des API utilisables à la demande, vous avez de bonnes chances
d’échouer.
L’autre option est de changer un produit existant qui souffre de problèmes

importants : il ne délivre pas la valeur escomptée, ou il est trop coûteux et complexe à
maintenir par exemple. Cette option est souvent retenue quand le comité de direction
est conscient de la nécessité de changer de business model.
“Accor est un très gros groupe hôtelier. Historiquement, notre

cœur de métier était d’opérer des hôtels. Il y a deux ans, nous
avons fait un changement complet de notre business model,
qui a entraîné une réorganisation et une transformation. Nous
avons vendu nos hôtels. Nos clients ce ne sont plus les gens qui vont dans
les hôtels, mais les propriétaires hôteliers, qui choisissent de prendre la
franchise Accor. Plus d’un tiers de nos revenus aujourd’hui sont liés à un
certain nombre de produits et services digitaux que nous mettons à leur
disposition. Il y avait un vrai besoin d'accélérer la transformation digitale,
et de créer une direction Produit.” - Alix Boulnois Lombard, Chief Product &
Innovation Officer chez Accor
Dans ce cas, les changements sont potentiellement beaucoup plus importants pour
l’organisation : remplacer le site e-commerce d’un retailer, revoir la plateforme web d’un
média papier… Une petite équipe en mode “proof of concept” n’y arrivera pas seule.
Commencez par une phase de discovery poussée, et proposez un MVP validé par les
utilisateurs. Si vous convainquez le management, passez à l’étape supérieure.
Comment vous y prendre ?

Définissez dès le départ clairement l’objectif business du pilote. Soyez ambitieux, mais
pas irréalistes. Définissez également les indicateurs clés que vous allez utiliser pour
mesurer le succès de votre initiative. Vous pouvez utiliser la méthode des OKR par
exemple. Partagez ces objectifs et KPI et validez-les avec vos sponsors. Le succès (ou
l’échec) doit être le plus factuel possible. L’objectif est-il d’abord de valider un prototype
214
/
et donc d’acquérir de la connaissance ? Ou votre mandat est-il de livrer une première

version du produit aux utilisateurs ?
Mettez en place une équipe pluridisciplinaire pour cette initiative : nommez un

product manager, et donnez-lui l’autorité pour décider de la façon d’atteindre l’objectif.
Nommez également un designer pour le projet. Si vous n’avez pas d’UX designer,
prenez un consultant spécialisé dans le product design. Nommez également un lead
tech pour cette initiative. Avec ces trois profils, vous pourrez commencer les phases
d’étude : il sera toujours temps d’ajouter d’autres personnes quand vous rentrerez en
phase de delivery. Vous aurez probablement besoin de les former ou de les faire
coacher.
Adoptez une démarche inspirée de Lean Startup : commencez par connaître vos
utilisateurs et être certain que le problème est correctement formalisé et pertinent.
Sollicitez l’aide des parties-prenantes pour acquérir de la connaissance utilisateur et
avoir leur avis sur le problème. Expliquez votre démarche. Et surtout, approchez de
vrais utilisateurs.
Une fois le problème recadré, formalisez des hypothèses et cherchez des idées de
solutions. Là aussi, impliquez les parties prenantes dans des ateliers collaboratifs. Les
inclure dans le processus devrait vous aider à emporter l’adhésion sur la méthode.
Vient ensuite la phase de prototypage. Dans les grands groupes, un des problèmes est
de pouvoir passer outre de lourds processus IT. Affranchissez-vous de la bureaucratie
inhérente à la gestion de projets informatiques. Si vous devez passer devant des
instances de validation à chaque itération de prototype ou à chaque mise en production
agile, vous avez déjà perdu. A la place, formalisez dès le début une gouvernance ad-hoc,
en impliquant des parties prenantes (architecture, plateformes, sécurité…) qui devront
être disponibles.
Identifiez les actifs IT sur lesquels vous pourrez vous appuyer. Par exemple, si votre
organisation dispose déjà d’un accès à un cloud public, voyez si vous pouvez l’utiliser
pour construire vos prototypes et votre produit. Si les règles pour y héberger une
application sont simples, profitez-en. Si les conditions sont drastiques et nécessitent la
validation de plusieurs comités, optez pour une autre solution…
Vous devrez avoir l’appui de quelqu’un de haut placé pour avoir le droit d’utiliser des
outils non validés par votre IT : outils de prototypage, outils de NoCode, outils SaaS
prêts à l’emploi… Expliquez que votre objectif est d’acquérir de la connaissance sur vos
utilisateurs et de trouver des solutions business à des problèmes business. En
contrepartie, isolez votre MVP du reste de votre SI, pour éviter les incidents de sécurité
ou de production. Et si besoin, expliquez qu’il sera toujours temps d’utiliser les
standards lors de l’industrialisation du MVP (même si ces standards devront
probablement évoluer si vous souhaitez vraiment diffuser la démarche product
management !).
Donnez-vous une deadline pour réunir les parties prenantes et évaluer les progrès sur
votre initiative. Discutez à la fois des résultats business, et des enseignements sur la
215
/
méthodologie utilisée : les apports, les erreurs, ce que vous avez appris, ce qu’il faudrait
améliorer. Si vous n’avez pas atteint les objectifs business, concentrez-vous sur ce que
vous avez appris de vos clients et des problèmes. Expliquez également comment en
expérimentant à moindre frais, vous avez épargné à l’organisation d’investir dans des
développements lourds, pour le même résultat.
1.2 - Passez à l’intrapreneuriat

Un autre moyen de démarrer une stratégie produit est de mettre en place un
programme d’intrapreneuriat dans votre organisation : incubez des startups internes
à votre organisation, afin de créer des produits et services stratégiques innovants pour
servir les objectifs stratégiques.
Comment procéder ?
D’abord, définissez les objectifs stratégiques pour lesquels vous souhaitez mener le
programme d’intrapreneuriat. Pour chaque objectif, choisissez la direction sponsor
chargée du programme. Demandez-leur de désigner un pilote pour ce programme.
Définissez avec eux les critères qui guideront vos choix de projets.
Ensuite, créez un cadre pour incuber le programme d’intrapreneuriat. Vous aurez

besoin de ressources pour accompagner vos futurs intrapreneurs :
1. Une charte RH, pour permettre le détachement des intrapreneurs de leur

direction d’origine pour plusieurs mois, voire une année.
2. Un cadre juridique, pour notamment gérer les problématiques de propriété
intellectuelle.
3. Un lieu dédié, souvent appelé Lab, avec des bureaux dédiés, des outils
d’idéation, de prototypage… Les labs d’intrapreneuriat sont souvent isolés des
bureaux habituels de l’organisation, dans un autre bâtiment, pour favoriser la
démarche d’innovation en rupture avec les pratiques habituelles de
l’organisation.
4. Un programme d’accompagnement pour coacher les futurs intrapreneurs.
5. Des ressources IT, data et design dédiées, ainsi que des processus IT à même
de permettre cette innovation.
Mettez ensuite en place un système permettant d’opérer une première sélection de

projets, en ligne avec les objectifs stratégiques. Il peut s’agir par exemple d’un simple
appel à projet ouvert à tous les collaborateurs. Effectuez un premier tri des
candidatures reçues, sélectionnez les propositions les plus intéressantes, en lien avec
les objectifs stratégiques. Accompagnez ensuite les postulants encore en lice : ils
devront mûrir leur projet et le pitcher devant un jury composé des différents sponsors
du programme, qui vont choisir les projets retenus. Traitez cette partie comme si le
postulant était le fondateur d’une startup devant convaincre des investisseurs
potentiels en early stage.
216
/
temps, investissement et implication des différentes étapes de l’intrapreneuriat160
Le dispositif de sélection peut également prendre la forme d’un hackathon : un

événement interne, pendant lequel des collaborateurs internes vont travailler sur une
problématique particulière pendant un à trois jours et proposer une solution innovante
sous forme de prototype. Les lauréats du hackathon se voient proposer de rejoindre le
programme d’incubation intrapreneuriale.
Les intrapreneurs peuvent débuter un projet seul ou en équipe. Une fois les projets
retenus, les intrapreneurs choisis rejoignent le programme et quittent temporairement
leur direction d’origine. Le programme se déroule généralement en plusieurs phases :
1. Un bootcamp sur quelques jours pendant lequel les intrapreneurs sont formés
et coachés sur les principes de base de la démarche entrepreneuriale (modèle
économique, démarche produit, design thinking, agilité, techniques de discovery,
prototypage…). Les intrapreneurs affinent leur vision produit, leur proposition de
valeur et commencent éventuellement à travailler sur un prototype.
2. Pendant une première phase de quelques semaines, les intrapreneurs mûrissent
leur concept, rencontrent des utilisateurs et itèrent sur leur MVP.
Au bout de cette phase, un entretien a lieu avec les sponsors, qui décident si le
projet vaut le coup d’être poursuivi. Voyez cette étape comme un deuxième tour
de financement de la startup.
3. Pendant une deuxième phase de quelques mois, les intrapreneurs créent le
produit sur la base du MVP et le lancent sur le marché, pour les utilisateurs ou
clients finaux. A ce stade, la startup interne grossit souvent et peut être amenée
à recruter des personnes pour renforcer ses effectifs.
Tout au long du programme, les intrapreneurs sont accompagnés, notamment sur la

conception du MVP et le go-to-market.
NAKACHE, Samuel. 5 bonnes pratiques pour booster l’intrapreneuriat dans votre entreprise.
160
Yoomap : 1 mars 2017. https://yoomap.fr/pratique-booster-intrapreneuriat-entreprise/

217
/
Enfin, définissez dès le départ quelles sont les possibilités de sortie, à l’issue du
programme d’intrapreneuriat. Il arrive malheureusement que des projets qui
réussissent meurent après le programme, le cadre de sortie n’étant pas défini et
personne ne souhaitant les reprendre.
● La startup interne peut devenir une startup… externe, dans laquelle l’entreprise
investit.
● Elle peut également devenir une filiale à part entière de l’entreprise, qui conserve
sa dynamique innovante, l’esprit startup et la démarche produit.
● Elle peut être réintégrée au département sponsor. Attention à conserver l’esprit
d’innovation et la démarche produit qui ont fait le succès du projet. D’un autre
côté, cette option permet d’infuser la culture produit au sein du département.
● Le programme d’intrapreneuriat peut également servir de prétexte pour la
création d’un département produit au sein de l’organisation, chaque startup
devenant une ligne produit au sein du département.
Que deviennent les intrapreneurs ? Dans certains cas, ils deviennent les dirigeants de la
startup ou de la filiale créée à l’issue du programme, deviennent Head of Product au
sein du département produit ou responsable du produit dans leur département
d’origine. Parfois, ils ne souhaitent pas poursuivre l’aventure et retournent à leur poste
d’origine. Dans tous les cas, là aussi pensez à l’accompagnement des ex-intrapreneurs,
et comment capitaliser sur leur expérience.
1.3 - Et le product management au sein d’une startup ?

Dans une startup débutante, l’idée et la réalisation du produit est souvent la chasse
gardée du CEO. Assez rapidement, il n’a plus le temps de s’occuper pleinement du
produit, et recrute donc un product manager.
Néanmoins, de nombreux CEO ne parviennent pas à lâcher le produit, et le product

manager se retrouve à simplement exécuter ses idées. La startup se retrouve avec les
mêmes travers que les corporates, avec un product owner qui gère un backlog de
développement sans avoir ni l’autorité ni les moyens pour challenger ces idées.
Ne tombez pas amoureux de vos idées. Pratiquement personne n’a le génie suffisant
pour trouver seul les solutions qui vont révolutionner un marché dans lequel de
nombreux acteurs évoluent déjà depuis longtemps. A ce stade, les investisseurs n’ont
pas misé d’argent sur les détails de la solution que vous proposez, mais sur l’approche
que vous avez, votre vision et votre personnalité.
Laissez votre product manager challenger ces idées, et donnez-lui le pouvoir de définir
la roadmap pour atteindre votre vision. Permettez-lui de faire du discovery, d’aller voir
des clients, de proposer et tester des hypothèses. Adoptez une démarche
build-test-learn. Cette démarche produit ne signifie pas que vous êtes totalement
dépossédé du produit ! Vous pourrez bien sûr proposer des idées, mais votre PM aura
pour rôle de les challenger et de les modifier en fonction des retours terrain. Votre rôle
sera également de valider la roadmap proposée par votre PM.
218
/
2 - Mettez en place une

organisation produit
Grâce aux pilotes, vous avez acquis la confiance du top management. Ils ont compris
qu’une démarche différente peut amener à des résultats meilleurs : éviter d’investir
dans des initiatives qui ne fonctionnent pas, laisser l’intelligence et la créativité des
équipes trouver comment atteindre les objectifs stratégiques qu’il a donnés.
Comment transformer l’organisation pour mettre en place une culture et une démarche
produit ? C’est une longue transformation ! Les habitudes sont installées et
l’organisation traditionnelle de l’entreprise ne la favorise pas. Vous aurez besoin de
changements culturels, organisationnels, humains et technologiques pour réussir.
2.1 - Un changement culturel

Changer la posture du top management
Première difficulté, faire changer la posture du management. Si vous voulez vraiment
passer à une démarche produit, le rôle du top management doit évoluer :
● Le management doit définir sa vision pour l’organisation.

● Il définit également les objectifs stratégiques de l’organisation, et donc en
particulier ceux que doit atteindre le département produit.
● Il fournit les ressources humaines et financières nécessaires au
développement du produit.
● Par contre, il doit s’abstenir de dire quoi faire : il doit cesser de prioriser des
projets de “nouvelle application mobile”, de “nouvelles fonctionnalités sur le
web”, ou d’un nouveau système pour gérer les feuilles de paie.
● A la place, il doit dire “augmenter le lifetime consumer value”, “positionner
l’organisation comme un leader du développement durable sur son marché”,
“améliorer l’expérience client malgré la crise sanitaire du Covid-19” ou “améliorer
le processus de gestion de la paie”. Et définir conjointement avec le produit les
indicateurs clés qui permettent de mesurer la réalisation de ces objectifs.
La culture du planning doit disparaître. La plupart des plannings ne sont faits que
pour donner l’impression aux dirigeants qu’ils maîtrisent ce que les équipes font. Et la
plupart du temps, le seul résultat est des plannings non tenus qui créent des conflits
entre les départements. La plupart des deadlines sont inutiles : si l’initiative est livrée,
un mois après, rien ne change. N’imposez des dates seulement lorsqu’il y a une vraie
contrainte externe : une deadline réglementaire ou un évènement business (un salon
lors duquel le CEO doit présenter la dernière innovation par exemple). Dans ce dernier
cas, sachez négocier sur le périmètre.
219
/
Autre changement d’ampleur : cesser de considérer que le client du produit est le

département “business” de l’organisation (sauf évidemment pour les produits
internes). Non, ce n’est pas au marketing de dire si un produit fonctionne ou non. Le
marketing peut fournir des insights très intéressants sur le client, et c’est souvent un
partenaire privilégié pour le développement de produits customer-facing. Mais il est
indispensable que les équipes produit puissent aller voir les clients directement et
challenger leurs idées avec eux.
Ensemble, instaurez une culture de confiance. Le management responsabilise les

équipes, en retour les équipes doivent montrer qu'elles le méritent.
Une culture customer obsessed

Il ne doit pas y avoir beaucoup d’entreprises au monde, surtout parmi les plus grosses,
qui n’affirment pas être “customer centric”, centrée client. Mais dans beaucoup de cas, il
s’agit d’une posture sans mise en œuvre réelle.
Dans une culture produit, le client est réellement au centre de toutes les priorités
(ou l’usager dans le cadre d’un service public) : toute la démarche est centrée sur la
réalisation d’outcomes, plutôt que d’outputs. Chaque effort fait par les équipes vise à
améliorer l’expérience client et lui apporter de la valeur, dans le cadre du business
model de l’organisation.
“A chaque désaccord nous faisions un test utilisateur pour

prendre une décision rationnelle et sortir des avis subjectifs. Il
était facile d’avoir accès à des conseillers pour tester les
produits et solutions back-office. Pour les produits grand
public, telle que l’application commerciale “Ma Banque”, il était facile
d’aller dans un centre commercial et de trouver des clients du Crédit
Agricole. Nous avons démontré que ce n’était pas compliqué, qu’il valait
mieux le faire tôt plutôt que de s’apercevoir de nos erreurs après le
développement. Nous avons fait de très bons tests utilisateurs avec les
caisses régionales, sur un produit que les conseillers devaient utiliser en
agence à côté de leurs clients. Les caisses régionales ont trouvé des
conseillers qui sont venus faire les tests avec leurs propres clients, comme
un jeu de rôle.” - Marie Petit, CPO La Fabrique by CA et ex Chapter Lead UX chez
Crédit Agricole Technologies et Services
Dans cette optique, le discovery est essentiel. C’est cette phase qui permet de
vraiment savoir si le produit peut et va apporter de la valeur au client. Mettre en place
un cadre qui permette aux équipes de faire du discovery est un préalable au succès.
220
/
Une culture de l’outcome

Du top management aux collaborateurs, le nouveau paradigme doit être le résultat
business, la valeur créée pour les utilisateurs et pour le business, plutôt que les livrables
qui engendrent cette valeur.
Cette culture de l’outcome doit être omniprésente : les objectifs stratégiques, la

roadmap, la façon de mener le discovery, le backlog du delivery, le budget pour le
produit…
La politique d’augmentation et de primes, qui motive financièrement les

collaborateurs de l’organisation, devrait refléter cette culture de l’outcome. Dans une
organisation produit, les collaborateurs sont récompensés parce qu’ils ont acquis de la
connaissance sur le client et ses problèmes, et parce qu’ils ont livré des résultats
business, pas parce qu’ils ont livré une nouvelle fonctionnalité ou un nouveau produit.
Une culture de la data

Autre objectif du product management : dépassionner et rationaliser les débats. Le
succès ou l’échec d’une initiative est déterminé par des indicateurs clairs, mesurables et
partagés. Les équipes doivent être capables de mesurer l’avancement de ces
indicateurs à tout moment.
La data sert également à vérifier que les hypothèses validées en phase de discovery se
réalisent bien une fois en production. Les outils disponibles sur le marché permettent
de savoir très finement comme le produit est utilisé, ce qui fonctionne et ce qui ne
fonctionne pas, et donc d’identifier de vrais points d’amélioration pour délivrer de la
valeur au client.
L’équipe produit doit donc être parfaitement à l’aise avec le traitement et l’analyse de
données, y compris sur des systèmes internes. Si vos outils RH ne sont pas adoptés
correctement, vous pourrez probablement identifier quelle partie du processus ne
fonctionne pas si vous êtes capables de tracer les parcours utilisateurs au sein de l’outil.
Accepter l’échec, apprendre de ses échecs

Dans une organisation traditionnelle, l’échec intervient généralement à la fin d’un
projet, qu’il soit formalisé ainsi ou non. Dans la plupart des cas, même si le projet a été
livré selon les spécifications (et donc est un succès pour le chef de projet), il ne délivre
pas la valeur que l’organisation aurait pu en attendre au regard de l’investissement.
Dans une organisation ou l’échec n’est réalisé qu’à la fin du processus, il ne peut pas
être acceptable.
Avec une démarche produit, l’échec est constaté le plus tôt possible dans le projet,
pendant le discovery. Plus qu’accepté, l’échec doit être recherché : c’est en échouant
rapidement que les membres de l’équipe, et plus largement l’organisation, obtiendront
des insights, des validated learnings, des enseignements précieux sur les clients ou
221
/
usagers, leurs problèmes, leurs désirs… et donc sur les solutions qu’ils peuvent
apporter pour vraiment créer de la valeur.
Les collaborateurs de l’organisation doivent être confiants vis-à-vis du fait que l’échec ne
leur sera pas reproché, en particulier s’ils sont capables d’en tirer des enseignements
utiles. C’est une condition sine qua non pour mettre en place une culture de
l’innovation.
Une culture agile

L’agilité est un autre buzzword omniprésent dans le discours des entreprises. Dans une
organisation produit, c’est une démarche concrète. Rappelons les 4 grands principes du
Manifeste Agile :
● Les individus et leurs interactions plus que les processus et les outils
● La collaboration avec les clients plus que la négociation contractuelle
Le product management est basé sur une interaction forte entre les différentes
personnes qui interviennent dans la création du produit en créant des équipes
pluridisciplinaires et autonomes. Il permet d’optimiser le développement de produits
qui créent de la valeur. Il est centré sur la production de valeur pour le client. Enfin, il
promeut une démarche itérative qui permet d’adapter très fréquemment la roadmap
pour gérer les changements de priorités et délivrer les bonnes solutions pour répondre
aux problèmes des utilisateurs et générer du retour sur investissement de façon
optimale.
2.2 - Un changement organisationnel : cassez les silos

La plupart des organisations traditionnelles délivrant des produits logiciels ont une
organisation en silos : les équipes métier sont d’un côté, les équipes IT de l’autre, les
équipes design ou data encore séparées, chacun avec ses propres objectifs, sa propre
compréhension du problème, sa propre conception de la solution, sa propre estimation
du coût et du délai pour livrer cette solution.
Même au sein d’un département, les équipes sont silotées. Par exemple les équipes IT
sont souvent organisées par composant technique, les équipes plateforme et les
équipes projet/produit ont des objectifs différents, l’évolution d’un produit et sa
maintenance sont assurées par des équipes différentes, les architectes sont dans une
bulle à part, les sources de données sont gérées de façon hétérogène par chaque
département…
Souvent les organisations sont conscientes de ce problème de silos, qui nuit à la

livraison des projets de l’entreprise, augmente les coûts et produit une valeur assez
faible au regard des investissements. Les solutions apportées sont toutefois loin de
résoudre les problèmes. Elles procèdent à des réorganisations, qui visent à mettre dans
un même département, sous une même direction, des individus ou des équipes qui
222
/
doivent davantage collaborer. Le problème est qu’en créant ces nouveaux

départements, elles cassent certes d’anciens silos, mais en créent de nouveaux. Elles
demandent également aux membres des équipes de davantage communiquer, sans
mettre en place les moyens de communication, en se reposant uniquement sur les
individus. Or, en particulier dans les grandes entreprises, la communication entre
personnes éloignées, qui ne se connaissent pas ou qui ont des objectifs différents reste
compliquée, et les bonnes paroles du management n’y changent rien.
Créez un département produit

Au sein des organisations traditionnelles françaises, la gestion de projet est souvent
séparée en deux fonctions : la maîtrise d’ouvrage est chargée de déterminer les besoins
et de créer des spécifications fonctionnelles détaillées. La maîtrise d'œuvre est chargée
des spécifications techniques, du développement du produit et de la livraison du
produit en production. La maîtrise d’ouvrage correspond aux directions business,
quand la maîtrise d'œuvre est l’apanage de l’IT. Souvent, une fonction assistance à
maîtrise d’ouvrage est mise en place pour formaliser les besoins business et rédiger les
spécifications fonctionnelles à leur place, soit dans une direction autonome, soit via des
chefs de projets fonctionnels au sein de l’IT.
Cette séparation est typique de l’organisation en silos et ne fonctionne pas. Elle génère
énormément de déchets et est la cause de mésententes et d’incompréhensions
flagrantes entre des équipes ayant des objectifs différents. La MOA prend des décisions
pour livrer des projets sans inclure la MOE, la MOE ne peut pas tenir les délais et les
coûts imposés par la MOA, et au milieu l’AMOA est une fonction preneuse d’ordre sans
réel pouvoir de remettre en cause les initiatives inutiles. Avec l’introduction de
méthodes agiles, ces chefs de projets AMOA sont devenus des product owners au sein
du département IT, mais leur positionnement n’a pas changé. Ils ne sont toujours pas
vraiment “owners” de leur produit, restent preneurs d’ordre d’un business séparé.
La création d’une direction produit, propriétaire et décideuse sur la roadmap produit,

permet de casser ces silos et d’introduire une forme de neutralité entre les attentes
business et l’exécution IT. Dans une organisation produit, le business aide le
management à définir les objectifs stratégiques à atteindre, le produit définit quelles
sont les initiatives à mettre en place et la tech réalise le produit, le tout en collaboration
permanente.
La direction produit est garante de la prise en compte des intérêts de l’utilisateur dans
le développement des produits. Elle assure la cohérence des processus et des normes
au sein de l’organisation et également la cohérence de l’expérience utilisateurs.
L’agilité sans direction produit signifie délivrer efficacement un produit. La direction

produit est là pour assurer une adéquation entre cette livraison efficace, les besoins
business et les attentes des utilisateurs.
Créez des équipes pluridisciplinaires autonomes

La solution préconisée par l’approche product management est simple, je l’ai
mentionnée tout au long de cette thèse : créez des équipes regroupant les profils
223
/
nécessaires à la création ou à l’amélioration du produit, à la livraison du projet, de façon

à ce qu’elles soient le plus autonomes possible.
Créer une équipe autonome ne signifie certainement pas regrouper les personnes sous
un même manager ! Gardez votre structure hiérarchique actuelle si vous le souhaitez,
mais regroupez-les au sein d’une même structure à laquelle vous donnerez un objectif
business commun.
Ces équipes doivent avoir une responsabilité verticale, c’est à dire être responsable de
la livraison de valeur business identifiée, plutôt que de faire partie d’une chaîne
d’équipes qui ne produisent de la valeur que collectivement.
Pour être autonomes, ces équipes doivent être empowered, c’est-à-dire que
l’organisation et le management doivent leur donner les moyens de livrer leurs objectifs
: elles doivent avoir les compétences nécessaires, l’équipement adéquat, la possibilité
de changer les méthodes et processus qui ne conviennent pas, et l’assurance que le
management ne cherchera pas à leur imposer les solutions pour parvenir à ces
objectifs.
Co-localisez les équipes

Autant que possible, mettez tous les membres de l’équipe au même endroit : ces
personnes vont travailler ensemble quotidiennement pour atteindre un objectif
commun. Elles ont besoin de pouvoir communiquer en permanence, échanger des
informations, s’assurer qu’elles ont une compréhension commune des enjeux. En les
mettant toutes sur un même plateau, elles apprendront à mieux se connaître, à mieux
communiquer entre elles, et au final à réellement avoir le sentiment de faire partie
d’une même équipe.
Concrètement, ça signifie un bureau ou un coin d’open space où le product manager,

les développeurs, les designers, les data analysts, les marketers, les ops… qui travaillent
sur le produit sont tous assis côte à côte. Fournissez-leur également des outils pour
travailler de façon collaborative : des tableaux, des post-its, des marqueurs pour qu’ils
puissent mettre en place un management visuel et, éventuellement, un accès à une
salle fermée pour des séances d’idéation si d’autres équipes sont sur le même open
space…
S’il n’est pas possible de co-localiser tous les membres de l’équipe, parce qu’ils se
trouvent sur différents sites par exemple, fournissez-leur des outils numériques pour
optimiser leur travail : outils de visioconférence, tableaux blancs virtuels, roadmap et
backlog virtuels, chat et partage de documents collaboratifs...
Donnez des objectifs communs à toutes les membres de l’équipe

Les membres de l’équipe doivent tous œuvrer pour atteindre un objectif commun :
traduisez cet objectif commun dans les objectifs individuels de chaque membre de la
squad. Mettez des objectifs business concrets, avec des valeurs chiffrées, en utilisant
224
/
par exemple les OKR. Mettez-vous d’accord avec les managers de chaque membre de
l’équipe et fournissez leurs les mêmes objectifs annuels.
● En alignant les objectifs de l’équipe avec les objectifs individuels impactant

directement la rémunération des membres, vous impliquez les membres de
l’équipe sur la livraison de valeur pour l’organisation.
● Moins les membres de l’équipe auront d’objectifs différents (en dehors de leurs
objectifs propres de développement personnel), plus vous vous assurez qu’ils
resteront concentrés sur la livraison de valeur, plutôt que de se disperser.
Assurez-vous que ces objectifs soient des outcomes, c’est à dire basés sur la production
de valeur business, plutôt que des outputs, des livrables ou des fonctionnalités. Par
exemple, donnez-leur comme objectif “augmenter de 20% le panier moyen sur le site
web” ou “réduire de 30% le temps moyen passé par le service client pour l’onboarding
de nouveau client”, plutôt que “livrer une fonctionnalité de recommandation de
produits” ou “dématérialiser telle tâche du service client en la mettant en self-service
sur le compte client en ligne”.
Améliorez le système de communication entre les équipes

Même si vous parvenez à mettre en place des équipes autonomes, elles ne restent pas
dans leur bulle sans interaction avec le reste de l’organisation. Vous devez expliciter
quelle est l’interaction souhaitée entre les différentes équipes.
La communication entre les équipes passe par 2 axes majeurs :
● Comme préconisé dans l’approche Team Topologies, explicitez la relation entre

les équipes. Simplement dire que les équipes doivent communiquer ne
fonctionne pas : cette communication doit être formalisée et partagée. Est-ce
que les équipes doivent collaborer (et pourquoi) ? Est-ce qu’une des deux
équipes fournit un service à l’autre (et dans ce cas, ce service doit figurer
clairement dans ses objectifs) ? Est-ce qu’une des équipes aide l’autre ?
● Créez des communautés de pratique : tous les membres des différentes équipes
qui partagent des intérêts communs ou des compétences doivent pouvoir
trouver des instances permettant de partager les bonnes pratiques, échanger
avec leurs pairs sur des problèmes particuliers, se former entre eux…
Inspirez-vous des guildes et des chapitres de Spotify par exemple.
2.3 - Un changement humain : des équipes avec les bonnes

personnes
Une organisation produit signifie de nouvelles compétences, un nouveau mindset, et
une nouvelle expertise. Vous devrez mettre en place un cadre pour redéfinir les rôles et
responsabilités des collaborateurs qui restent dans l’organisation, recruter de nouvelles
personnes et vous faire accompagner pour mener à bien ce changement.
225
/
“Chez Crédit Agricole Technologies et Services, nous avons

transformé toute l’entreprise en changeant le mode de
delivery : passer d’un mode projets, et de projets cathédrales
sur plusieurs années à une organisation produit, pour diviser
le time-to-market par trois et mettre l’expérience utilisateurs au coeur de
nos enjeux. Nous avons remis à plat le modèle managérial en supprimant
trois couches de management. Nous avons changé tous les modèles de
compétences : beaucoup de métiers n’étaient plus adaptés, beaucoup de
nouveaux métiers créés, et une nouvelle expertise qui manquait. Nous
avons mis en place un énorme programme de recrutement : 500
recrutements, dans une entreprise de 1500 personnes. Également, un gros
programme de formation et de re-skilling : quand on est chef de projet
informatique depuis 20 ans et qu’on devient Scrum Master ou Product
Owner, c’est compliqué”. - Marie Petit, CPO La Fabrique by CA et ex Chapter
Lead UX chez Crédit Agricole Technologies et Services
Recrutez un leader produit

Mettre en place une organisation produit est une démarche complexe, qui implique de
nombreux changements, tant au niveau de l’organisation, de la culture ou des
personnes. De nombreuses organisations ont choisi de recruter des leaders ayant
déjà dirigé des organisations produit avec succès, soit dans des startups ayant scalé
avec succès, soit dans de grands groupes américains type GAFAM. Le recrutement d’un
leader produit nommé par le CEO est un signal fort que les choses doivent et vont
changer !
Par exemple, pour développer l’application myCANAL dans une approche produit, le
groupe Canal+ a recruté l’ancien Head of Product de la startup Molotov. Pour
accompagner son changement de business model et prendre le virage du produit,
Accor a nommé une ancienne d’Amazon au poste de SVP Product & Innovation.
Lorsqu’elle a voulu tenter l’aventure mobile en adoptant une démarche centrée
utilisateurs, AXA a recruté un profil venant des startups et des entreprises tech
californiennes. Pour diriger son département produit, Carrefour a choisi le fondateur de
la startup Lucky Cart.
Travaillez sur les rôles et responsabilités

Le rôle des collaborateurs dans une organisation produit change en profondeur.
Travaillez bien la définition des responsabilités de chaque rôle : quelles sont les
prérogatives d’un product manager, d’un product designer et d’un lead développeur
notamment. Redéfinissez le rôle des managers et celui des équipes transverses
(productops, coachs…). En passant à une logique DevOps et de plateforme interne, le
rôle des ingénieurs systèmes change complètement. Un ingénieur d’exploitation
“classique” et un DevOps ou un SRE n’ont pas les mêmes compétences. Ensuite,
226
/
travaillez avec chaque personne pour choisir ensemble quel devrait être son rôle dans
l’organisation produit en fonction de ses sensibilités et de ses compétences.
Le principal nouveau rôle est celui de product manager. Fonctionnellement, il prend la

place du chef de projet, mais ses compétences, ses responsabilités, ses prérogatives et
son état d’esprit sont totalement différents. Les chefs de projets ne doivent pas
automatiquement devenir des product managers. Dans certains cas, il vaut mieux que
le product manager soit une personne venant du “métier”, ayant une bonne
connaissance du marché et des clients, plutôt qu’un profil IT qui sait correctement
exécuter mais qui sera incapable d’avoir la vision stratégique nécessaire pour le poste.
Entourez-vous des bonnes personnes

Comme dans toute transformation organisationnelle, vous aurez des personnes
moteurs, des opposants, et des hésitants.
La carte des partenaires : 8 types de comportements face au changement.161
Reposez-vous sur les personnes convaincues et motivées pour faire changer

l’organisation, et travaillez avec les hésitants pour les acquérir à votre cause.
Formez-les, montrez-leur les bénéfices de ce nouveau mode de travail. Neutralisez et
isolez les opposants.
161
BURIN, Jean Baptiste. Repérer les jeux d'acteurs pour faciliter le changement. JDN : 25 août 2014.
https://www.journaldunet.com/management/efficacite-personnelle/1142332-reperer-les-jeux-d-
acteurs-pour-faciliter-le-changement/
227
/
Vous aurez besoin de recruter, pour combler les expertises que vous n’avez pas. Dans
un premier temps, songez également à faire appel à des consultants en régie,
spécialisés dans le product management. Ils vous permettront non seulement de
délivrer rapidement des initiatives, mais aussi d’infuser la culture produit et de partager
les bonnes pratiques avec les collaborateurs.
Accompagnez et formez les équipes

Pour opérer sa transformation, l’organisation doit se doter des compétences
nécessaires à la mise en place d’une démarche produit, que ce soit au niveau des
couches managériales (head of product, VP product, CPO…) ou des équipes
elles-mêmes.
Bien souvent, cette transformation passe par le recrutement externe de profils seniors,
notamment à des postes de direction, ou pour certaines expertises manquantes (le
design par exemple). Elle passe également par la formation des équipes en place, pour
qu’elles maîtrisent les enjeux et les techniques propres à ce nouveau mode de
fonctionnement.
Pour les équipes de réalisation, cela passe notamment par des formations à l’agilité.
Soyons clairs, une certification de base à Scrum ne suffit pas à transformer un
développeur ou un architecte en lead technique d’un squad produit.
Les nouveaux product managers de l’organisation seront probablement d’anciens chefs

de projets, business analysts ou experts métiers qu’il faut former au monde du product
management : comment déterminer les bonnes évolutions du produit grâce au
discovery, comment prioriser et gérer une roadmap orientée outcomes, comment
travailler avec la squad en mode agile, comment exploiter des data…
Plusieurs formations courtes existent sur le marché. J’en citerai quelques-unes, liste
probablement loin d’être exhaustive :
● Thiga, une des principales agences de conseil en produit en France, propose des
parcours complets pour product managers de tous niveaux : formation
individuelle de PM, senior, lead, head of ou CPO ou formation collective en
entreprise sur mesure, pour former les équipes et le management.
https://thiga.academy/formations
● Hubvisory, autre agence de conseil spécialisée dans le produit et l’agilité,
propose différentes formules de cours au sein du l’Hubvisory Institute : une
formation théorique en 2 jours, un Learning Sprint sur 3 jours ou plus avec
application sur les produits des participants, un parcours sur mesure appelé
“Product University”, ou encore “Product Online”, une formation certifiante en
ligne.
https://hubvisory.com/offre-institute/
● BeNext, société de conseil spécialisée dans l’agilité et le produit dispense une
formation sur le product management agile sur 2 jours.
https://formation.benextcompany.com/agile-product-management
228
/
● Zenika, cabinet de conseil spécialisé dans la transformation digitale, propose

également une formation en 2 jours sur le product management.
https://training.zenika.com/fr-fr/training/product-management/description
● Lion propose des formations sur mesure aux corporates pour qu’elles adoptent
les meilleures techniques issues des startups, parmi lesquelles le product
management.
https://joinlion.co/formation-lion-pour-grand-groupe/
● Meraki propose un cycle de formation en 6 samedi, grâce à des CPO de startups
et scale-ups reconnus.
https://meraki.pm/
● Créé en 2020 par une ancienne PM/VP Product de Blablacar et Aircall, Noé
propose un accompagnement en 3 mois, soit 1 mois de formation intensive par
des PM de scale-ups et 2 mois de coaching en entreprise. Cette formation
s’adresse plutôt à des personnes qui cherchent un poste en startup
https://www.noe.pm/
● Maestro forme des product managers grâce à un bootcamp de 7 semaines
couvrant tout le cycle de conception d’un produit à l’aide d’un cas pratique réel,
accompagné par des PM de startup et scale-up reconnus.
https://www.joinmaestro.co/
● Le groupe Centrale Supélec propose une formation de product manager agile
en 4 jours, incluant une introduction à Scrum, au Lean Startup et au Design
Thinking.
https://exed.centralesupelec.fr/formation/executive-certificate-agile-product-ma
nagement/
● Berkeley Executive Education dispense une formation en ligne et en anglais
sur 8 semaines via son Product Management Studio.
https://executive.berkeley.edu/programs/product-management-studio
● La Product School assure des formations certifiantes en ligne, en anglais
uniquement, pour PM, lead PM ou aspirant CPO, assurés par des leaders des
entreprises tech de la Silicon Valley.
https://productschool.com/
● Openclassroom délivre un diplôme de product manager, grâce à une formation
en ligne.
https://openclassrooms.com/fr/paths/163-product-manager
● Coursera propose également un cycle de formation en ligne en product
management, en anglais uniquement.
https://www.coursera.org/specializations/uva-darden-digital-product-manageme
nt
Certains cabinets de conseil proposent également de mettre en place une structure de

formation et d’accompagnement interne à l’organisation.
229
/
2.4 - Une nécessaire refonte technologique

Mettre en place des pratiques de développement agiles au sein du département Tech
de l’organisation n’est pas suffisant pour délivrer de la valeur, mais c’est une pratique
pratiquement obligatoire pour passer à une démarche produit orientée utilisateurs.
Au-delà des pratiques de développement agiles, la démarche produit implique très

souvent un changement technique drastique au sein des organisations ayant un
système d’information complexe en place.
Pour pouvoir mettre en place des équipes autonomes avec une responsabilité verticale,
du type feature team ou impact team, l’architecture du système d’information doit être
la plus modulaire possible. De la même manière, il n’est pas possible d’adopter une
démarche DevOps de Continuous Deployment sur des systèmes monolithiques.
Pour être capables d’améliorer le time-to-market et de livrer rapidement de la valeur au

client, les systèmes d’information legacy doivent souvent être largement repensés,
rationalisés et optimisés pour mettre en place une architecture orientée service (SOA)
voire microservices, basée sur des API facilement exploitables. Le passage à une
infrastructure cloud (idéalement SaaS ou PaaS) est un prérequis pour rendre les
équipes autonomes.
“Dans beaucoup de grosses entreprises, les systèmes IT legacy

empêchent de créer des feature teams autonomes pour créer
des fonctionnalités de bout en bout. Ca implique énormément
de coordination, de dépendances, de besoins d’alignement,
des arbitrages dans les roadmaps. C’est un vrai challenge pour ces
entreprises, une des raisons pour lesquelles beaucoup ne créent pas de
direction produit, restent dans des silos, dupliquent des ressources. Je
pense que c’est un des très gros freins aujourd’hui.” - Alix Boulnois Lombard,
Chief Product & Innovation Officer chez Accor
Ces changements sont généralement coûteux et longs à mettre en place. Travaillez avec
la tech pour définir les priorités.
2.5 - Une redéfinition des processus

Changez votre façon de prévoir les budgets
Dans une organisation classique, les budgets alloués aux projets ou aux produits sont
souvent définis de façon annuelle sur la base de business cases. A ce stade, il est
pourtant impossible de savoir si une initiative va effectivement délivrer un résultat
pertinent, ni de connaître les ressources nécessaires pour mener l’initiative.
Pendant l’année, les équipes doivent dépenser le budget qui leur est alloué. Impossible
d’utiliser un éventuel budget non dépensé pour l’année suivante. Souvent, si le budget
n’a pas été dépensé, le top management alloue un budget moindre l’année suivante.
Cela signifie que si l’équipe trouve un moyen pour livrer plus rapidement une initiative,
230
/
voire qu’elle démontre qu’une initiative est inutile et qu’elle ne doit pas être poursuivie,
l’équipe chargée de cette initiative risque d’avoir moins de ressources l’année suivante.
Cette façon de gérer les budgets incite les équipes à dépenser le budget alloué pour des
choses inutiles !
Cette façon de gérer les budgets ne fonctionne pas dans un environnement agile
nécessaire à l’innovation. D’après une étude de Bain & Company, seulement 5% des
entreprises reconnaissent que leur processus de financement et de planification est
suffisamment flexible pour supporter un grand nombre d’équipes agiles162.
Plutôt que de financer des budgets sur base annuelle, adoptez une approche
similaire à celle des Venture Capitalists qui financent des startups :
Exemple de processus budgétaire proposé par Bain & Company
1. De façon régulière, chaque équipe ou chaque département présente ses

objectifs et pitche sa roadmap aux financeurs (le comité de direction, ou un
sous-comité en charge de financer ces initiatives)
2. Financez les étapes au fur et à mesure des étapes de la livraison produit
○ Par exemple, l'équipe a besoin de 50k€ pour mener des recherches
utilisateurs et analyser de la data pour déterminer si une initiative vaut la
peine d’être menée, financez-les.
○ Au bout de quelques semaines, si l’équipe a démontré que l’initiative peut
apporter de la valeur et qu’elle a besoin de 200k€ pour creuser le sujet et
travailler sur son MVP, financez l’initiative si elle vous paraît pertinente.
162
JOHNSON, Darren, BEREZ, Steve & DELAVA, Fabian. How to Plan and Budget for Agile at Scale.
Bain & Company : 8 octobre 2019.
https://www.bain.com/insights/how-to-plan-and-budget-for-agile-at-scale/
231
/
○ Après avoir construit une première version livrée aux utilisateurs qui
commence à être adoptée, passez au financement à grande échelle,
plusieurs millions si besoin.
○ A un moment, si l’équipe démontre que la valeur espérée n’est pas au
rendez-vous, ou si les outcomes générés par le produit ne sont pas ce que
vous espérez, diminuez ou arrêtez le financement, et allouez le budget à
une autre initiative.
Si vous mettez en place une équipe centralisée pour mener la recherche utilisateur,
attribuez-lui un budget dédié, qui sera complété par le budget alloué à chaque initiative
pour prendre en charge des sujets spécifiques.
Dans un environnement agile, soyez flexible dans la manière de gérer vos budgets.
Adoptez une approche ROIste : basez-vous sur les OKR, et financez les initiatives à la
mesure de ces OKR.
Eliminez les réunions inutiles, mettez en place des rituels

Les collaborateurs d’une organisation passent bien trop de temps et réunion, plutôt
qu’à travailler sur leurs initiatives et livrer de la valeur. En moyenne les salariés passent
8 heures par semaine en réunion, et près de la moitié du temps de réunion ne sert à
rien163.
La création d’équipes pluridisciplinaires et autonomes devrait énormément réduire les

besoins de réunions. La co-localisation favorise les échanges informels, et permet aux
membres de l’équipe de régler rapidement les différents problèmes qui pourraient
survenir. Le management visuel permet également à chaque instant à tout membre de
l’équipe, et aux stakeholders, de savoir où l’équipe en est. Encouragez également les
moments de partage au sein des équipes, de type afterwork ou team building.
Plutôt que de mettre des réunions, favorisez les rituels. Au sein de l’équipe,
déterminez des rendez-vous fixes pour traiter des sujets récurrents. Instaurez
également des rituels avec les parties prenantes pour échanger de façon régulière avec
eux. Pour chaque rituel, assurez-vous que l’objectif soit clair et partagé, et
communiquez l’ordre du jour à l’avance. Si vos rituels sont pertinents, les gens se
presseront pour y assister.
Voici quelques exemples de rituels :
● Daily meeting avec l’ensemble de l’équipe, de 15 minutes maximum, tous les

jours.
● Revue du backlog périodiquement (à la fin de chaque sprint en scrum, à la
demande en scrumban, à vous de voir en fonction de vos besoins)
● Revue de produit ou session de démo, à intervalles réguliers, pour démontrer
au business les avancées de l’équipe.
163
SOYEZ? Fabien. Les salariés passent 8 heures par semaine en réunion. Courrier Cadres : 4 janvier
2019.
http://courriercadres.com/entreprise/vie-au-travail/les-salaries-passent-8-heures-par-semaine-e
n-reunion-04012019
232
/
● Présentation de roadmap, afin que n’importe qui dans l’organisation connaisse

les priorités du prochain cycle pour l’équipe produit. Point bonus : organisez
toutes les présentations de roadmap pendant la même semaine à intervalles
réguliers, à l’heure du déjeuner, en prévoyant des sandwichs pour les
participants.
● Enfin, prévoyez des points réguliers pour discuter de l’amélioration continue de
vos processus, normes, outils... En langage agile on appelle généralement ce
rituel rétrospective.
● Rituels réguliers de synchronisation entre les équipes ayant des
dépendances.
Supprimez la bureaucratie, favorisez la collaboration

Les grandes entreprises ont souvent mis en place un processus lourd de gestion et de
validation de projets, à base de comités de validation de spécifications fonctionnelles et
techniques et de validations par le management à chaque mise en production. Dans
une structure agile, et encore plus dans une organisation produit, cette approche n’est
plus possible. Elle n’est pas compatible avec la livraison continue de valeur au client. Elle
crée un goulot d’étranglement et ralentit la boucle de feedback.
Pour quelles raisons les organisations traditionnelles mettent en place ces instances de
validations ?
● Elles ont besoin de s’assurer que les contraintes réglementaires et de sécurité

sont bien prises en compte.
● Elles sont un moyen pour contrôler que l’architecture du système d’information
est cohérente.
● Elles permettent de valider le passage du mode projet au mode support.
● Enfin lors de ces instances le management “tamponne” le projet, et contrôle que
les livrables sont cohérents avec ce qui était prévu au départ.
En mettant en place des équipes autonomes, ces instances de validation n’ont plus de
sens, ou en tout cas, plus sous cette forme.
Définissez en amont de la création du produit les contraintes à imposer aux

équipes : contraintes réglementaires, contraintes techniques, contraintes de sécurité…
Si besoin, mettez en place des enabling teams (au sein Team Topologies) pour
accompagner les équipes au démarrage d’une initiative produit.
Le PM doit s’assurer que son produit est conforme avec les règles business, y compris la
réglementation et la gestion des données personnelles. Ne cherchez pas à valider que
tout est conforme à chaque livraison, vous n’y arriverez pas. A la place, mettez en place
des rendez-vous réguliers pour vérifier que tout est toujours en place. Ajoutez ces
contraintes dans les normes de travail des équipes, et assurez-vous que les QA les
prennent en compte dans leurs tests. Si votre produit est particulièrement sensible à
certaines réglementations, intégrez un expert dans l’équipe, ou en tout cas un
référent au niveau de la direction produit concernée, pour qu’il soit impliqué et tenu au
courant de tous les développements qui peuvent le concerner. Une alternative est de
233
/
mettre en place des impact squads dédiées à la mise en place de contraintes

réglementaires164.
Prenez en compte les contraintes de sécurité dans l’intégralité de votre processus de

gestion produit. Adoptez une démarche “privacy and security by design”165. Mettez en
place du DevSecOps dans vos pipelines de continuous development pour automatiser
le plus possible la validation des standards de sécurité des produits.
Les lead developers sont responsables de l’application des principes

d’architecture. En mettant en place un système d’information basé sur des
microservices, des outils de DevOps et des plateformes “as a service” (PaaS) en interne,
vous diminuez les risques de créer des services à l’architecture non maintenable. En
fonction de la maturité des équipes, vous pourrez leur laisser plus ou moins
d’autonomie sur l’utilisation des standards. Certaines organisations mettent également
en place un rôle de Delivery Manager166, qui s’assure que les standards de l’organisation
sont bien respectés dans la livraison de chacun des produits.
Dans une organisation produit, il n’y a plus de distinction entre projet et support :
l’équipe est chargée de son périmètre de bout en bout. S’il y a un incident majeur en
pleine nuit, c’est à eux de se lever pour corriger le problème. C’est évidemment un
argument très fort pour inciter les équipes à rendre les processus de maintenance clairs
et de s’assurer que ce qui est passé en production est stable. Au pire, la mise en place
du continuous delivery permet de corriger très rapidement les problèmes identifiés en
production.
Enfin, le rôle du management ne devrait plus être de contrôler le travail des équipes.
Les équipes sont objectivées par la production d’outcomes, et le rôle du management
est de s’assurer que ces outcomes sont bien délivrés. Ralentir le processus en mettant
des instances de validation lourdes ne fait que ralentir la livraison de ces outcomes. La
culture de confiance passe aussi par la suppression de ces instances de contrôle.
2.6 - Communiquez sur votre démarche

La mise en place d’une organisation produit est un processus long et vous devrez
convaincre vos équipes et vos stakeholders de la démarche.
Les équipes, d’abord, doivent comprendre la direction dans laquelle vous souhaitez
aller, et pourquoi. Elles vont devoir travailler différemment d’avant et être beaucoup
plus autonomes, et la résistance au changement peut entraîner l’échec de votre
démarche si vous ne la prenez pas en charge.
164
Voir par exemple un poste de Compliance Product Lead chez Square, Inc. :
https://jobs.smartrecruiters.com/Square/743999673307279-compliance-product-lead
165
GREENWOOD, Lyne. Privacy and security by design for product management. Akvo : 26 avril
2018. https://akvo.org/blog/privacy-and-security-by-design-for-product/
166
SRINIVASAN, Rajesh. The transformed role of a delivery manager in Agile-DevOps model. HCL :
22 janvier 2019.
https://www.hcltech.com/blogs/transformed-role-delivery-manager-agile-devops-model
234
/
Les stakeholders eux risquent de voir d’un mauvais œil cette équipe qui vient prendre
une partie de leurs prérogatives. Discutez avec eux de la place de chaque département,
et explicitez les responsabilités de chacun. Expliquez-leur comment vous souhaitez
collaborer, et les bénéfices attendus. Impliquez les dans les décisions. Organisez des
workshops avec eux, comme des ateliers de story mapping ou d’impact mapping, ou un
design sprint. Communiquez largement sur vos roadmaps, et écoutez les feedbacks.
Enfin dans tous les cas, communiquez sur vos succès : organisez des sessions de retour
d’expérience, montrez les produits que vous avez délivrés, la valeur que vous avez créé
pour vos clients. Expliquez la démarche que vous avez employée, et démontrez la
connaissance du client que vous avez acquise grâce à la data et au discovery.
2.7 - Comment travailler avec des partenaires, des

consultants et des agences ?
Lorsque vous développez vos produits, vos collaborateurs adoptent une posture de
missionnaire, pour délivrer des outcome business, et non simplement des outputs, des
livrables techniques sous forme de logiciels ou de fonctionnalités.
En travaillant avec des entités extérieures, que ce soit sous forme de partenariats ou via
des consultants et des agences, vous perdez en partie cette attention sur les outcomes.
Néanmoins, dans certains cas vous serez obligés de passer par des ressources
externes, pour bénéficier d’une expertise que vous ne possédez pas en interne ou pour
intégrer des services que vous ne souhaitez pas développer vous-même. Quelle
approche devez-vous prendre ?
Comment monter des partenariats avec d’autres organisations ?

Les partenariats peuvent être technologiques (vous utilisez une technologie créée par
votre partenaire dans votre système d’information, par exemple l’utilisation d’une
plateforme Cloud comme AWS ou un CRM de type Salesforce), ou intervenir dans votre
processus client (intégrer une plateforme de paiement par exemple, ou mettre en place
un partenariat de distribution).
Quand vous construisez un produit en interne, vous maîtrisez le cycle produit du début
à la fin. Vous menez le discovery et mettez un premier produit en production, puis vous
pouvez itérer en fonction des feedbacks clients. Lorsque vous vous reposez sur des
produits externes, vous êtes liés par les dépendances, les compétences et les priorités
de vos partenaires.
Dans de nombreux cas, vous ne voudrez pas construire intégralement un produit. Se

reposer sur des offres performantes du marché permet évidemment d’alléger les coûts
de production et de bénéficier de l’expertise de ces partenaires, hors de vos
compétences cœur de métier.
235
/
Concrètement, la relation de partenariat dépendra de votre taille et de celle de votre

partenaire167 :
● Si vous êtes plus gros que vos partenaires, vous avez probablement le pouvoir
d’influencer sa roadmap. Votre partenaire risque d’être plus agile dans sa façon
de travailler, en particulier s’il s’agit d’une startup. Apprenez à les connaître et à
faire de leur agilité une force. Évitez de ruiner le partenariat en en demandant
trop à votre contrepartie et en les forçant à faire des choses sur mesure, qui ne
cadrent pas avec leur vision.
● Si vous êtes plus petit que votre partenaire, identifiez les leviers que vous pouvez
avoir dans la relation, pour éviter d’être trop dépendant de la vision du
partenaire. Évaluez les bénéfices que vous pouvez tirer de ce partenariat, et
l’impact qu’il pourrait avoir sur votre roadmap. Préparez-vous à effectuer la
majeure partie du travail dans le cadre de ce partenariat. Votre partenaire risque
d’être beaucoup plus lent que vous, et beaucoup plus procédurier, vous devrez
vous adapter.
○ Si vous êtes le fournisseur, préparez-vous à devoir faire évoluer votre
roadmap, mais évitez de faire du sur-mesure : les changements que vous
apportez doivent aller dans le sens de votre vision et être
industrialisables. Ils peuvent être la source d’opportunités si vous
identifiez des besoins communs à d’autres organisations.
○ Si vous êtes le client, demandez à connaître la roadmap de votre
partenaire et apprêtez-vous à utiliser une solution sur étagère, sans
possibilité d’influencer cette roadmap.
● Si vous êtes de taille sensiblement égale, investissez du temps dans l’alignement
des stratégies et des roadmaps entre les deux partenaires. Identifiez les
bénéfices pour chaque partie, et impliquez le management exécutif dans ce
partenariat en organisant des rendez-vous réguliers d’alignement. Identifiez vos
leviers d’action dans ce partenariat, et faites-en bon usage. Évitez de faire preuve
d’un orgueil démesuré.
Quand faire appel à des consultants et des agences ?

Vous ne pourrez pas tout le temps vous reposer sur des forces internes pour toutes les
phases de votre développement produit. Parfois, vous ne voudrez pas le faire.
Avant de voir pourquoi et comment faire appel à des ressources externes, quand
devez-vous utiliser des ressources internes ? Ou plutôt, quand devez-vous recruter de
nouveaux collaborateurs, pour renforcer vos équipes ou acquérir une expertise que
vous n’avez pas jusqu’à présent ? La réponse est simple : quand cette ressource est
affectée à un produit stratégique pour l’organisation, et que l’organisation est certaine
que cette ressource apportera de la valeur à long terme.
167
CHU, Brandon. Product Partnerships (pt. 1/2)— The Making of a Partnership. Black Box of
Product Management : 30 décembre 2015.
https://blackboxofpm.com/product-partnerships-a2d23dff2410
236
/
Dans les autres cas, vous pouvez envisager de faire appel à une ressource externe,
voire externaliser entièrement le développement d’un produit.
Faites appel à des agences de conseil expertes en product management pour vous
aider à mettre en place l’organisation produit : définir votre stratégie, coacher vos
leaders, accompagner et former les équipes, formaliser vos premières roadmaps,
accompagner le changement dans l’organisation, mettre en place des processus et des
méthodologies, incuber vos premiers produits.
Les bons leaders produits, CPO ou Head of Product, sont encore rares sur le marché.
Cette discipline est encore très jeune en France et en Europe, et la demande de plus en
plus croissante. Vous aurez de la concurrence. De plus, il y a des chances pour que vos
équipes de recrutement ne comprennent pas quel profil recruter à ce poste. En
attendant de trouver le bon leader, vous pouvez faire appel à un management produit
par intérim, en freelance ou via une agence de conseil. Attention à ne pas tomber dans
le piège du consultant black ops, présent pour quelques mois seulement qui met en
place des changements de surface sans se préoccuper des conséquences à long terme.
Créez un partenariat, et laissez entrevoir les bénéfices à long terme, tels que des
partenariats ou des recommandations.
Vous aurez également du mal à recruter rapidement des product managers, des
product designers et des développeurs ayant l’expérience de la gestion produit. Vous
souhaiterez d’ailleurs attendre et vérifier que cette démarche fonctionne pour vous
avant de recruter. Utilisez là encore des professionnels du produit pour renforcer
vos équipes. Je parle là de consultants en régie, intégrés à part entière à vos équipes,
qui utilisent les mêmes outils, les mêmes canaux que vos internes, les mêmes
formations que vos ressources internes. Ces consultants externes aideront à diffuser la
culture et les bonnes pratiques du product management. Attention à ne pas créer des
équipes de mercenaires. Équilibrez vos équipes entre ressources internes,
éventuellement inexpérimentées mais motivées sur la base de la réalisation des
outcomes, et ressources externes déjà formées et acculturées. Autant que possible,
essayez de monter des partenariats à long terme, pour éviter de faire appel à des
mercenaires intéressés uniquement par une rémunération à court terme.
Enfin, dans certains cas vous voudrez externaliser un service à part entière :
externaliser votre design d’interface par exemple, ou même le développement du
produit. Le principal écueil ici est bien évidemment de choisir le bon partenaire. En
externalisant un service, vous pourrez difficilement être orienté résultat. Les agences
fournissent des livrables, des outputs, et c’est à vous de vous assurer que ces livrables
délivrent la valeur attendue.
Avant d’externaliser un service à une agence (la réalisation d’un produit ou d’une
fonctionnalité, la création du design system pour un nouveau produit ou dans le cadre
d’une refonte graphique…), assurez-vous que le problème que vous devez résoudre est
porteur de valeurs : effectuez une phase de discovery avant d’externaliser.
Ensuite, rencontrez des partenaires potentiels, et vérifiez s’ils sont en adéquation avec
vous : est-ce qu’ils cherchent à comprendre votre vision et vos problèmes ?
237
/
Cherchent-ils à savoir quels sont les validated learnings que vous avez déjà acquis ?
D’une manière générale, si l’agence candidate vous propose des solutions avant de
poser ce type de question, vous ne parlez probablement pas avec les bonnes
personnes.
Choisissez votre agence sur la base de la valeur qu’elle peut délivrer, pas sur la base du
prix qu’elle estime pour votre produit. Le moins disant sera généralement celui qui
apportera le moins de valeur, sauf à ce qu’elle ait en tête une solution vraiment
originale et innovante auxquels leurs concurrents n'ont pas pensé.
Mettez-vous d’accord sur le mode de rémunération. Le temps passé n’est généralement

pas un indicateur suffisant : votre agence risque d’être tentée d’étirer le projet en
longueur, et de passer du temps sur des tâches inutiles. Regardez quelles sont vos
contraintes, et essayez de trouver des indicateurs pertinents qui peuvent entrer dans le
calcul, en ajoutant par exemple des “bonus” liés à l’atteinte de certains outcomes.
Un projet agile, ce n’est pas un projet global au forfait !168
168
Le tout petit problème de l’agilité. CommitStrip : 9 janvier 2017.
https://www.commitstrip.com/fr/2017/01/09/that-little-problem-with-agile/
238
/
Ne signez pas un contrat au forfait pour la réalisation d’un long projet. Vous vous
assurez de retomber dans le Build Trap en vous concentrant sur la livraison d’un output.
Découpez le projet en itérations limitées dans le temps. Commencez par une phase
d’onboarding et renforcez le discovery, en créant un MVP. Un vrai MVP, pas une version
qui contient à peu près toutes les fonctionnalités que votre business souhaite avoir.
Évaluez les résultats de cette première phase, puis décidez ou non de continuer. Et si
vous continuez, décidez de comment vous le faites, avec votre partenaire. Enchaînez les
phases courtes et évaluez le résultat des livrables à chaque itération. De cette
façon, vous pourrez estimer les outcomes de votre projet, et changer d’orientation si
vous en ressentez le besoin. Et il y a de bonnes chances pour que vous ayez besoin de
changer d’orientation. Une dernière chose, évitez d’externaliser uniquement le
développement. Vous voulez que votre partenaire comprenne ce qu’il fait et pourquoi il
le fait. Vous voulez qu’il travaille en équipe avec vous. Il doit être capable de faire des
tests avec vos clients, de négocier les fonctionnalités et le design, de la même manière
que vous le feriez en interne. Encore une fois, votre objectif est de créer de la valeur
pour le business et votre client, des outcomes.
239
/
Conclusion
En guise de
conclusion …
Le product management est une discipline récente et en pleine expansion en France.

Nul doute que de plus en plus d’entreprises vont prendre en compte cette démarche
centrée sur l’utilisateur et créer des départements produit.
Vont-elles le faire correctement ? C’est un challenge beaucoup plus compliqué. Pour

être un succès, le product management nécessite de mettre en place des changements
drastiques dans les entreprises, au niveau culturel, organisationnel, technique,
procédural et humain. Sans ces changements, l’organisation risque de rester coincée
dans le “build trap”, la création de produits et de fonctionnalités inutiles, parce qu’il faut
bien délivrer quelque chose. La mise en place d'une démarche produit réussie va
souvent de pair avec une transformation digitale nécessaire du business model de
l’organisation.
Quel avenir pour le product management ? Certains parlent de product management

sans product managers, où le produit serait tellement ancré dans la culture de
l’organisation que le product designer, le marketing et la tech pourraient œuvrer
ensemble dans une démarche produit sans besoin d’une personne dédiée pour tout
coordonner et porter la vision business et client169.
Autre sujet à approfondir : comment appliquer des techniques de product management

aux outils internes de l’organisation170, pour lesquels par définition le client est un de
vos collègues. Comment ne pas retomber dans le piège client-fournisseur des directions
AMOA classiques ?
169
JAWHAR, Ayman. Product Management Is Dead. Insead Knowledge : 8 septembre 2020.
https://knowledge.insead.edu/blog/insead-blog/product-management-is-dead-15156
170
Voir par exemple :
MCDONALD, Kent. Internal Product Management. kbp media : 19 juillet 2017.
https://www.kbp.media/internal-product-management/
SIDDIQUI, Jawwad. Ultimate Guide for Internal Product Management (with examples). Forever
Learning : 17 férier 2017. https://jawwad.me/guide-internal-product-management/
Internal Product Management: the Good, the Bad and the Ugly. Black Swan Farming.
https://blackswanfarming.com/internal-product-management-the-good-the-bad-and-the-ugly/
240
/
Annexes - Bibliographie et interviews
Annexes
Bibliographie et
interviews
241
/
1 - Livres
ANON, Josh & GONZALEZ DE VILLAUMBROSIA, Carlos. The Product Book : How
to become a great product manager. USA : Product School, 2017. 306 p.
https://productschool.com/the-product-book/
BANFIELD, Richard, ERIKSSON, Martin & WALKINGSHAW, Nate. Product

Leadership: How Top Product Managers Launch Awesome Products and Build
Successful Teams. Sebastopol, CA, USA : O’Reilly, 2017. 256 p.
CAGAN, Marty. Inspired : How to create tech products customers love. Hoboken,
NJ, USA : Wiley, 2018. 349 p.
COHN, Mike. User Stories Applied: For Agile Software Development, préface
de Kent Beck. Wesley, 2004. 304 p.
DOERR, John. Measure What Matters : How Google, Bono, and the Gates
Foundation Rock the World with OKRs, préface de Larry Page. Portfolio, 2018.
320 p.
KNAPP, James, ZERATSKY, John & KOWITZ, Braden. Sprint: How To Solve Big
Problems and Test New Ideas in Just Five Days. Bantam Press, 2016. 288 p.
FRENOVE, Anne-Sophie & FLAHAULT-FRANC, Emmanuelle. Into the French Tech

: 50 grands entrepreneurs coachent votre start-up ! Paris : First éditions , 2018.
317 p.
LEMAY, Matt. Product Management in practice : A Real-World Guide to the Key

Connective Role of the 21st Century. Sebastopol, CA, USA : O’Reilly, 2018. 173 p.
LOMBARDO, C. Todd, MCCARTHY, Bruce, RYAN, Evan & CONNORS, Michael.

Product Roadmaps Relaunched : How to Set Direction while Embracing
Uncertainty. Sebastopol, CA, USA : O’Reilly, 2017. 230 p.
242
/
MEDINA, Regis. Learning to Scale: The Secret to Growing a Fast and Resilient
Company, préface de Benoît Charles-Lavauzelle. Regis Medina, 2020. 314 p.
MESSAGER, Véronique. Gestion de projet agile : avec Scrum, Lean, eXtreme

Programming…, préface de Jean Tabaka. Eyrolles : 2013. 278 p.
MOORE, Geoffrey A. Crossing the chasm : Marketing and selling disruptive

products to mainstream customers. HarperCollins : 2014. 288 p.
PERRI, Melissa. Escaping the building trap : How Effective Product Management
Creates Real Value. Sebastopol, CA, USA : O’Reilly, 2019. 183 p.
PICHLER, Roman. Strategize : Product Strategy and Product Roadmap Practices

for the Digital Age. Pichler Consulting, 2016.
RIES, Eric. The Lean Startup: How Today's Entrepreneurs Use Continuous
Innovation to Create Radically Successful Businesses. Currency, 2017. 336 p.
SKELTON, Matthew & PAIS, Manuel. Team Topologies: Organizing Business and
Technology Teams for Fast Flow. IT Revolution Press, 2019. 240 p.
243
/
2 - Ressources générales sur le

product management
2.1 - Livres blancs
● THIGA. Agile product management : Le guide des product managers et product
owners d’élite. Paris : Thiga & Xebia. 92 p. (Product Academy, Vol. 1)
https://thiga.co/fr/product-academy-vol-1/
● THIGA. Les organisations orientées produit, rédigé par IRRMANN-TEZE, Alexandre,
FRIH, Maria & JOLIVEAU-BRENEY, Simon. Paris : Thiga. 154 p. (Product Academy,
Vol. 3)
https://thiga.co/fr/product-academy-vol-3/
● Pendo & Product Collective. The Rise of Product Ops. 27 p.
https://go.pendo.io/prodops-ebook
● CHEN, Andrew. 5 Key Questions on Building Growth Teams. Andreessen Horowitz,
2018. 56 p.
http://andrewchen.co/wp-content/uploads/2018/11/how-to-build-a-growth-team
.pdf
● HERBIG, Tim. Product Discovery : A Practical Guide for Agile Teams (2020). 57p.
https://herbig.co/product-discovery/
https://herbig.co/wp-content/uploads/2020/06/eBook-Tim-Herbig-Product-Disco
very-A-Practical-Guide-for-Agile-Teams-2020-v2.pdf
2.2 - Sites web

● Je suis PM, site de ressources français sur le PM
https://www.jesuispm.com/
● Mind the Product, fondé par Martin Eriksson
https://www.mindtheproduct.com/
● Blog de la Product School
https://productschool.com/blog/
● Blog de l’entreprise Product Board
https://www.productboard.com/blog/
● Product Craft, communauté product par Pendo
https://productcraft.com/
● Blog du cabinet Product Collective
https://productcollective.com/blog/
● Inside Intercom, Product & Design (anglais)
https://www.intercom.com/blog/product-and-design/
● Le blog de Thiga, agence française de conseil produit
https://blog.thiga.co/
244
/
● Blog de cabinet de conseil Hubvisory Product

https://hubvisory.com/blog/
● Blog de l’agence de conseil produit Wivoo
https://www.wivoo.fr/blog/
● Blog de Roman Pichler, leader d’opinion en product management et auteur de
Strategize
https://www.romanpichler.com/blog/
● Blog du Silicon Valley Product Group, fondé par Marty Cagan
https://svpg.com/articles/
● Le blog de WeFiit
https://wefiit.com/nos-actualites/
● Product Marketing Alliance, site de référence pour les PMM
https://productmarketingalliance.com/
● Blog de GV (ex. Google Ventures) sur le product management
https://library.gv.com/tagged/product-management
2.3 - Blogs tech et produit de startups françaises (ou pas)

● Blog tech de ManoMano, une des startups les plus actives en France en Product
Management
https://medium.com/manomano-tech
● Blog tech de la startup MeilleursAgents
https://medium.com/meilleursagents-engineering
● Blog tech de la startup Qonto
https://medium.com/qonto-engineering
● Blog de la startup Alan
https://medium.com/alan
● Blog tech de Doctolib
https://medium.com/doctolib
● Blog tech de Stuart
https://medium.com/stuart-engineering
● Blog tech de TheFork
https://medium.com/thefork
● Blog de Dashlane
https://blog.dashlane.com/category/dashlane/culture/
● Blog tech de LeBonCoin
https://medium.com/leboncoin-engineering-blog
● Blog de Payfit
https://medium.com/payfit
● Blog de OpenClassrooms
https://medium.com/openclassrooms-product-design-and-engineering
● Blog Inside Heetch
https://medium.com/inside-heetch
● Blog de Dailymotion
https://medium.com/dailymotion
245
/
● Blog Inside Aircall

https://medium.com/inside-aircall
● Blog de YounitedTech
https://medium.com/younited-tech-blog
● Blog de AB Tasty
https://medium.com/the-ab-tasty-tech-blog
● Blog d’Algolia
https://blog.algolia.com/
● Blog tech d’Amplitude
https://amplitude.engineering/
● Blog tech de Veepee
https://medium.com/vptech
● Blog de Deezer
https://deezer.io/
● Blog de Blablacar
https://medium.com/blablacar
● Blog d’Everoad
https://medium.com/everoad
● Blog de Toucan Toco
https://toucantoco.com/en/tech-blog.html
2.4 - Podcasts
● Product Hunt radio (anglais)
https://www.producthunt.com/radio
● This is Product Management (anglais)
https://www.thisisproductmanagement.com/
● Inside Intercom (anglais)
https://www.intercom.com/blog/podcasts/
● The Product Podcast (anglais)
https://productschool.com/product-podcast/
● Product People (anglais)
https://www.productpeople.tv/
● People and Product podcast (français)
https://podcasts.apple.com/us/podcast/people-product-podcast/id1518305608
https://open.spotify.com/show/55sbl4qWOGSZkwVkhaYpzP?si=3O5e7z5xT4-eNu
ovS9RvXg
● Product Squad, le podcast (français)
https://www.productsquad.fr/
● The Product Tape (français)
https://podcast.ausha.co/the-product-tape
● Parlons Produit (français)
https://podcast.ausha.co/parlons-produit
● Dans la tête d’un PM (anglais)
https://podcast.ausha.co/dans-la-tete-d-un-product-manager
246
/
● Product Talk - Products that count (anglais)

https://podcasts.apple.com/us/podcast/product-talk/id1038890550
https://open.spotify.com/show/3yM6oR3QD2chAFdSXAgzzK
https://tunein.com/podcasts/Technology-Podcasts/Product-Talk-p1120766/
● Product to Product (anglais)
https://roadmunk.com/product-to-product-podcast
2.5 - Chaînes Youtube

● La Product Conf - LPC & LPCx (français et anglais)
https://www.youtube.com/c/LaProductConfLPCLPCx
● Product School San Francisco (anglais)
https://www.youtube.com/channel/UC6hlQ0x6kPbAGjYkoz53cvA
● Wivoo (français)
https://www.youtube.com/channel/UC234z9kfnXUnXqnzdQMjd1w
● ProductStories (anglais)
https://www.youtube.com/channel/UC70BXNPXz652xVB5S222lBg
● Productized (anglais)
https://www.youtube.com/channel/UCc707M4Ey0qECi56KPqgJjA
● ProductPlan (anglais)
https://www.youtube.com/channel/UCKsDEo4_LJQ7WuzX184CEzw
● Dan Olsen, auteur de “The Lean Product Playbook” (anglais)
https://www.youtube.com/channel/UChx1ibI5TI7bBva0Z21azrw
2.6 - Media sociaux et communautés

Listes Twitter
● Tech Product Managers all over the world
https://twitter.com/i/lists/106771072
● Product Managers I Love
● Product People (par Melissa Perri)
● 15 Product Leaders To Follow on Twitter in 2020 (par Product School)
● Product leaders worldwide
● Product management in France
Groupes LinkedIn
● Product Management (129k membres, anglais)
https://www.linkedin.com/groups/42629/
247
/
● Product Design (63k membres, anglais)

● Digital Product Managers (13k membres, anglais)
● Product Manager Jobs (29k membres, anglais)
● Product Managers Community (30k membres, anglais)
Groupes Slack
● Mind the Product (anglais, 10k membres)
http://slack.mindtheproduct.com/
● Product School (anglais, 30k membres)
https://productschool.com/slack-community/
● Product Manager HQ (anglais, 8000 membres, payant $25)
https://productmanagerhq.com/join-the-community/
● Product Coalition (anglais, 5000 membres)
http://slack.productcoalition.com/
● We love product ! (français)
http://weloveproduct.com/
2.7 - Événements et webinars

Evénements
● La Product Conf (Paris et Madrid)
https://laproductconf.com/
● UXDX (online)
https://uxdx.com/
● Women in Product (online)
https://www.womenpm.org/
● The remote product manager (online)
https://remote-pm.makingjam.io/
● Product Craft by Pendo (online)
https://productcraft.com/conference/
● ProductCon (online, USA, Londres)
https://productschool.com/productcon/
● Product (Londres)
https://www.worldforumdisrupt.com/product-london-20/
● Product Management Festival (Zurich, online)
https://productmanagementfestival.com/zurich/
● Product-Led World (London, Amsterdam, USA)
https://productledworld.com/
● Product Camp (online)
https://productcamp.pl/
248
/
● Mind the Product conferences (online, Londres, Hambourg, Singapour, San

Francisco)
https://www.mindtheproduct.com/conferences/
● Industry (online)
https://www.industryconference.com/
● Leading the Product (online)
https://www.leadingtheproduct.com/
● School of PO by benext (Paris)
https://www.schoolofpo.com/
● Jam (online, London)
https://www.makingjam.io/
● Product Marketing Festival (online)
https://festival.productmarketingalliance.com/
Webinars
● Les PMM Talks de la Product Marketing Alliance
https://productmarketingalliance.com/pmm-talks/
Meetups
● LPCX - Meetup La Product Conf (Paris, Lille, Nantes, Lyon, Bordeaux, Toulouse,
Aix/Marseille, Barcelone, Madrid)
https://www.meetup.com/fr-FR/pro/lpc/
● Product Therapy, par Wivoo (Paris)
https://www.meetup.com/fr-FR/meetup-group-qZSpyXTZ/
● ProductTank Paris, par Mind the Product
https://www.meetup.com/fr-FR/ProductTank-Paris/
● School of PO, par benext (Paris)
https://www.meetup.com/fr-FR/School_of_PO/
● Product Stories (Paris)
https://www.meetup.com/fr-FR/_ProductStories/
● Product Management Workshops (Paris)
https://www.meetup.com/fr-FR/Product-Management-Workshops/
● Product Apéro (Paris)
https://www.meetup.com/fr-FR/product-apero/
● The Product Group France (Paris)
https://www.meetup.com/fr-FR/TheProductGroupFrance/
● People & Product, par Hubvisory
https://www.meetup.com/fr-FR/people-and-product/
● Product School Paris
https://www.meetup.com/fr-FR/Product-School-Paris/
● Product Crunch Paris
https://www.meetup.com/fr-FR/Product-Crunch-Paris/
● Women in Product Paris
https://www.meetup.com/fr-FR/womeninproductparis/
249
/
3 - Ressources web sur le product

design et le discovery
3.1 - Livres blancs
● THIGA. Le product design dans une organisation produit. Paris : Thiga. 76p.
(Product Academy, Vol. 4)
https://thiga.co/fr/product-academy-vol-4-product-design-organisation-produit/
● DesignBetter.co. DesignOps Handbook, rédigé par BATTLES, Kate, BLACK,
Meredith, MALOUF, Dave, WHITEHEAD, Collin, and BERNSTEIN, Gregg. Invision.
119 p.
https://www.designbetter.co/designops-handbook
● New York Times Product Discovery Activity Guide, rédigé par LAMIELL, Jim,
MING, Al, OLLAPALLY, Priya, TURK, Josh & YOM, Christine. 74 p.
https://fr.slideshare.net/almingwork/nyt-product-discovery-activity-guide
3.2 - Sites web

● Sprint, site officiel de Jake Knapp et John Zeratsky sur le Design Sprint
https://www.thesprintbook.com/
● Design Sprint Kit with Google : méthodologies et ressources sur le Design Sprint
https://designsprintkit.withgoogle.com/
● Sites de l’agence IDEO, leader en Design Thinking
https://www.ideo.com/
● Ressources de la d.school, école de design de Stanford spécialisée en Design
Thinking
https://dschool.stanford.edu/resources
● Site de la d.school française
https://www.dschool.fr/
● Blog de Klap, agence de conseil française spécialisée dans le design thinking
http://www.klap.io/blog/
● Blog de Usabilis, agence de conseil en UX et ergonomie digitale
https://www.usabilis.com/blog/
● Site de Design Sprint Services, agence européenne spécialisée dans le Design
Sprint
https://design-sprint.com/
● Blog de GV (ex. Google Ventures) sur le Design
https://library.gv.com/tagged/design
● Blog de Jeff Gothelf, auteur de Lean UX
https://jeffgothelf.com/blog/
● Site de NN/g, cabinet de conseil en UX et user research
https://www.nngroup.com/
250
/
● Site du consultant Tim Herbig, notamment sur le Product Discovery

https://herbig.co/
● Product Discovery Methods, reprenant notamment les techniques décrites dans
le Product Discovery Activity Guide du New York Times.
https://pdmethods.com/
● UX Planet, site de référence sur l’expérience utilisateur
https://uxplanet.org/
● UX movement, blog sur les interfaces utilisateurs
https://uxmovement.com/
● UX Daily, site de ressources en UX design mis à disposition par l’Interaction
Design Foundation
https://www.interaction-design.org/literature/article/overview
● UX Booth, site collaboratif d’information sur l’UX Design
https://www.uxbooth.com/
● Blog de UX Republic, cabinet de conseil en UX
https://www.ux-republic.com/blog/
3.3 - Podcasts et vidéos

● The Jake & Jonathan podcast - par Jake Knapp (créateur du Design Sprint) et
Jonathan Courtney
https://jakeknapp.com/podcast
● User Defenders, un podcast sur l’UX
https://userdefenders.com/
● Design Details, podcast sur le product design
https://designdetails.fm/
● Chaîne Youtube de DesignCourse
https://www.youtube.com/user/DesignCourse
● Chaine Youtube AJ&Smart, ressources sur l’UX, le Design Thinking et le Design
Sprint
https://www.youtube.com/channel/UCeB_OpLspKJGiKv1CYkWFFw
● Chaîne Youtube de NN/g
https://www.youtube.com/user/NNgroup
● Chaîne Youtube de InVision
https://www.youtube.com/channel/UCndfHdRdEiGOyCOgxQ4W9YQ
3.4 - Médias sociaux

● Groupe LinkedIn UX Strategy: Data-Informed Product and Service Design (47k
membres, anglais)
● Groupe LinkedIn Méthodes Agiles et User Experience / Agile-UX (1.2k membres,
français)
251
/
3.5 - Événements
● NEXT Conf, conférence de l’innovation par le design thinking
https://next-conf.com/
● UX days
https://uxdays.eu/
● UX Conf, organisée par UX Republic
https://www.ux-republic.com/events/
252
/
4 - Ressources web sur

l’entrepreneuriat et les startups
4.1 - Sites web
● Techcrunch, le site de référence mondial sur la tech et les startups
https://techcrunch.com/
● Product Hunt, des nouveaux produits innovants chaque jour
https://www.producthunt.com/
● Venture Beat, autre site américain de référence sur la tech et les startups
https://venturebeat.com/
● Site de France Digitale
https://francedigitale.org/
● Frenchweb, site média sur la transformation numérique et les startups
https://www.frenchweb.fr/
● Maddyness, site média de référence en France sur les startups
https://www.maddyness.com/
● Les pépites tech
https://lespepitestech.com/
● Site d’actualité sur et pour les startups
https://www.rudebaguette.com/
● Site officiel sur le Lean Startup
http://theleanstartup.com/
● Blog d’Eric Ries, auteur de Lean Startup
http://www.startuplessonslearned.com/
● What Matters, site de John Doerr et son équipe sur les OKR
https://www.whatmatters.com/
● Startup.info site d’actualité sur les startups
https://startup.info/fr/
● J’aime les startups, média d’information sur les startups
https://www.jaimelesstartups.fr/
● Widoobiz, site d’actualité sur l’entrepreneuriat
https://www.widoobiz.com/
● Strategyzer, cabinet de conseil ayant créé le Business Model Canvas
https://www.strategyzer.com/
● Blog du Shift, agence de conseil en innovation et entrepreneuriat
https://le-shift.co/blog/
● bpifrance création, site de la BPI pour les entrepreneurs
https://bpifrance-creation.fr/
253
/
4.2 - Podcasts et vidéos

● Podcast “La French Touch” (français)
http://www.lafrenchtouch.fm/
● Podcast “A la rencontre des acteurs de la tech” (français)
https://www.podcastics.com/podcast/a-la-rencontre-des-acteurs-de-la-tech/
● Chaîne Youtube What Matters sur les OKR
https://www.youtube.com/channel/UCGg6XgmR-pHwIfD1vDJgTCQ
254
/
5 - Ressources sur l’agilité et

delivery
5.1 - Sur l’agilité en général
● Manifesto for Agile Software Development, le site officiel du manifeste agile
https://agilemanifesto.org/
● Agile Alliance, une organisation promouvant les pratiques agiles
https://www.agilealliance.org/
● My Agile Partner, un site de ressources sur les pratiques agiles
https://blog.myagilepartner.fr/
● Coach Agile, un blog sur l’innovation agile
https://coach-agile.com/
● Le blog d’Atlassian, société éditrice de Jira, Confluence et Trello notamment
https://www.atlassian.com/blog
● Blog d’Octo, cabinet de conseil en ’agilité et l’innovation technologique
https://blog.octo.com/
● Qualitystreet, un autre site de référence sur l’agilité
https://www.qualitystreet.fr/
● Mike Cohn’s Blog, le blog d’un des signataires du manifeste agile et auteur de
User Stories Applied
https://www.mountaingoatsoftware.com/blog
● State of Agile, enquête annuelle sur l’agilité et le DevOps
https://explore.digital.ai/state-of-agile
● Heart of Agile, une nouvelle approche de l’agilité par Alistair Cockburn
https://heartofagile.com/
● Wiki sur l’agilité de CESI, une école d’ingénieur
https://wikiagile.cesi.fr/
5.2 - Sur Scrum

● Scrum Alliance, l’autre organisme de certification Scrum
https://www.scrumalliance.org/
● Scrum Guides, site officiel de Scrum
https://www.scrumguides.org/
● Scrum.org, entreprise créé par Ken Schwaber, un des deux créateurs de Scrum,
qui délivre une des deux certifications reconnues pour ce framework
https://www.scrum.org/
● Lucy in the Scrum, blog d’une consultante agile et produit
http://lucyinthescrum.com/
255
/
● Scrum, agilité et Rock’n Roll, blog de Claude Aubry, consultant agile

https://www.aubryconseil.com/
5.3 - Sur Kanban

● Everyday Kanban, site de ressources sur la méthode Kanban
http://www.everydaykanban.com/
● Kanban Tool, site de ressources sur Kanban
https://kanbantool.com/kanban-guide/
● Kanbanize, un autre site de ressources sur Kanban
https://kanbanize.com/kanban-resources
5.4 - Sur DevOps

● site des évènements devopsdays
https://devopsdays.org/
● Blog sur le DevOps
https://www.padok.fr/blog
● Un autre blog sur le DevOps
https://blog.wescale.fr/
● Site de Google sur le rôle du SRE
● Site de référence sur le Continuous Delivery
https://continuousdelivery.com/
● Blog sur le cloud, le continuous delivery et le devops
https://www.claranet.fr/blog
256
/
6 - Interviews
Les vidéos des interviews sont à usage exclusif du comité pédagogique du MBAMCI.
Elles ne seront pas disponibles dans la version rendue publique de cette thèse.
Nom Rôle Sujet de l’interview
Clarisse Responsable Où en est la démarche de

Moussie transformation DSI AXA transformation de la DSI d’AXA
France France ?
Alexandre Consultant et Échange informel et contacts

Jubien conférencier en stratégie potentiels pour alimenter ma thèse.
mobile
Enseignant au MBAMCI
ex-Head of Mobile Deezer
et Viadeo
Alexandre Consultant en product Pourquoi et comment ? La démarche

Takacs management produit à L’Express et chez Viadeo
ex-Head of Product
l’Express et Viadeo
Kathleen Product manager Comment l’intrapreunariat permet de

Marie-Joseph intrapreneuse chez Pôle diffuser une culture startup et
emploi product chez Pôle emploi ?
Aurélie Co-fondatrice et product Comment BNP FI met en place une

Vallée owner de Neymo, filiale démarche produit à travers un
de BNP Paribas PF, programme d’intrapreunariat ?
ancienne intrapreneuse
Matthieu Co-fondateur et Head of Comment mettre en place une

Pecheul Sales de WeFiit, société de démarche Product dans une
conseil en product entreprise ?
management et QA
257
/
Alexia Boulot Head of Product chez Quel est le rôle d’un Head of Product
Veepee, iGraal, Voyages chez Veepee, quelle organisation et
SNCF responsabilité des équipes produit ?
Gabriel Head of Product et PM Comment la démarche produit

Soares chez Aptus Health, Betclic, a-t-elle été utilisée pour développer
HTC, Mappy et Orange un site d’information médicale ?
Silvère Duval Product Owner AXA Quel est le rôle d’un product owner
France et d’un product manager dans la DSI
d’AXA France ?
Alix Boulnois Chief Product & Comment Accor a mis en place une
Lombard Innovation Officer chez démarche produit dans le cadre de la
Accor transformation de son business
model ?
Marie Petit Chief Product Officer à La Comment le Crédit Agricole met en

Fabrique by CA place une démarche produit, chez
CATS et à La Fabrique by CA ?
Chloé Lecerf Product Marketing En quoi consiste le métier de PMM et

Manager chez Spendesk quelles interactions avec les équipes
Product ?
Marion Fondatrice de Peps.pm En quoi consiste le poste de Head of

Darnet ex-Head of Product Product ? Quels challenges pour un
Synthesio et ITinSell profil product dans une organisation
ex-PM Privateaser et non acculturée ?
Wonderbox
258

Maxime Nahon Les Organisations Innovantes Orientees Produit

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Maxime Nahon Les Organisations Innovantes Orientees Produit

Transféré par

Droits d'auteur :

Formats disponibles

Maxime Nahon

Code NSF 312 - 326, certification professionnelle de niveau I

Promotion 2019- 2020

Les organisations innovantes

Date de remise : 09 octobre 2020

INSTITUT LÉONARD DE VINCI

Le présent document est la thèse (légèrement remaniée) que j’ai

N’hésitez pas à me contacter sur les réseaux sociaux ou par e-mail :

Cette thèse est distribuée sous licence CC BY-NC 4.0

Partie I - Qu’est-ce que le product management ? 17

1 - Pourquoi le Product Management ? 18

1.1 - Ce qui ne fonctionne pas dans le modèle traditionnel 18

1.2 - Le product management moderne : un modèle centré sur la production de

2 - Une histoire du product management 25

2.1 - Naissance de la stratégie de marque… et du product management 25

2.2 - Divisions produit chez HP, optimisation de la production chez Toyota 25

2.3 - Le chef de produit marketing dans les années 60 25

2.4 - L’approche produit centrée utilisateur dans la tech 26

2.5 - Le produit au coeur des méthodes agiles 26

2.6 - L’avènement des directions produit 27

3.1 - Quelle taille idéale pour une équipe produit ? 29

3.2 - Les caractéristiques d’une équipe produit qui réussit 29

Partie II - Les rôles au sein d’une organisation produit 34

1 - Le Product manager, leader du produit 35

1.1 - Les compétences du PM au travers du framework CORE 36

1.2 - Lead product manager 39

1.3 - Associate product manager 39

1.4 - Product Manager et Product Owner 40

1.5 - PM et chef de projet 43

2 - Le product design, leader de l’expérience utilisateurs 45

2.1 - Product designer 47

2.2 - Les autres rôles du design 48

2.3 - Une organisation sans design ? 50

3 - L’équipe de réalisation, de l’idée à la réalité 52

3.1 - Les développeurs 53

3.2 - Tech Lead 54

3.3 - Quality Assurance (QA) 54

4 - Les experts et fonctions transverses 56

4.1 - Product researcher 56

4.3 - Product Data Analyst 58

4.4 - Product Growth 59

5.1 - Head of product 60

5.2 - Chief Product Oﬃcer 61

5.3 - Head of Design, leader de l’équipe design 62

5.4 - Le leadership technique 63

6 - Le marketing dans une organisation produit 65

6.1 - Product marketing manager 65

6.2 - L’intégration du marketing aux squads 74

Partie III - La stratégie produit 76

1.1 - Construire sa vision produit 79

1.2 - L’énoncé de mission 83

2 - Les objectifs stratégiques 85

2.1 - Les OKR - Objectives and Key Results 86

3.1 - Pourquoi les roadmaps traditionnelles ne fonctionnent pas ? 90

3.2 - Une roadmap orientée outcomes 91

3.3 - Trouver les idées, déﬁnir les initiatives 96

3.4 - Prioriser les initiatives 104

3.5 - Prendre compte les imprévus 110

4 - Le cycle de vie du produit 112

4.1 - La recherche du bon problème à résoudre : le problem/solution ﬁt 112

4.2 - La recherche du Product/Market ﬁt 114

4.3 - La phase de croissance : le growth 118

4.4 - La maturité du produit 121

Partie IV - Product Discovery : identiﬁer quel produit développer 122