LES CLÉS

DU PRODUCT
MANAGEMENT
Méthodes et stratégies Chloé Dumolard
pour réussir vos Floriane Sirven
produits numériques
LES CLÉS
DU PRODUCT
MANAGEMENT
MÉTHODES ET STRATÉGIES
POUR RÉUSSIR VOS
PRODUITS NUMÉRIQUES

1
 Présentation des autrices
Chloé Dumolard
Chloé Dumolard est Lead Product Manager
et formatrice passionnée chez Thiga. Sa carrière
l’a conduite à occuper des postes clés au sein de
grandes entreprises telles que Decathlon, SNCF
Voyageurs ou la digital factory du groupe Seb où elle
a piloté toutes les étapes d’une création de produit,
du test de concept à la recherche du Product
Market Fit. Dans les startups Evaneos, Leetchi et
Alma, elle a un impact décisif sur la vision Produit
et la structuration des équipes. Définition des OKRs, recherche utilisateur,
priorisation de la roadmap, cette passionnée de danse connaît par cœur les
pirouettes du Produit.
Floriane Sirven
Consultante chez Thiga depuis cinq ans, Floriane
Sirven a été Head of Product chez Chanel où elle
a joué un rôle déterminant dans la mise en place
de la gouvernance Produit et piloté la définition
de la roadmap avec un fort enjeu de conduite du
changement. Auparavant, elle a travaillé pour la
SNCF et Se Loger où elle a géré tout le cycle de vie
du produit, de la vision au delivery dans un contexte
agile avec des itérations continues. Ayant à cœur de
transmettre ses expériences de terrain, Floriane est aujourd’hui formatrice
senior chez Thiga Academy et construit les parcours de formation Produit
chez L’Oréal.
2 3
À propos de et
Fondée en 2014 à Paris, Thiga est un cabinet de conseil international
unique qui vise à combler l’écart entre l’aspiration et l’exécution. Il permet
aux entreprises de devenir des leaders technologiques grâce à la Pensée
Produit et au développement complet de produits numériques de bout en
bout.
En 2011, Marc Andreessen a inventé l’expression “Le logiciel mange le
monde”. Plus d’une décennie plus tard, plus d’entreprises que jamais, quel
que soit leur secteur d’activité traditionnel, se considèrent comme des
entreprises de logiciels ou de données.
Cependant, devenir une véritable entreprise technologique de premier
plan est un défi. Cela nécessite une culture, une organisation et un
ensemble de compétences spécifiques. Le succès en tant qu’entreprise
numérique implique souvent un ADN commun qui va au-delà des équipes
de développeurs et implique tout le monde, de la direction au marketing,
aux ventes et au service client. C’est ça, le Product Management.
Au cours de la dernière décennie, Thiga est devenue un leader en Product
Management et en Product Design . Nous disposons d’une équipe de 250
consultants et formateurs répartis en France et en Espagne. Avec Thiga
Academy, nous formons plus de 2000 personnes par an.
Thiga est née dans l’écosystème technologique, en aidant les start-ups
à développer leurs produits. Nous sommes des doers et aujourd’hui, nous
accompagnons les entreprises qui veulent transformer leur organisation
pour adopter la culture Produit.
En tant que pionniers sur ce marché, nous avons joué un rôle important
au coeur de la communauté Produit. Nous organisons une conférence
annuelle appelée “La Product Conf ”, qui rassemble 1 500 participants.
Nous avons notre propre média et avons publié 6 livres. Celui-ci est notre
nouveau-né et nous sommes très heureux car vous venez à peine de l’ouvrir.
Si vous avez besoin d’être accompagnés par notre cabinet de conseil,
retrouvez-nous sur thiga.co
Si vous avez besoin de former vos équipes, nous accompagnons leurs
carrières en Product Management et en Product Design jusqu’aux postes de
Product Leaders. Regardez sur academy.thiga.co
 Préface de Christopher Parola,
PRÉFACE Chief Product Officer de Yousign

En préfaçant ce livre, je pense aux nombreuses rencontres et expé-

riences qui ont nourri ma vision du Product Management durant les quinze
dernières années. Quand j’ai commencé, rares étaient les personnes qui
connaissaient le terme même de Product Management, la mode était encore
aux Product Owners et à la vague de “l’Agilité”.

Avoir un livre comme celui-ci entre les mains m’aurait facilité les choses.
Cet ouvrage est un condensé de l’essence même du Product Management,
imprégné des réalités, méthodes, et rituels que j’ai pratiqués au quoti-
dien, partagé avec mes équipes et que j’ai pu aborder dans mes articles et
conférences.

Le cadre nécessaire à l’autonomie

Chloé et Floriane ont su décrire dans ce livre de nombreux concepts et

pratiques qui permettent de créer le cadre propice à l’autonomie.

Vous trouverez dans ces pages non pas une formule magique ou un
framework supplémentaire, mais plutôt un mélange d’observations et de
conseils concrets sur la manière de construire et de maintenir un produit
numérique solide. Vous y découvrirez l’importance de l’alignement des
équipes et de la clarté de la vision, qui m’ont tenu à coeur chez Meilleurs
Agents, au sein du groupe Aviv et aujourd’hui chez Yousign.

En tant que Chief Product Officer, je suis convaincu que mon rôle est de
donner à mes équipes le cadre dans lequel elles seront autonomes. Vision
Produit, principes d’équipe, pratiques de discovery et de delivery, tout y est
expliqué, argumenté, et accompagné d’exemples.

Cette autonomie est la clé de votre réussite. Elle libère l’innovation et

permet la construction des produits aux plus forts impacts.

“C’est quoi ta vision Produit ?”

Comme Chloé et Floriane, qui consacrent toute la première partie du

livre à la vision Produit, j’ai sans cesse entendu cette question. Il n’est pas
une conférence, un meetup ou une rencontre entre professionnels du pro-
duit où la question n’est pas abordée.

Quand je parle de vision Produit, il s’agit d’une vision à l’échelle de l’en-

treprise, qui s’inscrit dans la mission et dans la stratégie. Cette vision est
5
 parfois appelée “vision d’entreprise”, mais je trouve alors qu’elle se mélange
trop souvent aux concepts de transformation du monde par l’entreprise. Or
ce n’est pas cela. Pour moi, la vision Produit est ce que notre produit doit
devenir pour livrer sa valeur et avoir son impact.
Le sujet de la vision Produit vous concerne, que vous soyez Product
Manager, Product Designer, Product Marketing Manager ou membre du
comité exécutif. La vision Produit vous sera utile, qu’elle soit définie à
l’échelle de l’entreprise ou à l’échelle d’un de vos nombreux produits. Et cet
ouvrage vous offre un chemin pour la construire.
J’ai eu à définir la vision Produit dans deux positions : celle de contri-
buteur individuel la première fois, et de CPO la seconde. Étonnamment,
les étapes diffèrent assez peu, et vont vous aider que vous soyez leader ou
manager. Ne négligez pas cette fondation essentielle !
Rituels et langage commun
De nombreux rituels sont présentés au fil de l’ouvrage, notamment sur
la base de l’exemple fictif de Thiga Eats.
Ce fil rouge permet de se figurer de manière très concrète les différentes
étapes et c’est une grande qualité de ce livre.
Les rituels présentés sont le ciment des équipes de Product Managers.
Ils structurent le quotidien et créent de la cohérence. Ils sont indispen-
sables pour aligner les visions et clarifier la communication. En un mot,
ils ancrent l’équipe. Ils adaptent les stratégies et anticipent les problèmes.
Ils sont la clé de notre résilience et de notre succès dans le monde du pro-
duit. Ils sont notre constante, notre pouls dans un univers en perpétuelle
évolution.
Pour celles et ceux qui ne sont pas fans de rituels, sachez qu’il faut les
comprendre pour les transcender. Vous n’avez pas à les appliquer comme
un manuel scolaire, mais les connaître en détail, avec des illustrations et
des cas concrets, vous permettra d’en retirer le meilleur dans votre contexte
et de laisser de côté ce qui peut ne pas fonctionner. Ne voyez pas dans ce
livre une forme de dogmatisme mais une boîte à outils dans laquelle il sera
facile de piocher.
L’impact comme boussole
Toutes les méthodes et les pratiques décrites dans le livre vous per-
mettent d’atteindre le seul objectif fondamental pour toute équipe Produit :
avoir de l’impact.
6 7
Chez Meilleurs Agents, nous avons théorisé et mis en oeuvre le concept
des Impact Teams avec mon complice de toujours, Nicolas Baron, désor-
mais Chief Technology Officer chez Yousign.
Nous étions en hypercroissance et notre objectif était d’augmenter l’im-
plication des équipes, de les aligner autour d’objectifs communs et de les
responsabiliser pour atteindre des objectifs. Plus nous les impliquions dans
la prise de décision, plus elles allaient être engagées.
Nous partions sur d’excellentes bases. Meilleurs Agents avait déjà
une culture agile en place, avec des rituels et une amélioration continue.
L’entreprise avait investi dans des tests automatisés pour assurer la qua-
lité du code. Nous avions une capacité à déployer fréquemment, ce qui est
essentiel pour accélérer l’apprentissage. Enfin, les équipes étaient coloca-
lisées, ce qui facilitait la communication et la collaboration. C’était avant
l’épidémie de Covid 19… Cette organisation a parfaitement tenu le choc du
télétravail.
Nous avons ainsi mis en place les «Impact Teams», des équipes pluridis-
ciplinaires responsables d’objectifs chiffrés. Chaque équipe était autonome
pour déterminer comment atteindre ses objectifs. Des réunions de partage
d’expérience entre Product Managers étaient organisées pour favoriser la
diffusion de la connaissance.
Ce nouveau paradigme impactait le comité de direction qui est passé
d’un rôle de décideur à celui de stratège en fixant les bons objectifs. Les
équipes étaient encouragées à proposer des idées, puis s’ensuivait un long
processus de scoring basé sur le potentiel de reach, l’impact attendu et la
confiance dans le projet pour décider de ceux qui étaient retenus.
Ces Impact Teams ne sont pas une fin en soit, et chez Yousign, notre
organisation est hybride. Là encore, un bel exemple d’outil à connaître et à
adapter à votre contexte.
Je terminerai en vous disant que le voyage du Product Manager est un
voyage d’évolution personnelle et professionnelle, et cet ouvrage est une
étape clé sur cette route passionnante. Il peut être une découverte comme
une redécouverte pour les plus expérimentés d’entre vous.
En vous souhaitant une lecture éclairante et impactante,
Christopher Parola
 VERSION IMPRESSION AMAZON KDP

SOMMAIRE Introduction 11

Module n°1 : Fixer le cap 19

Chapitre 1 : Maîtriser le contexte du produit 20
Chapitre 2 : Définir une mission et des objectifs pour l’équipe 28
Chapitre 3 : Identifier des opportunités Produit 36
Chapitre 4 : Créer la roadmap 44

Module n°2 : Comprendre le problème et

choisir la solution 55
Chapitre 5 : Comprendre la discovery 56
Chapitre 6 : Creuser les problèmes utilisateur 64
Chapitre 7 : Imaginer, concevoir et choisir des solutions 74
Chapitre 8 : Tester des pistes de solutions 84
Chapitre 9 : Garder le focus avec la priorisation 92

Module n°3 : Construire le produit 103

Chapitre 10 : Préparer les développements 104
Chapitre 11 : Gérer le delivery avec Agilité 116
Chapitre 12 : Planifier et donner de la visibilité 126
Chapitre 13 : Suivre l’avancement et gérer les imprévus 138
Chapitre 14 : Livrer les fonctionnalités 144
Chapitre 15 : Gérer le lancement des fonctionnalités 152

Module n°4 : Améliorer en continu 161

Chapitre 16 : Définir les mesures de succès 162
Chapitre 17 : Collecter et suivre les données 170
Chapitre 18 : Faire évoluer le produit 176
Chapitre 19 : Traiter les anomalies et la dette technique 184
Chapitre 20 : Travailler en équipe et collaborer avec les parties prenantes 190

Conclusion 201

Remerciements 203

Glossaire 205

9
INTRODUCTION

INTRODUCTION
Nos intentions
INTRODUCTION Le Product Management occupe une place essentielle dans les organi-
sations qui placent les produits et services numériques au cœur de leur
stratégie. Cette discipline permet de lancer des produits qui correspondent
réellement aux attentes des utilisateurs et d’améliorer les produits exis-
tants pour rester compétitifs. Le Product Management est stratégique, car
il n’est pas évident de créer des produits à succès !

Historiquement, la gestion de produit est apparue dans le secteur des

biens de grande consommation au sein des départements marketing. Mais
la nature même des produits technologiques rend cette gestion particu-
lière : les évolutions peuvent être très rapides, réalisées de manière incré-
mentale, et il est aisé de mesurer leur utilisation en temps réel. Il n’est
donc pas pertinent de séparer la conception de nouveaux produits et leur
production. Les développeurs et les Product Managers doivent travailler
main dans la main. Le Product Management est devenu une discipline reine
des entreprises technologiques, différenciée de la fonction marketing. Et
les équipes de Product Management sont pilotées par un·e Chief Product
Officer, intégré·e au comité de direction.

Au gré de nos missions chez nos clients, nous avons éprouvé les
méthodes Produit, testé différentes approches en fonction des contextes,
appris auprès des équipes et nos pairs. C’est pourquoi nous avons décidé
de rassembler les fondamentaux dans un livre concret et pratique, afin de
vous donner les clés du Product Management.

Nous ne sommes pas parties d’une page blanche puisque ce livre est
la version entièrement refondue du tout premier livre sur le Product
Management écrit en français. Depuis la première édition de 2015, le monde
du Produit a bien changé ! Le Product Management n’est plus réservé aux
startups. D’un côté, les scale-ups font face à des enjeux de rentabilité et
de consolidation. De l’autre, les grands groupes ont entamé leur transition
vers le numérique pour s’organiser et gérer les produits à l’échelle.

Dans ce contexte en ébullition, nous avons consolidé nos savoir-faire

chez Thiga. Ainsi est né le projet de réédition du petit livre vert qui vous a
sûrement guidé dans vos premiers pas de Product Manager.

L’ambition de ce livre est de proposer un guide de référence du Product

Management. Vous y découvrirez les meilleures pratiques pour maîtriser
la démarche Produit, de précieux conseils issus de nos expériences et des
exemples concrets pour illustrer les concepts clés. Vous trouverez aussi
toutes les ressources nécessaires pour rapidement mettre en pratique les
méthodes. Enfin, des références incontournables du monde du Produit vous
donneront envie d’aller plus loin et d’approfondir certains sujets.
10 11
INTRODUCTION

INTRODUCTION
Un livre pour tous ◉ Définir des objectifs ambitieux pour votre équipe ;
les Product Managers ◉ Construire une roadmap orientée objectifs ;

Nous sommes convaincues qu’il n’existe pas de façon unique de faire ◉ Prioriser les bonnes initiatives ;
du produit, et qu’il est important de savoir adapter ses pratiques. C’est
pourquoi il nous tenait à cœur d’écrire un guide exploitable, quel que ◉ Mener une discovery efficace ;
soit votre contexte. Nous avons fait notre maximum pour ne pas être
trop dogmatiques, partager ce qui nous semble être de bonnes pratiques ◉ Construire et maintenir votre backlog ;
réalistes et adaptables aux différentes réalités.
◉ Gérer le delivery avec agilité ;
Ce livre s’adresse aussi bien aux Product Managers qui travaillent sur un
produit à destination d’utilisateurs professionnels (B2B), que de particuliers ◉ Définir les bons indicateurs de succès ;
(B2C) ou d’employés (B2E), aux PMs responsables d’un produit payant ou
gratuit, d’un produit en SaaS (Software as a Service), d’un site Web ou d’une ◉ Améliorer votre produit en continu après la mise en production ;
application mobile, que vous soyez en charge de l’intégralité d’un produit
ou bien d’une partie du parcours utilisateur ou d’un composant. ◉ Adopter la bonne posture pour collaborer avec vos parties prenantes
et travailler en équipe.
Récemment arrivé·e en poste ou Product Manager aguerri·e, vous
trouverez dans ce livre des éléments pratiques pour vous guider dans votre
quotidien. Comme le sportif qui fait son entraînement ou le musicien qui
fait ses gammes, il y a des fondamentaux du produit auxquels les Product Une structure adaptée à
Managers reviennent sans cesse, quel que soit leur niveau de séniorité.
L’organisation du livre expliquée ci-dessous permet d’ouvrir n’importe quelle différentes lectures
page, de se remettre en mémoire les bonnes pratiques et de la refermer.
Ce livre est divisé en quatre modules, abordant chacun une étape clé
En tant que Product leader, cet ouvrage est un outil de partage et du processus Produit. Chaque module est ensuite divisé en chapitres, se
de transmission, un condensé de bonnes pratiques que vous pourrez concentrant chacun sur un concept à creuser. Vous pouvez choisir de lire
transmettre facilement à vos équipes. notre livre :

◉ De bout en bout, afin d’avoir une vue d’ensemble de la démarche

Produit ;
Ce que vous allez apprendre
◉ Par module pour creuser particulièrement une étape du processus ;
Ce livre vous donne une vue d’ensemble du cycle de vie d’un produit
numérique, depuis la définition de la stratégie jusqu’à l’amélioration ◉ Par chapitre pour vous pencher sur un sujet précis.
continue. Nous ne nous contentons pas de vous donner des connaissances
théoriques, nous vous donnons également les clés pour comprendre
les rouages du Product Management. Doté d’une vision complète de la
discipline et des outils efficaces, vous serez prêt·e à créer des produits à
succès !

Vous apprendrez comment :

◉ Comprendre la vision et la stratégie de votre entreprise et de votre

produit ;
12 13
INTRODUCTION
Les concepts sont illustrés à travers l’exemple d’une entreprise fictive
appelée « Thiga Eats ». Ce cas concret fil rouge est représenté par des
encadrés verts.
Thiga Eats
Thiga Eats est un service de livraison de plats cuisinés et d’épicerie
lancé par Thiga en 2020 et basé à Paris. Les commandes sont prises
sur l’application mobile de Thiga Eats auprès des restaurants/épiceries
partenaires à proximité, et sont livrées par des coursiers indépendants
(vélo, scooter, etc.). Imaginez que vous rejoignez Thiga Eats en tant que
Product Manager de l’équipe Activation, dont le périmètre va de la
recherche de plats jusqu’au paiement en ligne.
Nous vous proposons des templates pour vous aider dans l’utilisation de
certains outils.
Ces templates sont téléchargeables gratuitement
grâce à un QR code.
Dans certains chapitres, des notions sont mises en lumière à travers des
encadrés gris.
Pour aller plus loin...
Ces notions vous permettront d’aller un peu plus loin dans vos
connaissances, de prendre de la hauteur ou de découvrir des
pratiques innovantes que vous ne connaissez pas encore.
14
INTRODUCTION
En conclusion des chapitres, vous trouverez nos conseils pour faire
de vous des Product Managers aguerris et à la fin de chaque module, un
résumé des éléments clés à retenir.
Enfin, si certains termes ou concepts ne sont pas clairs, vous pouvez
vous référer au glossaire en fin de livre. Vous y trouverez une définition
courte du terme en question et, le cas échéant, une référence au chapitre
dans lequel le concept est décrit plus en détail.
Les éclairages pour la lecture
Le Produit
Chez Thiga, nous considérons comme un produit tout bien ou service
censé répondre à un besoin utilisateur. Si ce produit est un outil immatériel,
distribué à travers des moyens numériques, alors c’est un produit numérique.
Dans ce livre, nous utiliserons le terme « produit » pour désigner, selon
le contexte, l’intégralité d’un produit numérique, ou bien uniquement une
sous-partie correspondant au périmètre d’une équipe. Nous n’ajoutons pas
le terme « numérique » à chaque fois pour des soucis de fluidité de lecture.
Il est implicite. Les produits physiques ne font pas l’objet de cet ouvrage.
Les métiers du Produit
Dans le livre, nous mentionnerons les différents métiers qui
interviennent dans les activités Produit. Bien que les titres utilisés varient
d’une entreprise à une autre, nous utiliserons les termes Product Manager,
Product Designer et Product Marketing Manager qui nous permettront de
faire référence aux différentes compétences.
Le·la Product Manager (PM) est chef d’orchestre du produit. Il·elle est
responsable de faire des choix stratégiques pour le produit afin que celui-ci
ait un impact positif pour l’utilisateur et pour l’entreprise. À la croisée des
problématiques utilisateur, business et techniques, les Product Managers
donnent la direction stratégique et priorisent les sujets de l’équipe, parti-
cipent à la découverte des besoins utilisateur et à la conception des solu-
tions, gèrent le delivery et s’assurent de suivre le succès du produit. À noter
que le·la Product Manager endosse un rôle de Product Owner (PO) dans une
équipe qui fonctionne en Scrum. Ce rôle est exclusivement mentionné dans
ce cadre de travail agile. Bien qu’il existe des contextes où vous retrouvez
des PMs et des POs, nous considérons chez Thiga que le terme Product
15
INTRODUCTION

INTRODUCTION
Manager fait référence au métier, alors que le terme de Product Owner se
réfère au rôle endossé lors de la gestion des développements en Scrum.

Le·la Product Designer (PrD) est un·e UX/UI Designer avec une forte
culture Produit. Les Product Designers mettent toutes les méthodologies
et techniques de l’User eXperience (UX) au service de la stratégie, de la
conception des parcours, de la création des interfaces et de la performance
d’un produit. Les Product Designers ont un rôle clé en particulier dans les
activités de recherche utilisateur, conception des fonctionnalités et créa-
tion des interfaces.

Le·la Product Marketing Manager (PMM) a un rôle fondamental dans la

stratégie, en amenant une connaissance profonde du marché et du client
(celui qui achète). Il est garant du positionnement produit, c’est-à-dire de
l’adéquation entre la proposition de valeur et la demande du marché. C’est
une fonction qui est aussi clé dans la collaboration de l’équipe Produit avec
les équipes marketing, commerciales et le service client dans l’accompa-
gnement des lancements.

La culture Produit et culture Projet

On distingue la culture Produit de la culture Projet, car il existe des

différences fondamentales dans les approches. Un projet a un début et une
fin, ainsi qu’un budget qui est consommé durant sa durée de vie. À l’inverse,
un produit a un début, mais pas nécessairement de fin. Tout au long de
son cycle de vie, le produit évolue. L’approche Projet est basée sur la pla-
nification, les actions sont réalisées de manière séquentielle, formant une
suite d’issues prédictives. À l’inverse, une approche Produit ressemble à
une boucle (la boucle d’apprentissage) d’activités qui se répètent à l’infini.

Lorsque l’on a une approche Produit, on intègre généralement

l’approche agile pour livrer les fonctionnalités le plus rapidement possible.
Nous recommandons d’adopter les deux approches qui partagent certains
principes, notamment l’orientation utilisateur, la frugalité, l’autonomie des
équipes et l’amélioration continue.

16 17
 1—
MODULE №1

MODULE №1
Fixer
le cap

Le Product Management consiste à naviguer dans

«Les roadmaps doivent
l’incertitude, à trouver l’équilibre entre formuler une vision
et rester flexible pour l’atteindre, à créer des produits qui
apportent de la valeur aux utilisateurs et à l’entreprise. Pour
cela, il faut commencer par définir la stratégie Produit, c’est-
à-dire fixer le cap !

fournir clarté et focus, La roadmap est l’outil central d’une équipe Produit car elle
permet d’expliciter le chemin à prendre pour concrétiser la
aidant l’équipe à comprendre stratégie et met en avant les initiatives sur lesquelles l’équipe
va se concentrer dans les prochains mois. Bien plus qu’une

le pourquoi de son travail et liste de fonctionnalités à développer, la roadmap est un outil

puissant d’alignement et de communication qui vous aide à
partager au reste de votre organisation les choix de l’équipe
comment il contribue plus Produit.

largement à la vision Produit. » Pour construire la roadmap, vous devez avant tout
maîtriser le contexte dans lequel s’inscrit votre produit, en
vous imprégnant de la vision et la stratégie de votre entreprise,
— Bruce McCarthy
Fixer le cap

Fixer le cap
puis décliner cette stratégie en objectifs pour votre équipe en
vous appropriant la mission de votre équipe. Pensez à être en
permanence à l’écoute de vos utilisateurs et de vos parties
prenantes pour détecter de nouvelles opportunités à adresser.
18 19
MODULE №1
CHAPITRE 1
Maîtriser le contexte
du produit
L’une de vos missions en tant que Product Manager est de maîtriser la
vision et la stratégie dans lesquelles votre produit s’inscrit. Il est important
de comprendre et de parfois challenger ces éléments qui vous permettent de
fixer le cap et de solidifier vos futures décisions Produit..
S’approprier la vision et stratégie
La vision et stratégie Produit sont les résultantes d’une stratégie
d’entreprise plus large. Ces informations sont le plus souvent partagées aux
équipes Produit par le Chief Product Officer, le Head of Product ou par les
fondateurs qui tiennent souvent ce rôle en startup.
La vision, moteur de la motivation
La vision est le monde idéal que l’on souhaite créer pour les utilisateurs
à moyen terme (2 à 5 ans). Centrée sur les utilisateurs, orientée vers le
futur, inspirante, elle permet de créer un alignement de haut niveau entre
toutes les parties prenantes autour de la raison d’être du produit et la défi-
nition de son succès pour les utilisateurs et leur environnement. Avec la
vocation de motiver les équipes, la vision change peu fréquemment. On
trouve la vision sous forme d’une phrase courte, simple et inspirante qui
peut prendre des formes différentes, par exemple :
◉ Une « we believe statement », une affirmation qui résume les
convictions et aspirations de l’entreprise.
Fixer le cap
20
MODULE №1
We believe statement Thiga Eats
« Nous sommes convaincus que chacun doit pouvoir profiter d’une
cuisine saine et équilibrée facilement depuis chez soi. »
◉ Une « differentiation statement », une affirmation qui met
en évidence les caractéristiques, les avantages ou les qualités
distinctives d’une entreprise, d’un produit ou d’un service par
rapport à ses concurrents.
Différentiation statement Thiga Eats
Pour les citadins des grandes métropoles qui n’ont ni le temps ni l’énergie
de se faire à manger, mais ont une consommation responsable, Thiga
Eats est un service qui permet de se faire livrer des plats de qualité
depuis des restaurants et épiceries de son quartier. Contrairement à
Uber Eats, Deliveroo ou Frichti, Thiga Eats offre une sélection qualitative
et une garantie d’écoresponsabilité.
La stratégie, cadre des ambitions
La stratégie permet de cadrer à moyen terme (1 à 2 ans) comment
atteindre la vision. Autrement dit, la stratégie décrit comment se rappro-
cher de la vision, comment réduire l’écart entre la situation actuelle du
produit et l’état que l’on souhaite atteindre. Richard P. Rumelt, l’un des
penseurs les plus influents en matière de stratégie et de gestion, confie
dans son livre Good strategy, Bad strategy : « Le noyau d’une bonne stratégie
contient trois éléments principaux : le diagnostic d’un problème, une direction
appropriée, et un ensemble d’actions cohérentes ».
◉ Le diagnostic explique le « pourquoi » : il permet une
compréhension commune et claire de la situation actuelle
du produit sur le marché, de repérer les tendances de fond et
de projeter des scénarios et anticiper les mouvements de la
Fixer le cap
concurrence. Le problème majeur que l’on souhaite résoudre
sur la période à venir est résumé sous forme de challenge.
21
MODULE №1

MODULE №1
◉ La direction répond au « quoi » : elle est l’approche à adopter pour
La stratégie Thiga Eats
répondre au challenge que l’on se fixe et décrit en quelques phrases
à quoi ressemblerait le succès (et l’échec), pourquoi le challenge est
désirable, accessible pour l’entreprise, mais aussi ce à quoi vous Marché Produit Organisation
devez renoncer pour y parvenir.
Le diagnostic
◉ Les actions précisent le « comment » : elles forment un ensemble
cohérent qui permet d’aligner les activités de l’entreprise.
Où Un nouvel «Le produit Mauvaise
étiez-vous acteur dans la sympa qui doit communication
livraison de encore faire intra-équipes
La stratégie peut changer pour prendre en considération de nouveaux il y a 12 à 18
repas ses preuvesM
mois ?
challenges ou opportunités (arrivée de nouveaux acteurs sur votre marché,
mise en place d’une réglementation, levée de fonds, nouvelle initiative à
forte valeur…).
Qu’est-ce qui Pandémie Création ClariÑcatioË Recrutements
vous a mené là boost des d’outils pour de la mission notamment UX
Une bonne stratégie permet d’autonomiser les équipes en donnant du où vous êtes ? commandes prénétrer le des équipeÅ research et
marché : + excellente Product Ops
contexte et en posant un cadre permettant aux initiatives d’émerger et être parrainages exécution
sélectionnées organiquement. Elle donne une direction à suivre, mais elle animation
Renforcement commerciale
laisse aussi une marge de manœuvre aux équipes. de la présen-
tation de l’ofre Télétravail

quoi Un acteur Une population PerceptioË qonne

essem le la solide cté de plus en plus de l’ofr4 conÑance entre
situation restauratioË soucieus4 Thiga Pats plus équipes
auou ’ui ? et livraisoË de l’environ- qualitative que
de courses nement la concurrence

‚atigue des
équipes
Un marché de Lombreuses
plus en plus frictions dans
saturé le parcours de
recherche

ot e Comment pouvons-nous nous diférencier de la concurrence

callen†e dans un marché presque saturé ¡

La di®ection
Pn favorisant le local et la personnalisation sur les ¿¹ ½ ¿º prochains moisÆ
nous voulons montrer aux clients Thiga Pats qu’il est possible d’utiliser uË
service de livraison ¿³³Í responsable²

Les actions
Fixer le cap

Fixer le cap
ò ïeal avec des partenaires responsables áéquipes salesà Ý
ò Communiquer sur la responsabilité áéquipe marÙetingà Ý
ò Renforcer les usages des ofres locales áproduitಲ²

22 23
MODULE №1

MODULE №1
Contribuer au diagnostic stratégique ◉ Construire votre analyse sur la base des éléments collectés.

Le diagnostic est constitué d’informations sur le marché, l’organisation
et le produit. En tant que Product Manager, vous contribuez de près ou
de loin (selon votre entreprise, profil, séniorité…) à établir des éléments
du diagnostic quant au marché et au produit. L’analyse de l’organisation,
relevant des compétences du Head of Product, est le plus souvent complétée
par ce dernier.
La formalisation de ce diagnostic du marché dépend souvent du type
d’analyses qui sont menées. Un format qui fonctionne bien est un deck de
slides qui résume les observations et apprentissages.
Les informations sur le produit

Les éléments du diagnostic Vous devez également vous intéresser de près à votre produit. En pre-
nant de la hauteur sur la situation, l’historique des succès et des échecs,
vous pouvez ainsi vous projeter sur de nouveaux objectifs et challenges.

Le 5 r210 Pour faire cet état des lieux, appuyez-vous sur les données quantitatives
Market Research et qualitatives. Voici quelques exemples d’activités que vous pouvez mener
Benchmark
pour nourrir ce diagnostic :

◉ Étudier les principales métriques de votre produit (chapitre 16) ;

L!or i tio
Les collaborateurs ◉ Identifier les points de frictions sur le parcours utilisateur (taux
d’abandon à chaque étape du parcours) ;

◉ Auditer vos fonctionnalités (niveau d’adoption, fréquence d’utilisation) ;

Le produit
Data ◉ Étudier les retours de vos utilisateurs et dégager des thématiques
User Research
Feedback récurrentes ;

◉ Analyser la satisfaction de votre produit grâce aux enquêtes de

satisfaction ou aux commentaires publics.

Les informations sur le marché

Votre diagnostic Produit doit être alimenté par des informations sur
le marché, notamment l’analyse de vos concurrents, vous permettant de
comprendre le positionnement de votre produit.

Pour réaliser cette analyse, vous pouvez :

◉ Réaliser une veille des produits de vos concurrents directs et

indirects. Intéressez-vous au positionnement qu’ils ont, aux fonc-
tionnalités qu’ils proposent et aux nouveautés prévues en testant
Fixer le cap

Fixer le cap
leur produit ou en parcourant leur roadmap si celle-ci est publique ;

◉ Analyser les ressources mises à disposition par les équipes Product

Marketing (études de marché, benchmark des concurrents…) ;

24 25
MODULE №1

Synthétiser les éléments de diagnostic
avec le SWOT
Le SWOT (Strengths Weaknesses Opportunities Threats) est un
framework pouvant être utilisé pour synthétiser ces éléments de
diagnostic internes et externes.
Le SWOT vous permet de lister les atouts (Strengths & Opportunities)
dont vous disposez, et les handicaps (Weaknesses & Threats) auxquels
vous êtes confronté. Il vous aide à définir une stratégie qui s’appuie sur
vos avantages compétitifs et anticipe les risques auxquels vous serez
confronté.
MODULE №1
Nos conseils
◉ La vision n’est pas systématiquement formalisée sous forme d’une
phrase, vous aurez parfois accès à plusieurs documents qui vous
permettront de saisir l’orientation à prendre.
◉ Si vous n’avez pas accès à des informations précises sur la vision
et la stratégie, n’hésitez pas à les formaliser vous-même. Posez
des questions à vos Product leaders afin de mieux comprendre
la direction stratégique que vous devez suivre et partagez les
informations à votre équipe.

Le SWOT Thiga Eats

◉ Votre marché et votre produit évoluent constamment, renouvelez
votre diagnostic une à deux fois par an.



   

M+(-'Q+I&
 nb!!!%d [%W!#!%j
 l!!!%!%

tr t US!
 X#W!!#h!WW!!h
z-Gv'-&&-&
 $ %%%!!#
W %{
 }!% "! !#!%

*,,/(+)'.+.-& JI(-G+&
 $ %!#!  $ %!%!65 !%
" %!! #%!
ts
tr t  !#!!%!
!%!! ! % !
Fixer le cap

Fixer le cap
26 27
MODULE №1
CHAPITRE 2
Définir une mission
et des objectifs
pour l’équipe
Comme le souligne l’auteur d’Inspired : « Les bonnes équipes tirent leur
inspiration de leurs objectifs, de l’observation des difficultés des clients, de
l’analyse des données que ces clients génèrent en utilisant leur produit, et
de leur recherche constante pour résoudre de vrais problèmes grâce à la
technologie ». Des objectifs clairs rendent une équipe Produit autonome, en
l’aidant à se poser les bonnes questions et à prendre les bonnes décisions.
Mission et métriques de l’équipe
La mission d’une équipe est sa raison d’être. Stable dans le temps, elle
résume en quelques mots simples et compréhensibles le moyen par lequel
l’équipe va participer à l’atteinte de la vision Produit.
Mission d’une équipe chez Thiga Eats
L’équipe Activation a pour mission d’amener nos nouveaux utilisateurs
à effectuer leur première commande.
Fixer le cap
28
MODULE №1
Il n’est pas forcément de votre ressort de déterminer la mission de
votre équipe Produit. Ces décisions sont étroitement liées à la structure
de l’organisation et sont souvent déterminées directement par les Product
leaders. De plus, si vous intégrez une équipe déjà en place, celle-ci aura
bien entendu déjà cadré son périmètre d’intervention. En tant que Product
Manager, vous devez incarner cette mission dans toutes les décisions que
vous avez à prendre et la faire infuser dans votre équipe. Aussi, lorsque la
mission de votre équipe vous est communiquée, n’hésitez pas à la challenger
et faire des propositions si un élément vous paraît flou.
Afin d’évaluer à quel point votre équipe remplit sa mission, les grandes
métriques mises en place vous sont très utiles. Sous la forme d’une ou
plusieurs métriques clés, vous avez la possibilité de suivre le succès à
long terme de votre équipe. De la même manière que la mission, celles-ci
peuvent vous être communiquées par vos Product leaders ou vous pouvez
également faire des propositions.
Métrique clé de l’équipe Activation
La métrique clé est le pourcentage d’utilisateurs qui ont réalisé une
première commande sur l’application.
Les objectifs pour piloter l’impact
de l’équipe
D’où viennent les objectifs ?
Les objectifs d’une équipe doivent découler de la stratégie. Ils peuvent
être fixés de façon top-down par les Product leaders, ou bien définis de
façon bottom-up par l’équipe.
Quel que soit votre contexte et point de départ, vous devez vous pencher
sur les objectifs de votre équipe pour y raccrocher votre roadmap (chapitre 4).
Fixer le cap
29
MODULE №1

MODULE №1
Les objectifs découlent de la stratégie ◉ Relevant (Pertinent) : ils doivent être en accord avec votre périmètre
d’équipe et la stratégie ;

◉ Time-bound (Échéance) : vous devez fixer une limite dans le temps

à laquelle vous espérez atteindre vos objectifs.
organisation Vision Stratégie

Objectif de l’équipe Activation

Un objectif SMART de l’équipe Activation pourrait être par exemple :

« améliorer la pertinence des suggestions proposées à un nouvel
Objectifs &
équipe produit métriques
Roadmap utilisateur ». On peut le mesurer à travers le taux de conversion depuis
la liste des propositions de restaurants d’ici à septembre.

Le rôle des objectifs d’équipe
Les objectifs créent une dynamique collective et ambitieuse au sein de votre
équipe. Point de départ de toute initiative, les objectifs ont le bénéfice de :
◉ Fixer l’ambition pour une période donnée ;
◉ Favoriser l’alignement des parties prenantes ;
◉ Permettre l’autonomie de l’équipe pour créer la roadmap ;
Le framework OKR
OKR, pour Objectives and Key Results, est une méthode de plus en
plus répandue de modélisation de la stratégie (d’une entreprise, d’un
produit ou d’une équipe). Conçue chez Intel et mise en place par Google
en 1999, elle repose sur deux piliers :
1. Des objectifs ambitieux et inspirationnels ;
2. Des Key Results ou indicateurs clés de mesure du succès, chiffrés
et bornés dans le temps.

◉ Garantir le focus des efforts de l’équipe autour des initiatives clés.
Pour fixer vos objectifs, assurez-vous d’avoir des objectifs SMART :
Dans une organisation qui utilise l’approche OKR à tous les niveaux, les
objectifs de chaque équipe sont une déclinaison des OKR stratégiques
de l’entreprise. Cela permet de garantir que l’ensemble des équipes
avancent dans la même direction et contribuent à leur niveau à
l’atteinte des objectifs stratégiques.

◉ Specific (Spécifique) : veillez à ce que chaque objectif soit

représentatif d’une ambition unique, claire et précise ;

◉ Measurable (Mesurable) : pour évaluer l’atteinte de chaque objectif

à travers les initiatives que vous mènerez, vous devez y associer des
Fixer le cap

Fixer le cap
moyens de les mesurer ;

◉ Achievable (Faisable) : vos objectifs doivent être ambitieux, mais

réalistes ;
30 31
MODULE №1

MODULE №1
Les OKR à différents niveaux
Objectif exclu par l’équipe Activation
Vision
Pour notre équipe Activation, on écartera l’objectif « permettre aux
restaurateurs de s’onboarder de manière 100 % autonome », qui n’est
Obj. strNtéKique G Obj. strNtéKique 2 Obj. strNtéKique <
Niveau pas de la responsabilité de l’équipe, mais qui sera géré par l’équipe B2B.
stratégique
kr kr kr
Annuel
kr kr
Les objectifs étant fixés, vous devez aussi définir les critères de
kr
performance clé (KPIs) qui permettent de mesurer la valeur apportée. Vous
pouvez ainsi valoriser :
Obj. équipe G Obj. d’équipe 2
Niveau équie
kr kr ◉ Un impact sur l’évolution d’une métrique clé (Impact) ;
Trimestriel
kr
◉ La sortie d’une fonctionnalité clé qui permettra d’impacter vos
kr Obj. d’équipe <
métriques (Ship) ;
kr
◉ Le gain de nouvelles connaissances qui vous aideront à prendre des
kr
décisions futures (Learn).

Il est important de choisir une cible à atteindre pour chaque métrique.

Ainsi, une fois le temps imparti écoulé, il vous suffira d’évaluer si la cible
est atteinte.

Fixer et gérer les objectifs de votre KPIs de l’équipe Activation

équipe
Pour l’objectif « améliorer la pertinence des suggestions proposées à
un nouvel utilisateur », nous pouvons fixer d’ici à septembre :

Bien définir les objectifs

◉ + 25 % de conversion depuis la liste des propositions de
En tant que Product Manager, vous allez définir les objectifs en restaurants (Impact) ;
collaborant avec votre équipe et vos Product leaders. Vous devez mettre
le focus sur ceux qui apportent de la valeur pour vos utilisateurs et votre ◉ Lancer le module « suggestion de la semaine » (Ship) ;
entreprise. Une fois que vous les avez identifiés, il faudra faire un choix
pour n’en conserver que quelques-uns. Un ensemble de trois ou quatre ◉ Évaluer le potentiel d’une recommandation de restaurant selon
objectifs est pertinent pour vous laisser un champ d’action suffisamment le profil consommateur (Learn).
large et avoir un impact tout en gardant un focus pour l’équipe. Pour vous
aider, écartez les objectifs qui ne sont pas alignés avec la vision Produit et
ceux qui ne sont pas en lien avec votre mission d’équipe. Veillez à valider
Fixer le cap

Fixer le cap
ces choix avec vos Product leaders, qui s’assureront que cela ne nuise pas à
la collaboration entre les équipes ou ne crée pas de nouveaux silos.

32 33
MODULE №1

Ajouter un objectif de responsabilité
N’oubliez pas de considérer la responsabilité de votre produit. Si
vous pensez qu’il faut accélérer sur le sujet, ajoutez un objectif dédié
(par exemple « rendre le produit plus accessible » ou « prévenir les
comportements négatifs »).
MODULE №1
Nos conseils
◉ Partagez clairement et régulièrement votre mission d’équipe avec
toutes vos parties prenantes pour rassembler vos collaborateurs
et progresser ensemble dans la bonne direction.

Comme l’évoque Fabrice Des Mazery dans le livre Responsables : « nous ◉ Pour fixer une ambition d’impact, étudiez l’évolution de votre
sommes, en tant que concepteurs de produits, responsables de la métrique et proposez une projection au-dessus des chiffres
façon dont nous donnons vie aux produits ainsi que de leurs effets sur que vous observez. Si vous optez pour une nouvelle métrique,
le monde. Nous ne pouvons pas nous permettre d’ignorer le rôle que commencez par fixer une cible qui justifie l’effort que vous voulez
nous jouons aujourd’hui, d’autant plus que les utilisateurs sont de plus y consacrer.
en plus attentifs au fonctionnement des produits qu’ils consomment. »
◉ Assurez-vous de suivre les objectifs de l’équipe en présentant les
Vos objectifs responsables peuvent aussi se focaliser sur les limites que résultats lors de rituels d’équipe réguliers.
vous souhaitez respecter, les métriques seront alors plutôt des « anti-
KR » que l’on cherchera à faire diminuer (par exemple « temps maximum
par session utilisateur » ou « nombre maximum d’interruptions de
service par semaine »…).

Quand définir les objectifs et les réévaluer

Généralement, les objectifs d’entreprise sont définis sur une année, et

les objectifs des équipes sont définis sur un trimestre. Toutefois, dans le cas
de startups qui ont besoin de réagir et d’aligner leur stratégie régulièrement
sur les évolutions du marché, les objectifs stratégiques peuvent être revus
plus souvent.

Nous vous conseillons de revoir vos objectifs de façon trimestrielle

afin d’évaluer si vous avez atteint votre cible. Il vous arrivera de vouloir
continuer à travailler sur un objectif qui reste pertinent en adaptant les
métriques ou la cible.
Fixer le cap

Fixer le cap
34 35
MODULE №1

MODULE №1
CHAPITRE 3 Le modèle de l’Atomic Research

Identifier des Expériences

« On a fait ceci »

Les expérimentations forment des signaux bruts

opportunités Produit
et servent à puiser les faits.

« On a trouqé ceci »

Faits Des faits impartiaux et utiles sont recueillis à partir

Les demandes, les idées, les retours utilisateur, les données… tous ces des expériences.

éléments constituent le terreau de votre produit. Issus de multiples sources, Tests des

vous parvenant sous différentes formes, vous allez traiter ces entrants pour « On a appris ceci »
recommandations

détecter de nouvelles opportunités. Insights Les faits sont interprétés. wn ou plusieurs faits

peuvent se connecter pour créer un insight.

« µ­ors on qa faire ceci »

Opportunités Des recommandations peuvent ”tre faites à parti

des insights.

Dégager des insights

Qu’est-ce qu’un insight ?
Pour mieux comprendre comment dégager ces opportunités à partir de
sources variées, prenons le temps de définir ce qu’est un insight. Un insight
donne une explication contextualisée de faits constatés, qu’il s’agisse de
problèmes ou constats positifs. Comme le souligne Daniel Pidcock, Product
Designer et théoricien de l’Atomic Research « c’est l’analyse des faits qui
donne lieu à une interprétation. Un ou plusieurs faits peuvent se connecter
pour créer un insight. »
La recherche exploratoire
Il existe différentes approches de recherche et nous vous recommandons
de les associer. En effet, il est important de considérer deux axes d’analyse.
Le premier axe distingue ce que les gens disent (leur attitude face au produit)
de ce que les gens font (leur comportement). Le second axe différencie les
approches quantitatives (le quoi) des approches qualitatives (le pourquoi).
Les approches de recherche

Identifier les insights vous permet de prendre de meilleures décisions Ce que les gens disent
concernant les prochaines étapes pour votre produit.

Exemple : Exemple :
Interviews SonMaQes, NKS

Qualitatif Quantitatif
Fixer le cap

Fixer le cap
Exemple :
Exemple :
Observation,
Analytics
Session replay

36 Ce que les gens fnt 37

MODULE №1

MODULE №1
Pour identifier de nouveaux insights, vous pouvez commencer par
Liste des entrants de l’équipe Activation
identifier les symptômes ou les problèmes par le biais de la recherche
quantitative. Celle-ci vous permet de dégager des tendances. La donnée
collectée sur l’utilisation de votre produit, à travers le taggage (chapitre Voici la liste des entrants issus de la recherche utilisateur, de la
17), vous permet de comprendre en détail comment vos utilisateurs donnée Produit et des demandes des parties prenantes :
interagissent avec votre produit. Grâce à ces données, vous pouvez détecter
les fonctionnalités les plus utilisées et celles qui ne le sont pas ou pour
lesquelles vos utilisateurs ne parviennent pas à finaliser le parcours
attendu.

Une fois les problèmes identifiés, vous pouvez chercher à en comprendre

les raisons par le biais de la recherche qualitative exploratoire. La recherche
exploratoire implique une observation directe, une enquête approfondie et
une analyse minutieuse afin de développer une compréhension complète
des utilisateurs — qui ils sont, ce qui les intéresse, ce qui motive leur
comportement et leurs décisions, etc.

Les demandes des parties prenantes

Le département marketing, le service client et le service commercial

peuvent également être sources d’insights indispensables, notamment dans
le cas de produits B2B. Par leur proximité avec les utilisateurs et clients ou
grâce à leur expertise sur un domaine particulier, ils identifient des thé-
matiques et des sujets à adresser. Il est impératif de vous rapprocher de
l’ensemble de vos parties prenantes régulièrement pour avoir de la visibilité Détecter des opportunités Produit
sur ces sujets.
à adresser
Au-delà des axes stratégiques formulés, il est possible que votre top
management soumette des demandes. Il peut s’agir d’un nouveau projet
stratégique à intégrer, d’une piste de solution à creuser ou d’une opportunité Catégoriser vos entrants
à étudier.
Maintenant que vous avez récolté les entrants, tout l’enjeu est de
Les changements de législation et contraintes juridiques génèrent distinguer les véritables problèmes — pour lesquels vous pouvez apporter
également des demandes. Celles-ci aboutissent en général à des une solution — des problèmes pour lesquels vos utilisateurs ne cherchent
changements non négociables à apporter au produit. Le service juridique pas activement de solution (ou déjà couverts par une alternative, et qui
peut également faire des suggestions pour vous aider à améliorer vos ne sont pas de vrais problèmes). Pour cela, commencez par détecter des
pratiques, notamment en termes de RGPD et lorsqu’il y a une zone grise tendances en identifiant les sujets qui se recoupent. Les multiples demandes
dans la législation. N’hésitez pas à vous rapprocher d’eux. que vous avez reçues ainsi que les insights utilisateur peuvent parfois
émaner du même problème utilisateur, c’est pourquoi il est important de les
catégoriser. Cela vous permet également de différencier les retours isolés
des problèmes plus critiques.
Fixer le cap

Fixer le cap
38 39
MODULE №1

MODULE №1
Identifier vos opportunités Opportunity Solution Tree de l’équipe Activation
Grâce à la catégorisation de vos entrants, vous faites émerger une
multitude d’opportunités pour vos utilisateurs, vos éventuels clients et À partir des entrants collectés, on peut construire l’Opportunity
votre business. Bien qu’il soit tentant de vouloir toutes les résoudre, vous Solution Tree suivant :
devrez adresser avant tout les opportunités qui auront le plus d’impact sur
vos objectifs en les priorisant dans la roadmap (chapitre 4). Résultat attendu
Augmentation du nom%re d’utilisateurs actifs
Pour bien identifier vos opportunités, vous pouvez utiliser un OST
(Opportunity Solution Tree), arbre dans lequel les opportunités enfants sont
reliées à des opportunités parentes plus vastes. Préconisé par la célèbre
conférencière et coach Teresa Torres dans son livre Continuous Discovery Opportunité Opportunité Opportunité
Habits, la création de cet arbre permet de :
Je ne trou e rien à commander Je culpa%ilise de Je trou e que les
l’impact écologique résultats ne me
◉ Bien appréhender la complexité de certaines opportunités et mettre lorsque je correspondent
commande pas
en évidence les liens entre elles (certaines se ressemblent, sont des
sous-ensembles d’une opportunité plus grande) ;

◉ Diviser des problèmes majeurs, qui peuvent paraître insurmontables,

en sous-problèmes plus petits et auxquels il est plus facile d’apporter Opportunité Opportunité Opportunité Opportunité
une réponse ;
Il n’y a pas Les Je ne Proposer des
d’ofre egan restaurants comprends résultats de
◉ Livrer de la valeur de façon itérative en vous permettant de régler que je préfère pas comment restaurants selon
les problèmes plus petits qui, un par un, vous rapprochent d’une ne sont pas cOercOer un qui je suis
proposés restaurant
résolution du problème parent plus large.

Votre arbre d’opportunités peut être enrichi au fil du temps en y ajoutant

des opportunités majeures ou des sous-opportunités à mesure que vous
collectez de nouveaux insights. Solution Solution

Améliorer les résultats Module de suggestion de

de restaurants selon o„ la semaine
je suis
Fixer le cap

Fixer le cap
40 41
MODULE №1

MODULE №1
Nos conseils
◉ Rassemblez vos entrants et les informations issues de votre
recherche dans un document commun pour faciliter l’analyse et le
partage de connaissances entre les membres de l’équipe.

◉ Lorsque vous collectez des feedbacks, ne faites pas de tri en

amont ! Même si les éléments collectés ne sont pas pertinents dans
l’immédiat, ils pourront nourrir la détection de futurs insights.

◉ Pour encourager vos parties prenantes à remonter des demandes

régulièrement, assurez-vous de leur donner une visibilité sur le
suivi de leurs sujets
Fixer le cap

Fixer le cap
42 43
MODULE №1

MODULE №1
CHAPITRE 4 ◉ Next représente le prochain cycle. Généralement d’une durée
identique au Now, il regroupe les initiatives déjà priorisées, bien
que moins prioritaires que les précédentes. Le niveau de priorité de

Créer ces éléments peut changer d’ici à la fin du cycle en cours.

la roadmap
La roadmap, document star des équipes Produit, est bien souvent au
cœur des préoccupations. Littéralement « feuille de route », la roadmap
permet d’organiser dans le temps les étapes à parcourir pour concrétiser la
stratégie. Comme l’explique Bruce Mccarthy dans son livre Product Roadmap
Relaunched, « une roadmap n’est pas une liste de fonctionnalités que l’on
souhaite implémenter, mais un outil de communication stratégique qui permet
de créer une compréhension partagée de l’impact que l’on souhaite avoir ».
◉ Later regroupe l’ensemble des initiatives intéressantes, mais qui ne
sont pas prioritaires pour l’instant. Il ne s’agit pas d’y ajouter toutes
les initiatives évoquées au cours du temps, mais bien de faire un tri
pour ne garder que celles pour lesquelles vous détectez un potentiel
intéressant à conserver. Là encore, le niveau de priorité sera revu
régulièrement.
Les objectifs
La roadmap est orientée Outcome (impact) et non Output (production).
Les initiatives Now doivent nécessairement être reliées à vos objectifs
(chapitre 2) en vous assurant que ce soit bien visible sur la roadmap (choix
d’un code couleur visuel par exemple). Il se peut que les initiatives du Later
ne soient pas encore rattachées à des objectifs, c’est aussi pour cela qu’elles
ne sont pas prioritaires.

La roadmap, un outil stratégique Différents formats de roadmap

Une roadmap permet d’illustrer le chemin que vous allez prendre pour Objectifs en ligne
atteindre vos objectifs (chapitre 2). Toute roadmap est constituée de trois
éléments incontournables : une échelle de temps, des objectifs, et enfin des
initiatives rattachées à ces objectifs et priorisées sur l’échelle de temps. Objectif 1 Objectif 2 Objectif 3 Hors scope
OKR

L’échelle de temps Opportunité 1 Opportunité 2 Opportunité E

Now Fonctionnalité 2 Fonctionnalité E
Il est important que la roadmap reste à haut niveau, car ce n’est pas
un calendrier de dates précises détaillant les fonctionnalités qui vont être Fonctionnalité 1
développées. Toutefois, si vous connaissez déjà la date d’un jalon business
important (lancement d’une campagne marketing, ouvertures des ventes
pour Noël ou entrée en vigueur d’une nouvelle réglementation, par exemple),
vous pouvez la faire apparaître en annotation pour la garder en tête. Ainsi, next Opportunité " Fonctionnalité N
la roadmap est généralement modélisée sous le format Now, Next, Later :

◉ Now représente l’horizon le plus proche. Il peut s’agir, selon votre

Fonctionnalité "
Fixer le cap

Fixer le cap
organisation, d’un trimestre, d’un cycle de X jours, semaines ou
mois. Vous regroupez ici les initiatives les plus prioritaires. later Opportunité N Opportunité -
Opportunité ;

44 45
MODULE №1

MODULE №1
Objectifs en colonne Les initiatives

Now next later Les initiatives représentent les sujets de l’équipe et peuvent se présenter
sous forme :
Fonctionnalité 1 Opportunité c Opportunité 5
Objectif 1
Fonctionnalité 4 ◉ D’opportunités, pour lesquelles il faudra d’abord passer par une
phase de discovery (Module 2) ;
Opportunité 1
◉ De fonctionnalités, qui sont déjà passées en discovery et qui
Fonctionnalité C Fonctionnalité 5 peuvent passer en delivery (Module 3).
Objectif :
Opportunité 4
Un support visuel et accessible

Pour faciliter les échanges, le format de la roadmap est important afin

Opportunité C que celle-ci soit accessible, lisible et facilement compréhensible. Plusieurs
Objectif M supports peuvent être envisagés, mais nous vous conseillons de privilégier
une représentation graphique simplifiée.

Il existe de nombreux outils aujourd’hui permettant de modéliser une

roadmap : un board sur Notion, Miro, des slides ou encore en utilisant des
Fonctionnalité c
Hors scope OKR outils tels que Productboard ou Harvestr. Ci-dessous, nous avons présenté
Opportunité l quelques exemples de mise en forme d’une roadmap :
Opportunité z

Objectifs en couleur

Oa`ectiY " Oa`ectiY 5 Oa`ectiY : Hors scope OKR

Now next later

Fonctionnalité " Opportunité 4 Opportunité 5
Fonctionnalité 5 Fonctionnalité 5 Opportunité C
Opportunité " Opportunité Q
Fonctionnalité : Fonctionnalité 4
Fixer le cap

Fixer le cap
Opportunité 5
Opportunité :

46 47
MODULE №1

MODULE №1
Roadmap de l’équipe Activation réalisée sur Notion Roadmap de l’équipe Activation réalisée sur Miro

Now next later

Aéliorer la Module Proposer des
pertinence des «Suggestion de la résultats selon
résultats semaine» «+ui je suis»
proposés ° un
nouvel utilisateur Fonctionnalité Opportunité

Améliorer les
résultats selon «oR
je suis»
Fonctionnalité

Assurer un Réduire le temps de Intégrer solutions

processus de chargement des paiement ƒiczets
paieent sans pages Restaurants
friction”
Fonctionnalité Fonctionnalité

Optimiser le Augmenter la couuerture des solutions de

processus de paiement acceptés
parrainage
Opportunité
Opportunité

Augenter les Badges BIO & Zéro Option «Sans Inciter Ê la

usages éco- Déchet couuerts» consommation
responsaÖles éco-responsable
Fonctionnalité Fonctionnalité
Opportunité

Améliorer la uisibilité des partenaires éco-

responsables
Fonctionnalité

Introduire
 Créer un badge Améliorer la uisibilité des partenaires

et faire grandir Vegan offrant des menus Vegan
l’offre Vegan
Fixer le cap

Fixer le cap
Fonctionnalité Opportunité

48 49
MODULE №1
Créer et partager sa roadmap
Pour remplir sa fonction, la roadmap doit être co-construite, partagée
et communiquée régulièrement.
Élaborer la roadmap avec les parties prenantes
Une roadmap est avant tout un objet conversationnel permettant
d’aligner l’ensemble des interlocuteurs autour de priorités communes. Pour
qu’elle soit acceptée, elle doit être le fruit de discussions et de recherches
conjointes avec vos parties prenantes.
Pour créer votre roadmap, vous avez préalablement récupéré toutes
les informations nécessaires telles que vos objectifs (chapitre 2), les
opportunités (chapitre 3), les fonctionnalités importantes et toute autre
information liée à des jalons importants, des contraintes, des dépendances…
Grâce à toute cette matière, vous allez pouvoir organiser votre roadmap en
identifiant les initiatives les plus prioritaires (chapitre 9).
Vous pouvez soit réaliser un premier jet de votre roadmap et le présenter
à vos parties prenantes pour vous assurer que tout le monde soit aligné sur
les priorités du cycle à venir, ou bien organiser un atelier de roadmapping
afin de prioriser votre roadmap en séance.
Une fois vos choix fixés, il est important de présenter votre roadmap
aux décideurs (vos Product Leaders, éventuellement les responsables de
départements dans votre organisation) afin que ceux-ci puissent s’assurer
que les roadmaps des différentes équipes soient bien alignées et en accord
avec la stratégie.
Parler régulièrement de votre roadmap
La roadmap est parfois publiée de façon confidentielle ou ponctuelle.
C’est une erreur, car elle doit être un outil constant d’alignement pour les
collaborateurs. Dès sa construction avec les parties prenantes, lors de sa
publication et jusqu’à ce qu’une nouvelle édition soit publiée, il convient
d’évangéliser sur son évolution. Cela implique notamment de communiquer
régulièrement sur les impacts atteints, les changements de priorités, les
nouveautés, etc.
Fixer le cap
50
MODULE №1
En tant que Product Manager, votre rôle est de faire preuve de
pédagogie auprès des parties prenantes, en leur rappelant que votre
roadmap représente ce qui est prioritaire à un instant T et en fonction des
informations dont vous disposez. Si un élément ne figure pas dans votre
roadmap ou est identifié comme un élément non prioritaire, cela ne signifie
pas que l’initiative ne sera jamais prise en compte. Expliquez simplement
que le focus de la période en cours est porté sur d’autres sujets. Afin de
gérer au mieux les attentes, montrez-vous ferme et transparent·e sur les
priorités actuelles, mais invitez les parties prenantes à vous reposer la
question lors des prochains ateliers de priorisation. Pour faciliter cette
communication, profitez des moments de partage entre équipe ou avec
vos parties prenantes pour faire des rappels. N’hésitez pas à présenter des
chiffres clés sur l’avancement et l’atteinte des objectifs, par exemple lors de
vos reviews (chapitre 11).
Se positionner comme responsable de la roadmap
Au cours de votre carrière, vous serez probablement confronté·e à
plusieurs reprises à des roadmaps que vous êtes en charge d’exécuter, mais
que vous n’avez pas contribué à définir. C’est le cas si vous rejoignez une
organisation dans laquelle la roadmap a été définie avant votre arrivée ou
si vous évoluez dans une organisation au sein de laquelle la roadmap est
définie par les Product leaders.
Quelle que soit la situation dans laquelle vous vous trouvez, n’oubliez
jamais que c’est vous le garant de la roadmap de votre équipe. Vous
devez être en mesure de la présenter et d’être incollable sur son contenu.
Qu’importe les cas de figure, vous devez vous l’approprier et, dans la
mesure du possible, la challenger. Si certaines choses vous échappent ou si
vous avez des doutes sur la priorisation de certains éléments par rapport
à d’autres (lorsque vous prenez connaissance d’un nouveau contexte par
exemple), n’hésitez pas à questionner vos Product Leaders ou bien vos
parties prenantes. Vous devez également collaborer avec votre équipe pour
déterminer ce que vous êtes en mesure de livrer et les challenges que vous
devez repousser. Rappelez-vous qu’une roadmap doit être co-construite, les
sachants qui vous entourent sont donc les mieux placés pour challenger
avec vous la priorisation préétablie.
Fixer le cap
51
MODULE №1

MODULE №1
Nos conseils L’essentiel
◉ Si une opportunité non priorisée dans votre roadmap émerge en
de ce module :
cours de période, posez les bonnes questions avant de l’intégrer
dans votre roadmap. L’opportunité contribue-t-elle à l’atteinte des
objectifs fixés ? Quelle opportunité devez-vous déprioriser à la
place ?

◉ Changer trop souvent de priorité peut rapidement avoir des

conséquences significatives sur votre capacité à livrer de la valeur, 1.
mais aussi sur la motivation de l’équipe. Rappelez ces risques à
vos parties prenantes si elles sont à l’initiative de nombreuses
requêtes. 2.
◉ Si vous souhaitez confronter votre roadmap à vos utilisateurs,
vous pouvez la rendre publique, dans son format d’origine ou dans
une version simplifiée. Vous pourrez ainsi collecter des retours et 3.
obtenir des informations utiles pour nourrir vos prochains cycles.
La vision et la stratégie sont les fondations de vos futures décisions
Produit.
En tant que Product Manager, vous pouvez nourrir la stratégie en
contribuant au diagnostic du marché, des concurrents et du produit
en lui-même.
Pour bien comprendre le contexte et les enjeux dans lesquels
s’inscrivent votre produit, appuyez-vous sur les leaders de votre
organisation.

4. Cadrez la contribution de votre équipe à l’atteinte des objectifs

globaux de l’entreprise en définissant votre mission et vos objectifs.

5. Vos objectifs doivent être limités dans le temps, mesurables et

accompagnés d’une cible claire à atteindre.

6. Collectez régulièrement les nouvelles demandes auprès de vos

parties prenantes, identifiez de nouveaux insights pour détecter des
opportunités pour votre produit.

7. Les opportunités, votre mission, vos objectifs sont les fondations de

votre roadmap.

8. La roadmap est une intention pour atteindre vos objectifs, une

représentation graphique de votre stratégie et surtout un support
d’alignement.

9. La roadmap est co-construite avec vos parties prenantes et partagée

régulièrement pour refixer le cap.
Fixer le cap

Fixer le cap
52 53
2—

MODULE №2
Comprendre
le problème
et choisir
la solution

Une des dimensions clés du Product Management consiste

« La discovery est une à comprendre les besoins des utilisateurs et prendre des
décisions éclairées pour créer les meilleurs produits, c’est ce
discipline clé pour réduire qu’on appelle la discovery ! En d’autres termes, la discovery est

Comprendre le problème et choisir la solution

un processus de dérisquage qui, à travers un contact régulier
les risques et maximiser avec les utilisateurs, des ateliers et des outils adaptés, permet
de définir la meilleure solution pour répondre au besoin de
les chances de succès vos utilisateurs.

d’un produit. » Dans ce module, nous reviendrons sur les grands principes
de la discovery, avant de voir plus en détail comment
comprendre le problème, concevoir la solution et la tester
auprès de vos utilisateurs. Nous verrons également comment
— Teresa Torres faire des choix tout au long du processus grâce à des méthodes
de priorisation adaptées.

55
MODULE №2
CHAPITRE 5
Comprendre la
discovery
La discovery regroupe un ensemble d’activités permettant de
comprendre les comportements des utilisateurs, déceler leurs problèmes et
besoins, concevoir les solutions les plus adaptées et efficaces et tester ces
dernières. La discovery est essentielle car elle permet de limiter le risque
d’échec en aidant les équipes à décider ce que le produit devrait être.
Pourquoi mener de la discovery
La discovery permet de comprendre le problème à résoudre (Problem
Discovery) et concevoir la solution pour y répondre (Solution Discovery).
La discovery est décrite comme un « processus de prise de décision incluant
l’utilisateur tout au long de ce processus » par Teresa Torres, autrice du livre
Continuous Discovery Habits. L’objectif est de dérisquer les sujets avant de
prendre la décision de développer.
Il est important de vous assurer que vous êtes capable de répondre aux
Comprendre le problème et choisir la solution
questions fondamentales :
◉ Pourquoi ce problème est-il important ?
◉ Qui est concerné ?
◉ Comment convaincre la cible ?
◉ Quand intervenir ?
◉ De quoi la solution est-elle composée ?
N’attendez pas d’avoir le temps suffisant ou les outils parfaits pour vous
lancer. Mieux vaut peu que rien du tout ! Poser ces quelques questions vous
apportera déjà de précieux enseignements.
56
MODULE №2
Encadrer le processus de discovery
Le Lean Canvas pour poser vos hypothèses
Le Lean Canvas, mis au point par Ash Maurya, est un template intéressant
pour poser vos hypothèses à vérifier en discovery. Le Canvas aborde des
thèmes orientés sur le produit ou sur le marché :
◉ Les segments utilisateur : qui est la cible de votre produit ? Qui
sont vos potentiels early adopters ?
◉ Le problème et les alternatives : quel est le top 3 des problèmes
que vous cherchez à résoudre pour vos early adopters supposés ? Et
quelles sont les solutions existantes (alternatives) qui permettent
d’y répondre complètement ou partiellement aujourd’hui ?
◉ La proposition unique de valeur : la proposition de valeur est la
raison qui doit pousser vos prospects à devenir des utilisateurs. En
quoi résolvez-vous leurs problèmes ?
◉ Les solutions : quelles sont les trois grandes fonctionnalités qui
vont répondre aux problèmes de vos early adopters ?
◉ Les canaux : quels sont les canaux que vous pouvez utiliser pour
atteindre vos futurs utilisateurs ?
◉ Les métriques : quelles sont les métriques que vous allez mesurer
pour valider ou invalider vos hypothèses ?
◉ Les coûts : quels sont vos coûts fixes et variables ?
Comprendre le problème et choisir la solution
◉ Les revenus : quel est le modèle économique ? Comment allez-vous
gagner de l’argent ?
◉ Les avantages concurrentiels : qu’est-ce qui vous rend plus
performant que les autres pour traiter les problèmes que vous
avez identifiés ? (Connaissances techniques, carnet d’adresses,
marque…).
Téléchargez votre template de Lean Canvas
57
MODULE №2
Le double diamant pour penser problème et solution
Le Design Thinking est une approche itérative et empathique permettant
de faire émerger de nouvelles idées et de solutionner des problèmes.
Souvent représentée sous forme de double diamant, l’approche présente
une partie problème et une partie solution. Chaque diamant est découpé
en deux phases : une phase de divergence et une phase de convergence.
Le double diamant
Problème Solution
Exploration Défnition Idéation Conception
Le premier diamant, ou diamant du problème, regroupe l’ensemble des
activités qui permettent d’explorer et définir le problème utilisateur que l’on
cherche à résoudre. Il se compose d’abord d’une phase de divergence qui
consiste à collecter le plus d’informations possible au travers d’interviews,
observations, immersions (chapitre 6). Puis une phase de convergence en
réduisant le champ des possibles au problème que votre produit devra
résoudre. Vous ne pourrez pas répondre à tous les problèmes soulevés, il
vous faut donc faire des choix et prendre des décisions à cette étape avant
de pouvoir passer au deuxième diamant.
Comprendre le problème et choisir la solution
Le deuxième diamant, ou diamant de solution, regroupe quant à
lui l’ensemble des activités d’idéation et de conception (chapitre 7) qui
permettent d’identifier la solution à apporter au problème choisi. De
nouveau, vous devez travailler sur une phase de divergence pour explorer
toutes les solutions possibles permettant de répondre au problème, avant
de converger vers la solution que vous allez ensuite pouvoir tester auprès
de vos utilisateurs. Et encore une fois, vous allez devoir faire des choix.
Et si cela n’est pas concluant ? Alors, vous devez recommencer !
58
MODULE №2
Discovery Discipline pour apporter clarté et
alignement
Au-delà de cette approche du double diamant très connue, il existe
d’autres méthodes comme celle mise en avant par Tristan Charvillat et
Rémi Guyot dans leur livre Discovery Discipline. Partis du constat que le
double diamant était un bon point de départ — mais pas assez précis —
et que « prendre des décisions reste l’activité la plus importante et la plus
compliquée, car il est toujours plus confortable de diverger que de conver-
ger », Tristan et Rémi ont créé une méthodologie basée sur sept étapes :
F.O.C.U.S.E.D. :
◉ Frame pour définir l’ambition du projet de discovery ;
Test
◉ Observe pour identifier le cas d’usage principal à étudier ;
◉ Claim pour imaginer rapidement un positionnement pour la
fonctionnalité ;
◉ Unfold pour choisir les moments clés de l’expérience à adresser ;
◉ Steal pour réutiliser des solutions existantes qui fonctionnent ;
◉ Execute pour assembler et construire une solution fonctionnelle
pertinente ;
◉ Decide pour évaluer la qualité de la solution et décider ou non de la
développer.
Le framework F.O.C.U.S.E.D
Comprendre le problème et choisir la solution
Frame Observe Claim Unfold Steal Execute Decide
La méthode, testée chez PayPal et adoptée chez BlaBlaCar, vise à poser
un cadre clair forçant la prise de décision. Elle s’applique à différentes
organisations, différentes équipes et tout type d’initiative. La force de ce
cadre systématique et synthétique permet d’aller chercher toujours plus
d’impact.
59
MODULE №2

MODULE №2
Se lancer dans la discovery Matrice de maturité des sujets
de l’équipe Activation

Cadrer les besoins de discovery Problème clair

Avant de vous lancer dans la discovery, cadrez le niveau d’investissement
à allouer en fonction de la maturité du sujet, du niveau d’ambition, du
risque que vous êtes prêt à prendre et du temps que vous avez. Disposez- Solution
vous d’insights pour vous aider ? Cherchez-vous à doubler l’usage d’une Delivery DiJCovery
fonctionnalité ou simplement à améliorer le taux de rétention de quelques Créer un badge Vegan Implémenter un module
« Suggestion de la semaine »
pourcentages ? À quel point êtes-vous prêt à dégrader l’expérience utilisateur
pour lancer ce nouveau sujet ? Combien de temps avez-vous à y consacrer ?
Risque Risqu
Une fois ce cadrage réalisé, identifiez les activités à mettre en œuvre en faible élevé
vous aidant d’une matrice de maturité :
DiJCovery DiJCovere
◉ Le problème est clair et le risque est faible : vous pouvez développer rapide exploratoire
directement la solution et mesurer l’impact en production ; Optimiser le processus Proposer des résultats
de parrainage selon « Qui je suis »

◉ Le problème est clair, mais le risque est élevé : concentrez-vous

sur la Solution Discovery (chapitre 7) ;

◉ Le problème n’est pas clairement identifié et le risque est Problème )eu clair
faible : faites une phase de Problem Discovery courte pour vous
aider à préciser le problème et entamer rapidement la réflexion sur
la solution (chapitre 6) ;

◉ Le problème n’est pas clairement identifié et le risque est élevé :

faites de la discovery poussée. Réaliser la discovery en équipe

La discovery est essentielle pour identifier le bon problème et les

Comprendre le problème et choisir la solution

Comprendre le problème et choisir la solution

solutions qui y répondent. Si la tâche peut paraître ardue, rassurez-vous,
dans bien des cas, vous n’aurez pas à l’assumer seul·e. Vous mènerez les
nombreuses activités de discovery épaulé·e par les Product Designers et/
ou UX Researchers (présents dans votre équipe ou dans l’organisation).
Vous pourrez vous répartir les activités en fonction de vos compétences et
appétences. Peu importe qui des Product Managers ou Product Designers
sont les plus impliqués, le plus important est que les activités soient bien
réalisées et que les résultats soient bien partagés au reste de l’équipe.

En plus des Product Designers, d’autres profils peuvent également vous

aider à faire les choix requis tout au long du processus. N’hésitez pas à vous
appuyer sur votre Lead Technique et votre Product Marketing Manager
pour prendre les décisions. Leurs compétences vous permettront d’élargir
votre vision et de vous assurer de bien considérer les enjeux business, les
besoins utilisateur et les contraintes techniques.
60 61
MODULE №2

MODULE №2
Nos conseils
◉ Si vous manquez de temps, demandez-vous quelle discovery vous
pourriez faire avec le temps dont vous disposez.

◉ Pensez à documenter au fur et à mesure votre discovery en vous

appuyant sur des livrables synthétiques.

◉ La discovery n’est pas une validation scientifique ! Même si vous

avez réduit l’incertitude, vous devez vous fier à vos convictions et
confronter vos fonctionnalités à vos utilisateurs pour en mesurer
l’impact.

◉ Si vous faites face à des parties prenantes réticentes à l’idée de

perdre du temps avec de la discovery, rappelez-leur qu’il est très
coûteux de développer une solution qui ne correspond pas aux
besoins des utilisateurs. Investir dans de la discovery permet de
réduire ce risque.
Comprendre le problème et choisir la solution

Comprendre le problème et choisir la solution

62 63
MODULE №2
CHAPITRE 6
Creuser les
problèmes utilisateur
La discovery de vos opportunités vous demande de comprendre, creuser
et définir les problèmes utilisateur. Avec une approche orientée utilisateurs,
il s’agit de traiter des informations pour comprendre leur vie quotidienne,
leur contexte et découvrir ce dont ils ont besoin avant de vous intéresser
aux solutions.
Comprendre les problèmes
Mener des interviews utilisateur
Les interviews sont un bon moyen de collecter des informations
qualitatives qui vous permettent d’en apprendre plus sur les problématiques
utilisateur. Avant de réaliser ces interviews, vous devez constituer un panel
sur la base de critères d’éligibilité ou d’exclusion. La constitution de ce
panel peut être réalisée de plusieurs manières :
Comprendre le problème et choisir la solution
◉ Questionnez votre entourage, vos amis, vos collègues. Le test
Friends & Family est un moyen simple pour gagner du temps.
Cependant, il est risqué, car il induit de nombreux biais. En effet,
votre cercle proche n’est pas nécessairement représentatif de votre
cible d’utilisateurs ;
◉ Allez chercher les utilisateurs potentiels là où ils se trouvent :
réseaux sociaux, sites spécialisés, salons professionnels ou même
dans une gare ou un café… ;
◉ Ayez recours à des sociétés spécialisées dans le recrutement
de panel. Extrêmement efficaces, ces solutions sont payantes, mais
elles permettent de constituer un panel correspondant à une cible
précise.
64
MODULE №2
Une fois votre panel recruté, préparez votre guide d’interview et
organisez des entretiens individuels. Si vous êtes néophyte en la matière,
vous pouvez construire et suivre un script d’interview comme celui proposé
par l’orateur international Ash Maurya dans Running Lean. Le script vous
permet de confronter votre vision des problèmes avec celle des interviewé·es
et d’identifier les solutions existantes qu’ils utilisent le cas échéant.
Lors d’un entretien, ne cherchez pas à vendre votre produit, vous êtes là
pour apprendre ! Passez chaque problème en revue et cherchez à évaluer son
importance aux yeux du prospect en faisant attention aux pièges suivants :
◉ Décelez le vrai du faux : si un·e interviewé·e vous dit qu’il·elle ren-
contre régulièrement un grave problème, mais qu’il·elle ne cherche
pas activement une solution, peut-être qu’il·elle exagère l’ampleur
du problème, inconsciemment ou non, pour vous faire plaisir ;
◉ Ne généralisez pas trop vite : les interviews utilisateur vous
donnent des signaux, mais seules les données quantitatives
permettent d’évaluer le comportement de l’ensemble de vos
utilisateurs.
Compléter avec l’observation, l’immersion et le
quantitatif
Les interviews utilisateur vous aident à collecter des informations
précieuses, mais il faut garder en tête que ce que les utilisateurs disent en
interview ne correspond pas toujours exactement à ce qu’ils font dans la
réalité.
C’est pourquoi il est pertinent de compléter vos interviews par de
Comprendre le problème et choisir la solution
l’observation pour analyser le comportement et le contexte de votre cible.
Nous vous conseillons par exemple de passer une journée auprès du service
client ou sur le terrain auprès de vos utilisateurs. C’est un moyen facile à
mettre en place pour récolter des retours.
L’immersion est aussi intéressante pour vous plonger dans l’expérience
de vos utilisateurs. Testez vous-même votre produit en situation, il sera
ainsi plus aisé de détecter les problèmes liés au contexte d’utilisation.
Enfin, vous pouvez appuyer vos hypothèses avec des éléments
quantitatifs. L’analyse de votre produit peut vous permettre de compléter
la compréhension des problèmes avec des données d’usage. Vous pouvez
également proposer à vos utilisateurs de donner leur avis sur les problèmes
que vous avez identifiés dans les interviews en envoyant un questionnaire à
une cible plus large. Les statistiques quantitatives sont un bon moyen pour
compléter vos apprentissages.
65
MODULE №2

MODULE №2
Formaliser les apprentissages Le persona simplifié
(template à télécharger p.73)

Dès lors que vous avez dégagé une multitude d’informations, vous pouvez
extraire et formaliser les enseignements pour en synthétiser l’essentiel. Nom + type d’utilisateur

Pour ce faire, plusieurs outils existent pour vous aider à converger vers des
apprentissages exploitables. Ses motivations

Ce qui infuence ses choii

Les personas

Un persona est un utilisateur type fictif, basé sur des données utilisateur Ses 3-ust-ations

dont il est censé représenter et synthétiser les objectifs et les motivations.

Pour créer un persona, on utilise les données représentant les utilisateurs, Ses tops 3 challenges/problèmes et ce que ça lui « coûte »

récoltées à travers les entretiens et les observations. Vous pouvez formaliser

différents types de persona :

◉ Le persona primaire : celui pour lequel le produit est construit et

Outcome

dont les besoins et objectifs doivent être satisfaits ; Ce que serait sa _ie bperso ou proY sans ces problèmes

◉ Le persona secondaire : celui qui partage des besoins et objectifs

avec le persona primaire, mais qui a néanmoins des caractéristiques
propres, non prioritaires ;
Appétence technologique Fréquence d’utilisation Équipements

◉ Le persona négatif (ou anti-persona) : celui qui représente un non-

utilisateur, qui n’est pas notre cible et qui sera déçu par le produit.

Vos personas permettent de mieux comprendre votre cible ainsi que

les problèmes qu’elle rencontre. Ils facilitent l’accès aux informations sur
les utilisateurs et vous aident à faire les bons choix lors des ateliers de
conception.
Attention toutefois, le persona a le défaut d’être un peu statique, parfois
Comprendre le problème et choisir la solution

Comprendre le problème et choisir la solution

même caricatural. Comme Fabrice Des Mazery l’évoque dans son livre
Responsables, les personas peuvent rapidement devenir des stéréotypes
dictés par des préjugés et chargés de détails inutiles à la prise de décision.
Pour pallier cette utilisation néfaste, rappelez-vous que les utilisateurs ont
des expériences dynamiques et des motivations qui sont contextuelles,
c’est-à-dire qu’ils peuvent vouloir quelque chose dans un certain contexte
et être complètement contre dans un autre. C’est pourquoi le persona doit
être combiné avec d’autres représentations comme les parcours utilisateur
ou les expériences map, de manière à illustrer leurs différentes motivations,
émotions et attitudes face à des problématiques à différents moments de
sa vie.

66 67
MODULE №2

MODULE №2
L’empathy map L’empathy map
(template à télécharger p.73)
L’empathy map (carte d’empathie) est un outil collaboratif permettant
de visualiser ce que vous savez à propos d’une catégorie d’utilisateurs de Qu’est-ce qu’il it ? Qu’est-ce qu’il ±knjk ?
votre produit. L’objectif est de partager une vision commune des besoins
utilisateur.
Ce quadrant contient ce que l’utilisateur Ce quadrant contient ce que pense

dit à voix haute lors d’une interview l’utilisateur tout au lon„ de l’expérience.

Vous pouvez l’utiliser lors de vos sessions d’observation ou bien en ou d’une étude d’utilisabilité. Idéalement, Il est possible d’avoir le même contenu

atelier pour synthétiser les résultats de votre recherche utilisateur. Elle se il contient des citations textuelles et dans dit et pense. Cependant, portez

compose de quatre quadrants : directes issues de la recherche. une attention particulière à ce qu

les utilisateurs pensent, mais vous

voudrez peut-être pas exprimer

◉ Ce que l’utilisateur dit : vous listez ici ses verbatims, c’est-à-dire (par politesse par exemple).

les éléments que votre utilisateur exprime à voix haute ;

◉ Ce que l’utilisateur pense : ici, vous portez une attention

particulière à ce qu’il n’exprime pas directement (par timidité ou
politesse par exemple) ; Qu’est-ce qu’il fait ? Qu’est-ce qu’il ukjjknt ?

◉ Ce que l’utilisateur fait : ce quadrant représente ses actions Ce quadrant représente les actions Ce quadrant représente l’état

entreprises ; entreprises par l’utilisateur. D’après

la recherche, que fait physiquement

émotionnel de l’utilisateur. Pensez à

utiliser des adjectifs et une courte

l’utilisateur ? Comment l’utilisateur phrase pour expliquer le contexte.

◉ Ce que l’utilisateur ressent : vous détaillerez ici son état s’y prend-il ? Qu’est-ce qui l’inquiète ? Le passione ?

émotionnel à travers des adjectifs ou phrases courtes (qu’est-ce qui

l’inquiète ? Le surprend ? Le passionne ?).

L’empathy map peut être utilisée en support lors de votre recherche

utilisateur, notamment pour prendre des notes lors de vos sessions
Comprendre le problème et choisir la solution

Comprendre le problème et choisir la solution

d’observation sur le terrain ou alors en atelier en interne avec vos parties
prenantes et afin de partager votre compréhension de votre cible. Dans ce
cas, l’empathy map vous servira ensuite de base pour la création de vos
personas.

L’experience map

L’experience map (carte de l’expérience) permet de visualiser

l’expérience globale d’un utilisateur qui veut accomplir un but. Elle ne se
limite pas à l’utilisation de votre produit en particulier, mais décrit de façon
chronologique l’ensemble des étapes et comportements de l’utilisateur tout
au long de son parcours.

68 69
MODULE №2

MODULE №2
Experience map d’un utilisateur de Thiga Eats Une fois les différentes étapes identifiées, l’experience map permet
de mettre en avant les comportements utilisateur à chaque étape ainsi
que les points de douleurs et éventuelles opportunités d’amélioration de
OWZVYU `YUUY]W[U Vg[]WUVgU[W[aU a`Y[]U l’expérience.

     
  




Téléchargez vos templates de persona, d’empathy map
et d’expérience map.
 )1 (  6 h ƒ
€1 ‰  )1 (  6 € €   ž 1

 1˜


   

A     
1‰  6

:K1  


    1 
6
6 «
Préciser le problème
 )€11 1    
Vous avez creusé les problématiques et formalisé des apprentissages ?
Il s’agit désormais de décrire simplement ces problèmes pour cadrer
  Ï    1 h 
 la recherche de solution. Pour cela, nous vous suggérons d’utiliser la
1
4
,1  
    
 :(    formulation « Comment pourrait-on… ? » (How Might We). En effet, cette
6

 »

 formulation est assez large pour ne pas orienter sur le choix de la solution

€

et se concentrer sur le résultat attendu par l’utilisateur. La précision du
problème doit avant tout :
 :   6
^     64

     )1 (  6
1  ◉ Ne pas présupposer de solution ;
 
1   
  
   6 
◉ Souligner le problème que vous cherchez à résoudre ;
 )
 

 
 Û  ä ◉ Préciser la cible utilisateur.
)
   p1( ‰(A
 6

 ä
 )


    (
Comprendre le problème et choisir la solution

Comprendre le problème et choisir la solution

1    P
 AK1  
   6 G
Un problème identifié par l’équipe Activation

        
1
 
1  6  6 
Le problème peut être formulé de la façon suivante : « Comment
 1 
K16
pourrait-on réduire les déchets générés par une commande ? »
 
1 
1
 Û  A

6
 1 1


 ^(

 61W
C  6€   1
(  
T
(

 z
  6 1
 1i

O

 1  p1 h
 1

  1  
 
 6

 1

70 71
MODULE №2

MODULE №2
Nos conseils
◉ Avant de vous lancer dans les activités de discovery pour creuser
un problème, vérifiez que le sujet n’a pas été déjà étudié par une
autre équipe et faites une revue des insights disponibles en lien
avec le sujet.

◉ Lorsque vous menez des interviews utilisateur, privilégiez les ques-

tions ouvertes commençant par « quel », « qui », « quand », « pour-
quoi » ou « comment » afin de ne pas influencer les réponses.

◉ Afin de vous assurer que vos personas ne tombent pas dans

l’oubli après avoir été créés, utilisez-les à chaque atelier et chaque
restitution pour introduire les sujets.
Comprendre le problème et choisir la solution

Comprendre le problème et choisir la solution

72 73
MODULE №2
CHAPITRE 7
Imaginer, concevoir
et choisir des
solutions
En Design Thinking, générer un grand nombre de solutions innovantes
pour un problème donné est facilité par l’utilisation d’ateliers. Ils reposent sur
la conviction que l’intelligence collective, par opposition à la conception en
chambre de façon isolée, est le meilleur moyen de faire émerger des solutions
pertinentes et innovantes. C’est sur ces fondations que vous cherchez à faire
émerger des solutions pour répondre à vos problèmes ciblés.
Les ateliers d’idéation et de co-
conception
Les ateliers d’idéation
Comprendre le problème et choisir la solution
Un atelier d’idéation est une activité consacrée à la génération d’idées
nouvelles pour répondre à une problématique posée dans un contexte
précis. L’objectif est de faire émerger un maximum d’idées de solutions
pouvant répondre au problème identifié. Pour ce faire, partez de votre
problème formulé en « comment pourrait-on… ? » (chapitre 6) et appuyez-
vous sur différentes méthodes et techniques pour faire émerger les idées.
74
MODULE №2
Thème d’un atelier d’idéation de l’équipe Activation
« Comment pourrait-on réduire les déchets générés par une
commande ? »
Voici quelques exemples d’ateliers d’idéation :
Le brainstorming
Le brainstorming est un atelier de groupe utilisé pour générer un maximum
d’idées autour d’une problématique en un temps limité. Il implique un processus
de réflexion libre et spontanée où tous les membres du groupe sont encouragés
à proposer des idées, dans un environnement collaboratif et ouvert.
Cet atelier, facile à mettre en place, est souvent un bon point de départ
pour l’idéation. Mais il faut penser à certaines règles clés qui permettent
de mettre à l’aise les participants et d’assurer le succès de l’atelier. Avant de
commencer, vous pouvez rappeler les points suivants :
◉ Abstenez-vous de juger : laissez chacun s’exprimer sans émettre de
jugement sur les idées qui émergent afin de ne pas brider la parole ;
◉ Encouragez les idées excentriques : ne posez aucune limite à la
créativité, faites abstraction des contraintes techniques ou du coût
éventuel des solutions proposées ;
◉ Restez concentré·e sur votre sujet : faites attention à ne pas laisser
l’atelier partir dans tous les sens en gardant le cap sur le sujet principal ;
Comprendre le problème et choisir la solution
◉ Construisez sur les idées des autres : prenez en compte les idées
des autres en les intégrant à vos propres réflexions. Cela permet de
renforcer la collaboration et la créativité ;
◉ Répartissez la parole : une seule conversation à la fois, encouragez
les participants à se laisser parler et à s’écouter ;
◉ Visez la quantité : cherchez ici à faire émerger le plus d’idées
possible, la phase de convergence permettra ensuite de faire un
choix entre ces idées ;
◉ Soyez visuel : si vous êtes en présentiel, utilisez des Post-its et
un tableau. Si vous êtes à distance, assurez-vous d’utiliser un outil
collaboratif pour noter les différentes idées.
75
MODULE №2

MODULE №2
L’impact mapping Impact mapping de l’équipe Activation
L’impact mapping est un format facile à concilier avec une approche
orientée objectifs. Inventé par Gojko Adzic, l’impact mapping incite les

Lancer une nouvelle ofre veean

contributeurs à se concentrer sur l’identification de fonctionnalités qui

Améliorer la pertinence de la

Proposer des résultats en

Quelle action devons-nous

Développer un module de
sueeestion de la semaine
fonction de « Où je suis »
permettront d’atteindre un objectif bien défini. Pour ce faire, vous devrez
en amont de l’atelier choisir l’objectif sur lequel vous souhaitez réfléchir.

mettre en place ?

eéolocalisation
Lors de l’atelier :

Initiatives
1. Complétez avec les participants les impacts, c’est-à-dire les
comportements attendus de vos différents acteurs, les usages que
vous souhaitez générer ;

2. Complétez les initiatives à mettre en place pour générer ces

comportements. Ces dernières vous permettent d’identifier
clairement vos fonctionnalités ;

En facilitant les recherches de

En proposant une o~re vewan

adresses dans son quartier
En proposant de nouvelles
utilisateurs ciblons-nous ?
3. En fin d’atelier, priorisez les initiatives et fonctionnalités avec vos

restaurants à proximité
Quel comportement des
participants en attribuant un indicateur d’impact (fort, moyen,
faible).

Impacts

Consommateur responsable
Qui va nous permettre

Consommateur vewan
d’atteindre l’objectif ?

Consommateur local
Comprendre le problème et choisir la solution

Comprendre le problème et choisir la solution

Acteurs

souhaiterons-nous
faire évoluer le

depuis la liste
conversion
Pourquoi

produit ?
Objectif

+25% de
76 77
MODULE №2

MODULE №2
Les ateliers de co-conception Story map «Proposer des résultats
selon où je suis»
Ces ateliers permettent de matérialiser une idée de manière plus détaillée
en parcours, écrans, supports… Ils peuvent porter sur l’analyse du besoin et
donc la définition des fonctionnalités, ou encore la création de maquettes.

le restaurant
du service
Évaluation

en favoris
Mettre
Thème d’un atelier de co-conception
de l’équipe Activation

« Comment pourrait-on mettre en avant les offres écoresponsables

lMimpact positif sur

lMenvironnement
Mettre en avant
Payer sur place
ma commande

«À emporter»
dans la liste des résultats ? »

pour le mode
Finaliser
Voici quelques ateliers de co-conception :

Indiquer la distance
Le story mapping

Proposer un mode
par rapport à moi
un restaurant

«À emporter»
Choisir7
Ce format d’atelier est très bien adapté à la création d’un nouveau
produit et peut également servir à concevoir une nouvelle fonctionnalité
assez complexe. En effet, le story mapping permet de contextualiser les
fonctionnalités en lien avec un parcours utilisateur et de prioriser les idées.
Aussi, à l’issue de cet atelier, vous arriverez à dessiner une première version
réaliste de votre produit ou fonctionnalité. En une ou plusieurs séances :

Sauve–arder mes
proximité sur une

restaurants sous
un restaurant

préférences de
restaurants à

forme de liste
Visualiser les

Visualiser les

recherche
Chercher
1. Positionnez sur l’axe horizontal l’ensemble des étapes du parcours

carte
de l’utilisateur. Si vous avez plusieurs personas, réalisez une story
map par persona pour refléter les parcours différents ;
Comprendre le problème et choisir la solution

Comprendre le problème et choisir la solution

2. Les participants imaginent et discutent les fonctionnalités pour
chaque étape en faisant abstraction des contraintes ;

Saisir mon adresse

max. de recherche
Défnir un raaon
Géolocalisation
ma position

de livraison
Indiquer
3. Ils ordonnent ensuite les différentes fonctionnalités selon leur
priorité, jusqu’à converger vers une version intégrant uniquement les
fonctionnalités nécessaires pour répondre à votre problématique.

should

could
parcours
utilisateur

must
Téléchargez votre template de story map

78 79
MODULE №2
Le tri de carte
Le tri de carte est une méthode visant à construire l’architecture de
l’information d’un site ou d’une application, en impliquant ses utilisateurs.
Elle a pour but de catégoriser le contenu d’un produit selon une structure
cohérente et rapidement compréhensible par ses utilisateurs.
La méthode du tri par cartes comporte trois étapes :
1. Inventaire de l’ensemble des fonctionnalités et contenus du
produit : chacune de ces fonctionnalités est reportée sur une carte.
Les cartes peuvent être représentées sur un support papier ou saisies
sur un outil en ligne ;
2. Présentation des cartes aux utilisateurs : il leur est demandé de
regrouper les différentes cartes en groupes cohérents selon leur point
de vue ;
3. Analyse des résultats : à l’issue de l’atelier, les résultats sont analysés
manuellement ou en ligne avec l’outil utilisé.
Notez tout de même qu’un tri par cartes ne permet pas de définir une
architecture de l’information définitive. Il fournit une base qui doit être
complétée en fonction de la stratégie Produit, des limitations techniques et
des exigences d’utilisabilité.
Comprendre le problème et choisir la solution
80
MODULE №2
L’organisation des ateliers
Pour préparer et animer ces ateliers, vous allez travailler main dans la
main avec vos Product Designers. Vous devez alors définir ensemble les
rôles et responsabilités de chacun pour une organisation optimale : Qui
prépare l’atelier ? Qui l’anime ? Et qui facilite les échanges ?
Choisir les participants
Pour bien préparer un atelier, il faut avant tout bien choisir les participants.
Un casting pluridisciplinaire permet d’avoir plus de richesse dans les idées.
Selon les sujets, vous pouvez faire intervenir des représentants de la voix
des utilisateurs (customer success, service client…), des représentants des
clients (équipe commerciale, Product Marketing Manager), des experts du
sujet traité (service juridique, data…), ou encore des profils techniques
(développeurs).
Nous préconisons dans la mesure du possible de ne pas faire participer
les leaders, car leur présence peut influencer les participants (autocensure
par exemple). Si votre top management tient absolument à contribuer
aux ateliers, proposez-leur d’intervenir en introduction afin de rappeler
les enjeux. Vous pouvez aussi leur proposer de prendre connaissance des
résultats en fin d’atelier.
Préparer et animer l’atelier
En amont de l’atelier, communiquez sur l’objectif et l’agenda. Cela permet
aux participants de se projeter sur le déroulé et de préparer des éléments
en avance. Si vous faites participer des personnes peu familières avec les
Comprendre le problème et choisir la solution
pratiques Produit, prenez le temps nécessaire pour leur expliquer les grands
principes de la discovery. C’est aussi un bon moyen de démontrer la valeur de
l’atelier en question afin de garantir leur participation constructive.
Pendant l’atelier, pensez à :
1. Démarrer en présentant le contexte et la problématique à résoudre ;
2. Minuter les différentes séquences et garder le rythme afin de
terminer l’atelier avec un résultat actionnable ;
3. Remercier vos participants en fin d’atelier pour le temps et
l’énergie qu’ils ont consacrés, communiquer le compte rendu et les
prochaines étapes.
81
MODULE №2

Atelier en présentiel ou distanciel ?
Le présentiel facilite le partage des points de vue et le développement
de nouvelles idées (pendant l’atelier et lors des pauses). En revanche, il
génère une perte de temps post-atelier pour retranscrire les résultats.
Avec le distanciel, les introvertis peuvent se sentir plus à l’aise et les
extravertis être plus inclusifs. Mais il génère des frictions dues à des
problèmes de connexion ou d’accès aux outils.
Dans tous les cas, nous recommandons d’éviter les formats mixtes
— où une partie des participants est en présentiel et l’autre
à distance — pour assurer le bon déroulement de l’atelier.
MODULE №2
Nos conseils
◉ Facilitez les ateliers avec des outils visuels. En présentiel ou
distanciel, les tableaux blancs, Post-its et canvas permettent
d’aider à organiser les discussions, hiérarchiser les idées et
favoriser la collaboration.
◉ Limitez le nombre de participants afin de générer suffisamment
d’idées tout en laissant à chacun l’opportunité de s’exprimer.
◉ Soyez vigilant·e·s sur la répartition des temps de paroles, assurez-
vous que les plus introvertis partagent leurs idées et que les plus
extravertis n’accaparent pas la parole de façon démesurée.

Retenir les solutions à tester

Les ateliers vous permettent donc d’identifier plusieurs pistes de solu-

tions et de commencer à les prioriser avec les participants. Encore faut-il
que ces solutions aient un impact sur les objectifs à atteindre (viable),
techniquement réalisables (faisable), apportant de la valeur à l’utili-
sateur (utilisable) et n’introduisant pas d’usage négatif (responsable).

Choisir la solution

Utilisable
(UX)
Comprendre le problème et choisir la solution

Comprendre le problème et choisir la solution

Viable Faisable
(4%"01"") ()

Responsable
($%")

N’oubliez pas de prendre en compte vos contraintes, qu’elles soient

RGPD, éthiques, technologiques, légales ou financières. Vous devez ensuite
tester les solutions retenues. (chapitre 8).
82 83
MODULE №2

MODULE №2
CHAPITRE 8 Smoke test de l’équipe Activation

Tester des pistes Afin de tester l’appétence des utilisateurs, l’équipe a ajouté une fausse
option de recommandation de restaurants selon leur profil dans les

de solutions
critères de recherche et mesuré le taux de recherche avec cette
option.

9:41 9:41
L’objectif principal de la discovery est de réduire les risques de
développer une solution qui ne correspond ni aux attentes de vos
utilisateurs ni aux objectifs de votre entreprise. Tester vos pistes de
solutions, en les confrontant aux réactions de vos utilisateurs et à la réalité
du terrain, vous permet de réduire davantage le risque d’échec avant de
vous lancer dans les développements.

Les différents tests

Tester la proposition de la valeur

Lorsque vous commencez à avoir des pistes de solutions, et avant même

de concevoir un prototype, vous pouvez vérifier que la proposition de
valeur de votre fonctionnalité est bien comprise. Un test de proposition de
valeur permet de valider l’attractivité de votre fonctionnalité en utilisant
Comprendre le problème et choisir la solution

Comprendre le problème et choisir la solution

des moyens peu coûteux comme le smoke test (test de fumée).
Le smoke test consiste à faire comme si la fonctionnalité existait déjà et
à évaluer les réactions des utilisateurs. Il peut prendre la forme d’un faux
bouton, d’une publicité décrivant de manière synthétique votre proposition
de valeur ou d’une fausse landing page. On parle également de test de fake
door (fausse porte), car la fonctionnalité n’existe pas vraiment et il n’est
pas possible de l’utiliser réellement une fois la porte du test passée. En
évaluant le pourcentage des utilisateurs qui cliquent sur le bouton, visitent
la landing page ou laissent un feedback, vous pouvez avoir une estimation
du succès futur de cette fonctionnalité.
Attention toutefois, car les tests de proposition de valeurs tels que les
smoke tests peuvent générer de la déception pour vos utilisateurs lorsqu’ils
se rendent compte que la solution promise n’est pas disponible. Veillez à ne
pas rompre la confiance de l’utilisateur ou abîmer l’image de votre produit.
Portez une attention particulière au message que vous faites passer sur les
interfaces de ce test. Plutôt que de feindre une erreur technique, mieux vaut
être clair avec l’utilisateur en lui expliquant que la fonctionnalité est prévue
dans un futur proche et en l’invitant à donner son avis.

84 85
MODULE №2
Tester l’utilisabilité de la solution
Le test de prototype permet de vérifier si votre solution est facile
à utiliser et à comprendre. Il est donc très utile pour savoir comment
améliorer l’expérience utilisateur de votre fonctionnalité.
Pour réaliser ce type de test, vous devez travailler avec les Product
Designers pour concevoir un prototype à partir de maquettes interactives.
Le prototype peut être plus ou moins détaillé et fidèle à la réalité de la
fonctionnalité envisagée. La réalisation du test se fait lors d’une série
d’entretiens avec les utilisateurs pendant lesquels vous observez leur
comportement, recueillez leurs impressions et leurs actions et enfin notez
leurs ressentis.
À l’issue d’un test sur prototype, vous obtenez les bons signaux pour
vous permettre de dire si vous avez atteint le Problem/Solution Fit, c’est-
à-dire si la solution semble répondre au problème. Attention, ces signaux
vérifient que la solution est bonne sur le papier, mais ils ne permettent pas
d’assurer que la réalisation satisfera vos utilisateurs en situation réelle. Il
est donc important de ne pas tirer de généralités trop hâtives des résultats
obtenus, et de les compléter en exposant la valeur et en mesurant les
comportements réels.
Tester en livrant la valeur
Le MVP
Le MVP (Minimum Viable Product, Produit Minimum Viable) a pour
but d’apprendre en testant la valeur plutôt que de livrer un produit ou une
fonctionnalité. La démarche MVP permet de détecter le Product/Market Fit,
Comprendre le problème et choisir la solution
c’est-à-dire que le produit ou la fonctionnalité répondent bien aux attentes
du marché.
Le MVP repose sur la boucle Build-Measure-Learn de la méthodologie
Lean Startup. Ce processus itératif sert à tester le besoin et l’engagement
sur une cible restreinte, les early adopters, en fournissant le minimum de
valeur. Il ne vise pas tout de suite la cible plus large appelée la early majority
ou majorité précoce.
86
MODULE №2
Les différentes cibles utilisateur
(Diagramme de Geoffrey A. Moore)
Innova- Early Majorité Majorité Retardataires
teurs adopters précoce tardive
Penser MVP, c’est avoir l’état d’esprit Think big, start small ! (Pensez
en grand, commencez petit), par opposition à la philosophie Get Big Fast
(Devenir grand rapidement) consistant à lancer rapidement un produit
industrialisé, sans en avoir validé au préalable l’appétence qu’en auraient
les utilisateurs. Même Facebook, qui s’adresse aujourd’hui au grand public,
a commencé par cibler les étudiants de Harvard avant de s’élargir à d’autres
universités américaines puis aux lycées, etc., en adaptant son produit à
chaque occasion.
Pour réaliser votre test MVP, vous pouvez aller jusqu’à mettre à
disposition une version très manuelle de vos fonctionnalités. Appelé Turc
mécanique, Magicien d’Oz ou Test concierge, ces tests visent à simuler
manuellement l’expérience finale tout en donnant l’impression d’une
forme d’automatisation. Ainsi, la valeur est livrée grâce à l’humain et non
le code. Par exemple, Airbnb a testé un site Web sur lequel les fondateurs
proposaient leur propre appartement à la location. Un autre exemple serait
un chatbot, en réalité opéré par un humain avec des scénarios de réponses
Comprendre le problème et choisir la solution
prédéfinies.
Le bêta test
Plus adapté à un produit ou une fonctionnalité majeure, le bêta test
consiste à sortir un périmètre minimum avec de potentielles instabilités ou
un périmètre incomplet pour pouvoir récolter des feedbacks et améliorer
en fonction de ces retours. La version bêta peut être ouverte sur inscription
ou non à des utilisateurs externes ou réalisée en interne sur une population
d’utilisateurs plus familiers (collaborateurs, communauté d’utilisateurs
ambassadeurs…).
87
MODULE №2

MODULE №2
Le no-code
Cadrage d’un test de l’équipe Activation
Le no-code a explosé en 2020 et désigne un ensemble d’outils, voire
une tendance, qui vise à créer un produit numérique sans avoir de Feuilled’expérimentation 
  ifA
connaissances en langages de programmation. Les outils no-code ont tous
la même démarche : rendre abstraite la complexité du développement NƒI  - •ƒƒ,*I, *  0*Žif0
(programmatique, hébergement, sécurisation). Ainsi, il est possible 0Ž 1* 3
en quelques jours d’avoir un produit complètement fonctionnel sans
développer, vous permettant ainsi de tester et d’apprendre auprès de vos
($'&'%$ % $! -3 10 , ) *1
utilisateurs sans trop engager de dépenses de développements. Comet, &%$'! %!' !% &$'!
Prello, Qonto ou encore Payfit sont quelques exemples de produits opérés   &%$%$ %%$ !
'#%$' %& ! !"
avec cette démarche dite no-code. % $!

T I  M bP=J;

FCA?=;>EP
;J;P ?EB: \'V% % pnln P
Comment mener des tests ? 77?E658HHHD bP;A=J;

¿1 0Â1 * À ½Ž *Ž

»¹ ¸µ'%$ % %' %
‰•3*,Ž
To test or not to test I ‡3Žƒ *‚
 !% $¢$% % $%¤%$¤©

, ‘ ¹  ! #!'› š¤%¬

F
n?;=wJP  %% — ¥
Les tests de solutions peuvent se révéler coûteux et chronophages, ;t
?AP
„P !!%$ —% % $¢$%
' ¡% %$%$ %ž
surtout lorsque vous avez en tête de tout tester. Pour limiter le temps passé =7?„?77n7J —% ! ™''! %
PD $%'' %$²
et le coût engendré, il vous faut donc identifier les éléments qui doivent ¡%® &'¡!%
être testés auprès des utilisateurs et ceux qui peuvent être directement
développés. Certains sujets peuvent ne pas nécessiter de test. C’est par  Ž á PŽ• ,* 3 ,
exemple le cas de développements obligatoires liés à des contraintes I  1••â
FÛ JPJÙ7 n7× 30% % !%$ %ff% %
techniques ou lorsque votre solution est déjà clairement identifiée, peu Õ ;„?×?Ô $%¤%$¤% $%&!% % #!%
=J;?7  !% $¢$%
coûteuse en développement et peu risquée. En revanche, plus les solutions ;A=J;?=7?
sont complexes, innovantes ou différentes de ce que vous avez l’habitude l˄7lÊPÖD
de faire, plus un test s’impose. C’est à vous de juger à quel point il est
nécessaire de tester une solution avant de la développer (en fonction de la
Comprendre le problème et choisir la solution

Comprendre le problème et choisir la solution

difficulté à revenir en arrière, les effets de bords possibles). ÀŽ ƒ0Ž½0 1 I1

Définir l’hypothèse et les critères de succès

Vous devez commencer par définir les hypothèses que vous cherchez
à valider ou réfuter en partant des pistes de solutions identifiées à l’issue
de votre discovery. Ensuite, pour valider ou rejeter ces hypothèses, il
est nécessaire de définir un ou des critères de succès, dont un seuil de
performance à partir duquel on peut considérer que les hypothèses sont
validées. Pour vous aider à définir ce seuil, appuyez-vous sur les données
dont vous disposez ou choisissez une valeur en dessous de laquelle vous ne
souhaitez pas investir en développement.
Si les hypothèses sont mal définies ou trop généralistes, les critères de
succès peu ou pas pertinents et les seuils de performance choisis au doigt
mouillé, alors l’analyse de la performance de la solution en devient erronée.
Finalement, l’ensemble de la démarche peut faire perdre plus de temps
qu’elle n’en fera gagner. Pour vous aider à définir ces éléments correctement,
pensez à vos objectifs (chapitre 2).

88 89
MODULE №2
Réaliser les tests
En fonction de l’hypothèse que vous faites, vous allez pouvoir choisir
le test le plus adapté et générer des données quantitatives. Toutefois,
rien ne vous empêche ensuite de conduire des entretiens utilisateur afin
de comprendre pourquoi vous avez eu tel ou tel résultat. Allier données
quantitatives et qualitatives vous permet de mieux comprendre où se situe
la valeur pour vos utilisateurs et vous donne des pistes sur comment itérer
par la suite.
Analyser les résultats
Une fois les données du test récoltées, demandez-vous si les seuils de
succès que vous avez définis sont atteints. S’ils ne le sont pas, considérez
alors que le test réfute les hypothèses et qu’il est nécessaire de partir sur
d’autres pistes de solutions. Mais pas de panique ! Gardez en tête que
l’objectif est d’apprendre.
En cas d’échec total, vous n’aurez pas perdu votre temps ni votre budget :
comprendre que l’on fait fausse route suffisamment tôt minimise les pertes.
Enfin, il est également possible que vous validiez votre piste de solution,
mais aussi que vous releviez de nouvelles hypothèses à tester. Dans ce cas,
vous pouvez juger nécessaire d’enclencher un nouveau test.
Comprendre le problème et choisir la solution
90
MODULE №2
Nos conseils
◉ Ne vous attachez pas personnellement aux solutions que vous
testez. Bien que cela puisse sembler décourageant de rejeter une
solution sur laquelle vous avez travaillé pendant plusieurs jours,
voire plusieurs semaines, restez objectif·ve ! Évaluez les résultats
du test en fonction de vos critères de succès préétablis pour
décider si vous devez ou non implémenter la solution.
◉ Si vous décidez de ne pas mener de test de solution, vous pouvez
utiliser d’autres outils pour limiter les risques et progresser en
apprenant et en itérant. Par exemple, vous pouvez adopter une
stratégie de déploiement progressif en ouvrant une fonctionnalité
à un petit nombre d’utilisateurs en avant-première, avant de tester
progressivement la montée en charge.
◉ Dans certains contextes, les enjeux liés à l’image de marque ou
aux contraintes de sécurité peuvent rendre difficile la réalisation
de smoke test ou MVP qui proposent une fonctionnalité partielle.
Dans ce cas, privilégiez les tests de prototypes pour réduire les
risques liés à vos idées de solutions.
Comprendre le problème et choisir la solution
91
MODULE №2

MODULE №2
CHAPITRE 9 ◉ L’acquisition de nouveaux utilisateurs ;

◉ L’activation et la rétention de ces nouveaux utilisateurs ;

Garder le focus avec ◉ Etc.

la priorisation Ensuite, évaluez vos opportunités sur les critères en attribuant une
note, par exemple de 1 à 100. Le score obtenu vous aide à prioriser les
opportunités ayant le score le plus haut.
Prioriser c’est choisir le focus sur lequel l’équipe va concentrer son
effort. Il est important de ne pas prioriser sur la base unique de ses propres
intuitions ou celles des leaders, mais de le faire avec méthode.
Impact scorecard de l’équipe Activation

Critère* 1. 2. 3. 4. Score

Pondération 30% 20% 20% 30% 100%

Prioriser les opportunités Proposer des

résultats
80 70 50 70 270
Lorsque vous construisez votre roadmap (chapitre 4), vous devez en fonction
prioriser les opportunités identifiées afin d’orienter votre effort de discovery. d’où je suis
Voici quelques méthodes pour vous permettre de faire des choix éclairés en
vous posant les bonnes questions et afin de prendre les bonnes décisions. Optimiser le
processus de 50 50 40 15 155
parrainage
L’impact scorecard
Améiorerla
Vous devez prioriser les opportunités qui auront le plus d’impact sur vos perti-
60 30 10 30 130
objectifs (chapitre 2). Pour chaque opportunité, évaluez comment elle peut nence de la
Comprendre le problème et choisir la solution

Comprendre le problème et choisir la solution

contribuer à vous rapprocher de votre cible. Au-delà de l’impact sur votre géolocalisation

objectif, vous pouvez aussi choisir plusieurs critères d’évaluation. L’impact

scorecard vous permet de mesurer l’impact selon plusieurs critères Proposer des
pondérés. Dans un premier temps, identifiez les critères et les pondérations résultats en
30 40 20 10 100
avec les parties prenantes. Il peut s’agir d’un impact pour l’entreprise ou fonction de
qui je suis
pour l’utilisateur. En voici quelques exemples non exhaustifs :

◉ Le chiffre d’affaires ou les parts de marché ; *

1. Volume d’utilisateurs
◉ L’image de marque ; 2. Conversion depuis la liste
3. Chiffre d’affaire
◉ La réduction des coûts ; 4. Impact environnemental

◉ La limitation du risque technologique ;

92 93
MODULE №2

MODULE №2
L’opportunity map Opportunity score de l’équipe Activation
Le framework conçu par Anthony Ulwick s’appuie sur le principe selon
lequel les gens achètent des produits pour obtenir un résultat attendu. En
Opportunité Importance Satisfaction Score
vous basant sur le modèle des Jobs-to-be-done de Clayton Christensen, vous
pouvez définir une liste de résultats attendus et demander à vos utilisateurs Proposer des
de les évaluer sur une échelle de 1 à 10 selon deux critères : résultats en fonction 10 6 14
d’où je suis
◉ Leur importance ;
Proposer des
◉ Leur degré de satisfaction. résultats en fonction 7 3 11
qui je suis

Avec ces éléments, Ulwick propose de calculer un score d’opportunité pour Améliorer la
chaque résultat attendu et décomposé de la façon suivante : Opportunity pertinence de la 9 8 10
score = Importance + (Importance — Satisfaction) géolocalisation

Vous pouvez ensuite classer vos opportunités en quatre catégories : Optimiser le

processus de 6 9 3
parrainage
◉ Opportunity score > 15 = excellent ;

◉ > 12 = très bon ;

◉ > 10 = bon ;

◉ < 10 = convenable ou dépasse les attentes. Prioriser les fonctionnalités

Les opportunités ayant les scores les plus élevés sont à la fois les plus
importantes et les moins satisfaites, elles doivent donc être explorées en
premier.
Comprendre le problème et choisir la solution
Une fois des pistes de solutions identifiées (chapitre 7), vous êtes
capables d’évaluer l’effort nécessaire à leur implémentation pour prioriser
celles qui apporteront le plus de valeur avec le moins d’effort. Ici encore,
les frameworks ne doivent pas être considérés comme des scores de
priorisation absolus, la décision vous revient en fonction du niveau de

Comprendre le problème et choisir la solution

confiance dans votre priorisation, du niveau de risque que vous êtes prêt·e
à prendre ou d’éventuelles contraintes supplémentaires.

La matrice Effort/Impact

Vous l’aurez compris, la matrice Effort/Impact permet de classer les

fonctionnalités selon deux axes : l’impact d’une part et l’effort d’autre
part. Comme nous l’avons vu plus haut, l’impact peut être évalué de
différentes manières : réduction d’une douleur utilisateur, impact
business… L’effort peut également prendre en compte différents critères :
temps de développement, compétences actuelles des équipes, effort de
synchronisation projet, effort de création des contenus… Concentrez-vous
en priorité sur les fonctionnalités qui ont le plus fort impact et demandent
le moins d’effort.
94 95
MODULE №2

MODULE №2
La matrice Effort — Impact Le RICE

Le framework RICE est une méthode théorisée par Intercom et basée

Fort iCBaAt sur quatre critères :

◉ R pour Reach : combien de personnes pouvez-vous toucher/sont

concernées par le problème ?
Quick wins! Projets
majeurs ◉ I pour Impact : quel sera l’impact de la résolution de ce problème ?

Faible Effort ◉ C pour Confiance : quel est le degré de certitude de vos estimations
effort élevé de Reach et d’Impact ? A-t-on des données quantitatives et quali-
tatives qui vous permettent d’appuyer les indicateurs précédents ?
Projets $ui Tâches de
n’en valent remplissage ◉ E pour Effort : quel est l’investissement, le temps de travail estimé
pas la peine
de toute l’équipe, l’énergie nécessaire pour mettre en place la
fonctionnalité ? Y a-t-il des éléments (dépendances, technologies
qu’on ne connaît pas, beaucoup d’écrans…) qui vont augmenter la
complexité de la mise en œuvre de la solution ?
Faible iCBaAt
Le score RICE se calcule de la façon suivante : (Reach x Impact x
Confiance)/Effort
MoSCoW
Ce ratio valeur du problème/effort pour développer la solution permet
La méthode de MoSCoW permet de prioriser vos fonctionnalités selon de prioriser les solutions ayant le meilleur retour sur investissement, c’est-
les critères suivants : à-dire le score RICE le plus élevé.

Mo — Must have : doit être réalisée ;

S — Should have : devrait être réalisée si possible. Ces fonctionnalités

sont importantes, mais pas cruciales ;
Comprendre le problème et choisir la solution

Comprendre le problème et choisir la solution

Co — Could have : pourrait être réalisée s’il n’y a pas d’impact sur les
autres fonctionnalités en cours ;

W — Won’t have : ne sera pas réalisée.

Une priorisation par la technique de MoSCoW peut être un bon point

de départ, elle est facile à mettre en place et collaborative. Vous pouvez
l’utiliser en atelier avec vos parties prenantes pour les impliquer dans la
priorisation et obtenir un consensus.

96 97
MODULE №2

MODULE №2
RICE de l’équipe Activation
Nos conseils
Problème Solution R I C E Score ◉ La liste de frameworks présentée ici n’est pas exhaustive, il existe
plus d’une vingtaine de techniques de priorisation connues. Il n’y
a pas de méthode de priorisation parfaite, comme toujours, vous
Enregistrer adresses devez tester et adapter les méthodes à votre contexte.
2 3 3 1 18
Proposer des favorites
résultats en ◉ Une bonne collaboration et communication avec vos parties
fonction de où
prenantes durant la priorisation vous aideront à favoriser
je suis
Géolocalisation 4 4 4 5 12,8 l’adhésion.

◉ Attention à ne pas tomber dans le piège du « tout est important »,

Bandeau parrainage 3 3 4 1 36 quelle que soit la méthode utilisée, prioriser implique
Optimiser le nécessairement de faire des choix.
processus de
parrainage Parrainage dans
le parcours de 2 2 4 2 8
commande

Téléchargez vos templates de matrice effort impact,

RICE, MoSCoW
Comprendre le problème et choisir la solution

Comprendre le problème et choisir la solution

98 99
 MODULE №2
L’essentiel
de ce module

1. La discovery couvre un ensemble d’activités incluant les utilisateurs

qui ont pour but de dérisquer des idées en creusant les problèmes et
en imaginant et testant des solutions.

2. Appuyez-vous sur des cadres méthodologiques pour structurer

votre discovery : le Design Thinking et son double diamant, le Lean
Startup et son Lean Canvas, Discovery Discipline et la méthode
F.O.C.U.S.E.D.

3. Creusez les problèmes des utilisateurs en faisant des interviews, de

l’observation, de l’immersion…

4. Faites appel à l’intelligence collective pour imaginer les

fonctionnalités lors d’ateliers : brainstorming, story mapping,
impact mapping…

5. Dérisquez vos solutions les plus complexes grâce aux tests pour
faire face à la réalité du terrain.

6. Structurez vos tests en définissant des hypothèses, en choisissant le

Comprendre le problème et choisir la solution

bon test, en collectant les données et feedback et en analysant les
résultats.

7. La priorisation permet de garder le focus à chaque étape du

processus produit et pour tout type d’élément : une opportunité
vaste à explorer ou une fonctionnalité à tester.

101
3—
Construire le
produit
« La valeur réside dans
l’exécution, pas seulement
dans l’idée. Il est essentiel
de construire rapidement,
d’apprendre et de
s’adapter en fonction des
retours des clients. »
— Ash Maurya
MODULE №2
L’approche Produit se caractérise par l’obsession de
l’utilisateur et le souci constant de livrer des solutions qui
Comprendre le problème et choisir la solution
répondent à son besoin tout en collant aux objectifs business
de l’entreprise. Si la discovery permet de limiter les risques
de lancer une fonctionnalité inadaptée, le delivery permet de
livrer la valeur de vos fonctionnalités en continu et dans les
meilleurs délais, dans le but d’obtenir des retours réguliers des
utilisateurs et itérer ainsi rapidement.
Dans ce module, nous verrons comment relever ce challenge
en équipe, en préparant les développements de façon efficace
et en gérant le delivery avec agilité. Vous allez également
apprendre comment planifier et suivre le bon déroulement des
développements et comment tester et lancer vos fonctionnalités.
103
MODULE №3
CHAPITRE 10
Préparer les
développements
Outil central du delivery, le backlog Produit est clé pour préparer le
développement des nouvelles fonctionnalités. Il permet d’avoir une vision
globale sur ce qui constituera le produit, et d’organiser le delivery de
manière incrémentale. Un travail d’équipe est nécessaire pour l’alimenter,
rédiger les User Stories et s’assurer que tout est prêt avant de développer.
Le backlog Produit
Les éléments du backlog
Un backlog est un ensemble ordonné d’éléments à réaliser pour délivrer
le produit, c’est tout le travail que l’équipe va devoir réaliser. Souvent pré-
senté sous forme de liste, le backlog est constitué de différents éléments :
◉ L’Epic, brique fonctionnelle à valeur : une Epic décrit une partie
de la solution à développer pour répondre au problème identifié.
Elle contient les informations macroscopiques de contexte, de
valeur attendue et de critère de succès. L’Epic est un conteneur de
plusieurs User Stories qui, lorsqu’elles sont développées, contribuent
à délivrer la valeur ciblée ;
◉ La User Story, description fonctionnelle détaillée : une User Story
décrit un besoin utilisateur et précise comment faire évoluer le
Construire le produit
produit pour y répondre. L’objectif est de spécifier le développement
d’une partie d’une fonctionnalité ;
◉ La Technical Story, sujet technique : les prérequis techniques au
développement des User Stories (montée de version d’un composant
technique, refacto d’une brique technique) sont formalisés en tant
que Technical Stories. Ces éléments contiennent la description des
104
MODULE №3
tâches techniques à réaliser ainsi que l’objectif recherché. Ils sont
généralement rédigés directement par l’équipe de développement ;
◉ Le ticket de bug, demande de correction d’une anomalie : les
anomalies, comportements non désirés de votre produit, doivent
apparaître dans le backlog afin que leur résolution soit priorisée
vis-à-vis des nouvelles fonctionnalités ;
◉ Le Spike, sujet d’étude : lorsqu’une demande n’est pas estimable parce
qu’il y a trop d’inconnues, ou bien lorsqu’une phase de recherche est
nécessaire avant de statuer sur la solution à implémenter pour une
fonctionnalité donnée, il est possible de créer un Spike. Ces études
sont généralement bornées dans le temps. Cela permet de réserver
une partie de la capacité de l’équipe à la réalisation de l’étude tout
en maîtrisant l’impact sur le reste des développements. Afin de
maximiser le succès de la phase d’étude, nous vous recommandons
de définir en amont les livrables attendus. Si l’objectif n’a pas été
atteint lorsque le temps imparti est écoulé, vous pouvez décider de
prolonger la durée de l’étude ou bien de la reporter.
Et la feature ?
Il peut exister dans certaines organisations un niveau de granularité
additionnel entre l’Epic et la User Story, appelé feature. L’ajout de ce
niveau de découpage supplémentaire permet de regrouper vos
User Stories en ensembles fonctionnels cohérents intermédiaires,
particulièrement pertinents si votre produit est complexe ou de taille
conséquente. Dans ce cas, vos Epics sont découpées en features qui
elles-mêmes sont découpées en User Stories. Par exemple, on peut
avoir une Epic « Gestion du compte », découpée en plusieurs features
dont la « Création du compte », la « Suppression du compte » et la
« Réinitialisation du mot de passe », elles-mêmes découpées en User
Stories plus petites. L’important est avant tout de définir un référentiel
qui soit parlant pour votre équipe.
Construire le produit
105
MODULE №3

L’entretien du backlog
Le backlog est central pour l’équipe qui s’y réfère pour prendre
connaissance des solutions à développer. Les parties prenantes peuvent
également le consulter pour avoir de la visibilité sur les sujets en cours et
à venir.
Votre rôle est de faire vivre votre backlog en y ajoutant, retirant ou
réorganisant ses éléments régulièrement. Assurez-vous de toujours garder
en haut de la pile les User Stories à plus forte valeur. En tête du backlog,
les User Stories priorisées seront détaillées tandis qu’en redescendant dans
la liste la priorité sera moindre et les éléments plus gros, moins détaillés.
MODULE №3
Créer son backlog
Découper les Epics en User Stories
La création du backlog à un niveau Epic commence en réalité en phase
de discovery, lorsque vous précisez la solution. À ce stade, l’Epic n’est pas
assez détaillée pour commencer les développements, c’est pourquoi vous
devez découper votre Epic en User Stories à travers les activités de backlog
refinement.

Ne prenez pas trop de temps pour ajouter et préciser les éléments en Epic et User Stories de l’équipe Activation
bas du backlog. Pourquoi écrire, discuter, estimer, bref prendre du temps à
l’équipe si elle n’a pas la capacité d’absorber la charge de développement ?
L’Epic « Identifier les restaurants à proximité de chez soi » peut se
Faites que votre backlog soit toujours petit et lisible en vous concentrant
décomposer en plusieurs User Stories :
sur la livraison des fonctionnalités à forte valeur ajoutée.

◉ Filtrer la liste de restaurants par rapport à mon adresse.

Backlog ou pas backlog ? ◉ Visualiser les restaurants sur une carte.

◉ Ajuster le rayon de recherche « à proximité. »

Un backlog n’est pas un pense-bête, au risque de devenir un fourre-
tout illisible dans lequel sont notées toutes les nouvelles idées.
◉ Prévisualiser le détail du menu du restaurant depuis la carte.
La méthode Shape Up, développée chez Basecamp et expliquée
dans le livre du même nom écrit par Ryan Singer, va même jusqu’à
recommander de ne pas s’embarrasser d’un backlog et de se
concentrer sur les solutions à construire sur le prochain cycle de
six semaines. Les idées qui n’ont pas été retenues sont alors jetées.
Mener un refinement
Il estime que si elles sont toujours pertinentes six semaines plus
tard, elles ressortiront naturellement. Il met notamment en avant le
Le backlog refinement est un rituel collaboratif qui réunit autour
poids mental représenté par un backlog trop gros ainsi que le côté
de la table l’ensemble des participants au delivery. À l’issue des backlog
chronophage des backlog refinement : « Les backlogs sont un poids
refinements, vous devez avoir levé toutes les incertitudes et pouvoir vous
que nous n’avons pas besoin de porter. Des dizaines, puis des centaines
lancer dans les développements sereinement.
de tâches s’accumulent, dont nous savons tous que nous n’aurons
jamais le temps de nous occuper. Cette pile croissante nous donne
Il est donc important que les sujets abordés lors des refinements
soient partagés, et compris par toute l’équipe. Certaines équipes préfèrent
Construire le produit

Construire le produit
l’impression d’être toujours en retard, même si ce n’est pas le cas. Ce
n’est pas parce que quelqu’un a pensé qu’une idée était importante il
ritualiser les refinements en définissant des créneaux hebdomadaires,
y a un trimestre qu’il faut s’y atteler encore et encore. Les backlogs
d’autres sollicitent les échanges en fonction des besoins et de la bande
sont aussi une grande source de perte de temps. Le temps passé à
passante de l’équipe.
examiner, soigner et organiser de vieilles idées empêche tout le monde
d’avancer sur les projets opportuns qui comptent vraiment. »

106 107
MODULE №3

MODULE №3
Pendant les sessions de refinement, vous devez réaliser les activités
Exemple de mapping de l’équipe Activation
suivantes :

◉ Vous accorder avec l’équipe sur le bon découpage des Epics en User
Stories ; Question Question
Gestion des paniers Le code doit-il être en
de 25 euros pile ? majuscules ?
◉ Identifier les règles métier et les critères d’acceptation ;

◉ Repérer les éléments à clarifier ;

◉ Évaluer la complexité.
Pour encadrer les sessions de refinement, vous pouvez vous appuyer sur
des ateliers participatifs comme l’example mapping ou le Tres Amigos.
User story
En tant que nouvel utilisateur, je souhaite utiliser mon code de réduction de 10% sur
ma première commande, aon de prooter de mon o re de dienvenuen

L’example mapping vous permet d’aborder pendant un temps restreint Critère Critère Critère
(25-30 min) le périmètre d’une User Story et d’identifier les règles métier
d’acceptation d’acceptation d’acceptation
et critères d’acceptation associés et les questions restantes à préciser. À Renseigner un code Appliquer la remise N’utiliser le code
l’issue de l’atelier, les participants votent s’ils sont à l’aise pour partir en valide sur les paniers de plus qu’une seule fois lors
développement ou s’il faut continuer à préciser les éléments. de 25€ de la première
commande

Cas passant Cas non-passant Cas non-passant

Panier de 28€ avec le Panier de 2 € avec le Panier de 28€ avec le

code WELCOME code WELCOME– code WELCOME déjÇ
utilisé
-> une réduction de -> aucune réduction
10% s’applique ne s’applique -> aucune réductioÞ
ne s’applique

Cas non-passant

Panier de 28€ avec le

code ¸·EN©EN¨E–
-> aucune réduction
ne s’applique
Construire le produit

Construire le produit
108 109
MODULE №3
L’atelier Tres Amigos, réunissant autour de la table Product Manager,
développeur et testeur, aide à l’écriture des User Stories et notamment
des critères d’acceptation. Avant l’atelier, vous écrivez les règles métier
de la User Story. Celles-ci pourront être partagées en amont pour que
l’équipe prépare les questions. Lors de l’atelier, les règles sont revues et les
participants rédigent de façon conjointe les critères d’acceptation. L’atelier
permet généralement d’éclaircir certaines zones d’ombre et de préciser si
besoin les règles à implémenter.
Rédiger une User Story
Au-delà de leur structure et contenu, les User Stories sont avant tout un
support de discussion entre vous et les membres de l’équipe, permettant
d’échanger sur le besoin et se mettre d’accord sur les solutions à développer.
Ron Jeffries, informaticien américain de renom, indique que de bonnes User
Stories intègrent trois aspects :
◉ Carte : des informations synthétiques et faciles à comprendre
(pouvant tenir sur une carte) ;
◉ Conversation : des discussions et échanges qui donnent naissance
à des règles métier, non dictées par les Product Managers ;
◉ Confirmation : une compréhension partagée des attentes à travers
les critères d’acceptation.
Aussi, le bon format d’une User Story est celui qui fonctionne pour vous
et en fonction des sujets. Dans certaines équipes, suffisamment matures, et
pour certains sujets petits, peu risqués ou techniques, la User Story réduite
à une description fonctionnelle peut suffire. Gardez bien en tête qu’une
équipe alignée et partageant la connaissance du produit n’a pas forcément
besoin de User stories détaillées !
Construire le produit
110
MODULE №3
Zoom sur le framework INVEST
Le framework INVEST vous donne une ligne de conduite pour rédiger
le contenu de vos User Stories. Ses six critères vous permettront de
vous questionner pour rédiger de bonnes User Stories :
◉ Indépendante : vos User Stories doivent, dans la mesure du
possible, être indépendantes les unes des autres pour pouvoir
être développées et livrées individuellement ;
◉ Négociable : elles doivent amener à la discussion et peuvent
être modifiées jusqu’à ce qu’elles partent en développement ;
◉ Valeur : elles doivent apporter de la valeur. La notion de valeur
étant toujours difficile à évaluer, les User Stories doivent
être exprimées avec une vision de l’objectif recherché pour
l’utilisateur et l’entreprise ;
◉ Estimable : elles doivent être suffisamment claires pour
permettre à l’équipe d’en évaluer la complexité ;
◉ Small (Petite) : elles doivent être de taille assez petite pour
éviter les effets tunnel. Essayez donc au maximum de découper
finement vos User Stories ;
◉ Testable : les User Stories doivent raconter une histoire, dont
les tests découlent de façon évidente.
Vous pouvez par exemple rédiger vos User Stories de la façon suivante :
◉ Un titre, exprimant la finalité de la User Story ;
◉ Une phrase narrative orientée utilisateur décrivant le bénéfice
souhaité, souvent structurée sous la forme « en tant que… », « je
veux… », « afin de… » ;
Construire le produit
◉ Un ensemble de règles métier, détaillant le comportement attendu
pour répondre au besoin ainsi que les critères d’acceptation et condi-
tions nécessaires à la validation de la fonctionnalité (chapitre 14).
111
MODULE №3
Une User Story de l’équipe Activation
En repartant de l’atelier d’example mapping, le·la Product Manager de
l’équipe Activation a pu rédiger la User Story suivante :
Appliquer une réduction lors de la première commande
En tant que nouvel utilisateur, je souhaite utiliser mon code de réduction
de 10 % sur ma première commande, afin de profiter de mon offre de
bienvenue.
Règles métier :
◉ La remise s’applique uniquement si l’utilisateur saisit un code
valide (WELCOME en majuscule ou minuscule) ;
◉ La remise s’applique uniquement sur les paniers de 25 € ou
plus ;
◉ Le code n’est utilisable qu’une seule fois et lors de la première
commande.
Les règles ont été précisées grâce aux questions posées lors de
l’atelier.
Cette structure générique vous servira de base à la rédaction de vos
User Stories. Vous pouvez ensuite les compléter en ajoutant les éléments
pertinents à la compréhension du besoin et de la solution : maquettes,
schéma d’architecture, plan de taggage (chapitre 17)…
Avant de partir en développement
Organisez-vous avec le Kanban du ready
Construire le produit
Afin d’organiser les étapes de refinement des solutions, vous pouvez
visualiser les étapes dans un tableau Kanban. La visualisation vous
permettra de vous organiser avec votre équipe et de communiquer avec
transparence sur les sujets à venir en développement.
112
MODULE №3
Le Kanban du ready est un bon moyen pour ajuster la cadence de
préparation des User Stories, en fonction de la capacité de l’équipe de
développement. Vous pouvez viser à adopter une approche de juste à temps
pour la maturation des User Stories. On évitera de remplir un backlog
avec des éléments qui tomberont dans l’oubli quelques semaines plus tard.
Le Kanban du ready
Peêt à êten eédigé Rédactioi ni coues à enfine Rnad! to dn
Construisez la Definition of Ready
Votre refinement étant effectué, vous vous demandez quand une User
Story peut être développée ? C’est normalement l’équipe qui va pouvoir
répondre à cette question, mais une Definition Of Ready (DoR) vous aide à
identifier plus facilement cet état.
La DoR est la liste d’éléments attendus qu’une User Story doit rassembler
pour passer en développement. Il s’agit d’un contrat passé avec l’équipe,
permettant d’expliciter les attendus d’une User Story et permettant d’avoir
un gage de qualité en amont des développements.
Definition of Ready de l’équipe Activation
DoR — Équipe activation
L’US est INVEST
Les '$"!ettes s# t &$+)es
Les )2e $ 1es s# t e t>)es et t.$t)es
Construire le produit
Les tests ’$11e2t$t# s# t .)-)s
L’US est est')e
Les 1# t.$ts ’ te.S$1e es PXIs s# t .)-)s
113
MODULE №3

MODULE №3
La DoR peut évoluer au fil du temps et diffère d’une équipe à l’autre, voire
d’un produit à l’autre. Pour la définir, organisez un atelier avec l’ensemble
de l’équipe.

N’ayez pas peur du syndrome du backlog vide ! Sélectionner uniquement

les User Stories prêtes à partir en développement permet d’assurer la
livraison et la qualité de vos développements. Et si vous manquez d’éléments
fonctionnels prêts, rappelez-vous qu’il existe également les Technical
Stories, Spikes et tickets de bug.

Nos conseils
◉ Lorsque vous prenez possession d’un backlog existant, prenez le
temps de faire le tri et supprimez les éléments trop anciens, cela
permet de vous approprier le périmètre et de valider la valeur de
chaque solution.

◉ Lorsque vous découpez vos Epics en User Stories, gardez en tête

que vous n’avez pas besoin d’implémenter l’intégralité de l’Epic pour
la livrer aux utilisateurs. Prioriser les User Stories qui permettent
de livrer le périmètre minimal de chaque Epic, les autres User
Stories identifiées pourront être priorisées plus tard, en fonction
des retours utilisateur.

◉ N’attendez pas un refinement pour commencer à collecter les avis

sur la faisabilité technique, l’UX… d’une User Story. Vous pouvez
commencer à parler d’une User Story à votre équipe lorsque vous
avez un peu de temps avant ou après votre Daily par exemple.
Construire le produit

Construire le produit
114 115
MODULE №3

MODULE №3
CHAPITRE 11 Les 12 principes de l’Agilité

Gérer le delivery
avec Agilité Satisfaire le client en
priorité
Accueillir le changement
positivement
Livraisons fréquentes et
fonctionnelles

Pour le delivery, les équipes Produit s’appuient sur l’approche Agile.

L’Agilité permet une meilleure capacité de réponse aux changements, aux
exigences et aux besoins des utilisateurs grâce au développement itératif et
continu. En s’appuyant sur les principes et les valeurs de l’Agilité, l’équipe
veille à mettre en place un fonctionnement collaboratif et humain propice à
l’itération et l’amélioration continue.
Collaborer Soutenir les équipes et
quotidiennement avec le Dialoguer en face à face
faire confance
client et les développeurs

Les fondamentaux de l’Agilité

Les valeurs et principes

Un logiciel opérationnel Adopter un rhthme Soutenir l|etcellence
L’Agilité est un regroupement de 4 valeurs et de 12 principes décrits est la principale mesure régulier et soutenable technique et bonne
dans un manifeste et permettant de développer des produits numériques d’avancement. conception
de qualité par la livraison de petits incréments.

Les valeurs fondamentales de l’Agilité indiquent que :

◉ Les personnes et les interactions sont plus importantes que les

processus et outils. La communication et la collaboration entre les
membres de l’équipe sont essentielles pour le succès d’un produit ;
Avoir une équipe auto˜
Privilégier la simplicité organisée S|améliorer en continu
◉ Un produit qui fonctionne est plus important qu’une documentation
exhaustive. Bien que la documentation soit nécessaire, la priorité
doit être donnée à la création du produit ;
Construire le produit

◉ La collaboration avec le client est plus importante qu’une négociation
contractuelle. L’accent est mis sur les contacts de l’équipe avec le
client afin de bien répondre à ses besoins qui évoluent dans le temps ;
◉ L’adaptation au changement est plus importante que de suivre
le plan. Au lieu de s’accrocher à un plan initial fixe, l’équipe est
réceptive aux changements et pourra y répondre de manière flexible.
116
Construire le produit
Les frameworks Agiles sont des cadres de travail définis en accord avec
ces principes et valeurs. Il en existe plusieurs comme Scrum, Kanban,
Xtrem Programming… Si les pratiques Agiles peuvent évoluer, la rigueur
avec laquelle vous devez apporter rapidement et régulièrement de la valeur
à vos utilisateurs (principe fondateur du Manifeste Agile) reste intacte.
117
MODULE №3
Adopter un framework à la lettre, sans prendre de recul pour comprendre
et appliquer les principes et valeurs, ne rend pas l’équipe Agile. À l’inverse,
incarner les valeurs sans bénéficier des boîtes à outils offertes par les
frameworks Agiles sera difficilement tenable dans le temps, surtout dans
le cas de produits matures, de plus en plus complexes, avec de plus en plus
d’utilisateurs.
Les prérequis
En prérequis à la bonne application de l’Agilité, la mise en place d’un
environnement propice à l’autonomie et la collaboration de l’équipe est
nécessaire. En effet, la réussite d’une équipe Agile réside dans sa capacité à
être responsabilisée, avec un haut degré d’alignement et d’autonomie. C’est
pourquoi une équipe Produit Agile est :
◉ Pluridisciplinaire et auto-organisée : elle comprend toutes les
personnes (à temps plein ou partiel) nécessaires au delivery, que ce
soit dans la conception, le développement et le test ;
◉ Autorisée à faire des choix : elle peut prendre des décisions et
peut mettre en production régulièrement de manière autonome.
S’inspirer des différents frameworks
Agiles
Scrum, un cadre structuré
Scrum repose sur la mise en place de cycles de développements courts
et itératifs appelés sprint, au cours desquels l’équipe se focalise sur la
livraison d’un périmètre précis et fixé. Basé sur trois piliers fondamentaux
— la transparence vis-à-vis de tous, l’inspection ou la capacité à se remettre
en question et l’adaptation au changement — le framework détaille 3 rôles,
3 artefacts et 4 événements.
Construire le produit
118
MODULE №3
Les 3 rôles de Scrum
◉ Le·la Product Owner a pour rôle de maximiser la valeur du produit
réalisé par l’équipe. Il·elle est responsable de la gestion du backlog,
s’assure de représenter les besoins des différentes parties prenantes
dans les items du backlog et communique des objectifs Produit
clairs. Le rôle de Product Owner est propre au framework Scrum.
En principe, ces responsabilités incombent aux Product Managers.
◉ Le·la Scrum Master a pour rôle d’accompagner l’équipe dans
l’application de Scrum. Il·elle facilite également les échanges entre
les différents acteurs et lève les obstacles que l’équipe rencontre.
Selon les organisations et les niveaux de maturité d’une équipe, le
rôle de Scrum Master peut être tenu par une personne partagée
entre plusieurs équipes ou tenu par un développeur de l’équipe.
◉ L’équipe de développement réalise le travail nécessaire à la
création du produit et la livraison d’un incrément terminé.
Les 3 artefacts de Scrum
Scrum mentionne trois principaux artefacts qui permettent de diffuser
les informations avec transparence :
◉ Le product backlog (chapitre 10) est la liste d’items nécessaires
pour construire ou améliorer le produit, priorisés par le·la Product
Owner en fonction de leur valeur ;
◉ Le sprint backlog contient les éléments du product backlog les
plus prioritaires et que l’équipe de développement s’engage à livrer
pendant le sprint en cours ;
◉ L’incrément est une somme de développements respectant la
Definition of Done (chapitre 14) et pouvant être mis en production.
Le sprint
Au cœur du framework Scrum, le sprint dure maximum quatre semaines.
Cette durée est généralement fixée par les Product leaders et non par les
Construire le produit
Product Managers afin d’assurer une cohérence entre les équipes. Sachez
toutefois que l’objectif pour Scrum est d’avoir des itérations les plus courtes
possibles afin de livrer les incréments Produit, récupérer du feedback et
ajuster le périmètre au plus vite.
Le sprint commence par le sprint planning au cours duquel l’équipe
s’engage sur un objectif à atteindre : l’objectif de sprint ou sprint goal.
Rythmé par les daily, il se termine par la review et la rétrospective.
119
MODULE №3

MODULE №3
Les 4 événements Scrum Le framework Scrum

◉ Le sprint planning. Le sprint planning pose le cadre du sprint. Au

Product Scru !ter
cours de cette cérémonie, l’équipe discute des User Stories les plus Owner
prioritaires et détermine ce qui peut être embarqué dans le sprint
en définissant le sprint goal.

◉ Le Daily Scrum. Organisé tous les jours à la même heure, le Daily Équipe Daily
Scrum permet à l’équipe de partager comment avance le sprint Scrum

vis-à-vis du sprint goal. L’objectif du Daily Scrum n’est pas de faire

Sprint
un point de reporting du travail accompli, mais plutôt d’identifier planning Incrément
les éventuels points de blocage le plus rapidement possible et de
réajuster la priorisation et le backlog de sprint si nécessaire, afin de Sprint
garantir l’atteinte de l’objectif.

◉ La sprint review. La review permet à l’équipe de présenter

aux parties prenantes le résultat du sprint. L’équipe fait une
démonstration (démo) des incréments réalisés et peut récolter le Product Sprint Sprint revie;
Backlog Backlog Rétrospective
feedback des parties prenantes. Une bonne pratique est de confier
la démo aux développeurs qui ont contribué au développement
des fonctionnalités présentées. En plus de la démo, la review est
également l’occasion de partager des éléments clés tels que le suivi Kanban, un flux continu
des performances, un bilan sur l’avancement de la roadmap ou
l’atteinte des objectifs. Kanban se base sur le principe de flux tiré. Les éléments prêts et
prioritaires du backlog sont « tirés » dans le tableau Kanban. Avant de
◉ La rétrospective. La rétrospective (rétro) permet de faire un commencer un nouveau sujet, l’équipe regarde si elle peut faire avancer
bilan du sprint afin d’identifier les succès et les échecs, ainsi que ou terminer l’un des sujets actuels. L’approche Kanban se concentre sur la
les pistes d’améliorations. Aussi, elle permet de mettre en place des visualisation du travail en cours, la limitation de ce travail, l’optimisation
actions d’amélioration continue. Il existe une multitude de formats du flux et l’amélioration continue.
de rétrospective, permettant de se renouveler et de rendre l’exercice
plus dynamique (chapitre 20). La visualisation du travail en cours

Le tableau Kanban est un outil permettant de visualiser le flux de travail

sous forme d’étapes, chaque étape étant représentée par une colonne. Le
flux représente de façon exhaustive l’ensemble des activités nécessaires
pour livrer une fonctionnalité. Selon vos besoins, le tableau peut être aussi
simple que « à faire », « en cours » et « fait » ou bien plus détaillé, avec par
exemple les colonnes « à analyser », « prêt », « en développement », « en
review », « en test », « terminé », « déployé », « clôturé ».
Construire le produit

Construire le produit
La carte Kanban est un élément du backlog (chapitre 10). Placées dans le
tableau par ordre de priorité, les cartes, qui sont toutes de taille équivalente,
vont traverser les colonnes de gauche à droite. Il est possible pour une carte
de sauter certaines colonnes, mais en principe elles ne peuvent pas revenir
en arrière. Les critères de passage doivent être explicites et partagés.

120 121
MODULE №3
Cette représentation visuelle est essentielle, car elle permet de donner
une meilleure visibilité sur le travail en cours et de faciliter l’identification
de points de blocage qui empêcheraient l’avancée des sujets.
La limitation du travail en cours
Stop starting, start finishing est une devise qui reflète bien l’approche
Kanban. L’objectif est de faire passer le plus vite possible un maximum
d’éléments d’une colonne à l’autre. Plutôt que de travailler sur un grand
nombre de tâches en parallèle, on impose pour chaque colonne du tableau
une limite sur le nombre d’éléments pouvant figurer en même temps dans
la colonne. C’est ce qu’on appelle la WIP Limit (Work in Progress Limit).
Une fois la limite atteinte, l’équipe se concentre sur les éléments présents
dans la colonne et s’entraide afin de les faire passer à l’étape suivante.
Le framework Kanban
backlog analysis development test deploy done
WIP Limit WIP Limit
WIP Limit
WIP Limit
Backlog Item Flow
L’optimisation du flux
En Kanban et pour optimiser le flux de travail, il est important d’ana-
lyser les processus de production et d’identifier les étapes qui prennent le
plus de temps. Le cycle time (temps d’un cycle), indicateur qui permet de
mesurer le temps pour passer d’une étape à une autre, permet de détecter
Construire le produit
les goulots d’étranglement. Le tableau vous aidera également à repérer les
étapes pour lesquelles les tâches s’accumulent. En identifiant les étapes qui
posent problème, il est possible de les améliorer et d’optimiser le processus
de delivery des fonctionnalités.
122
MODULE №3
L’amélioration continue
L’approche Kanban encourage l’amélioration continue en évaluant
régulièrement le processus et en identifiant les opportunités d’amélioration.
L’équipe discute des succès et des échecs dans le but d’identifier les moyens
d’améliorer les performances à l’avenir. Même s’il n’y a pas de rituel
spécifique documenté dans le framework Kanban, la rétrospective est un
bon moyen pour cadrer ce rendez-vous régulier.
Adapter les frameworks Agiles pour
son équipe
Scrum et Kanban sont donc deux frameworks qui mettent en œuvre
les principes et valeurs Agiles en visant à améliorer la collaboration, la
transparence et la productivité. Même si les deux approches ont des
ressemblances, chacune a ses spécificités et ses contraintes.
Apportant plus de processus et de règles, mais aussi fondé sur un rythme
itératif fixe avec les sprints, Scrum est adapté aux contextes qui nécessitent
une planification rigoureuse, lorsqu’il y a un besoin d’alignement fort entre
différentes équipes qui travaillent sur le même périmètre par exemple.
Cependant, Scrum peut devenir contraignant, obligeant les Product Owners
à fournir un nombre conséquent de User Stories prêtes à être embarquées
dans un sprint à une date donnée, ou encore en réduisant la capacité à
s’adapter au cours d’un sprint.
Kanban, plus flexible, permet de prendre plus rapidement en compte les
changements de priorités et convient mieux dans des contextes nécessitant
une capacité d’adaptation rapide. En contrepartie, Kanban peut manquer
de structure et de planification à long terme.
Certaines équipes optent pour un modèle hybride, souvent appelé
Scrumban, pour adapter le cadre à leurs besoins de fonctionnement. Vous
pouvez partir de l’approche en flux Kanban tout en ajoutant des éléments de
Scrum tel que le daily, la review et la rétrospective. Vous pouvez également
choisir de garder le cadencement en sprint et proposer à l’équipe de piocher
Construire le produit
directement dans le backlog les User Stories prioritaires à mesure que les
développements des autres tickets se terminent.
123
MODULE №3

MODULE №3
Nos conseils
◉ Testez différents cadres Agiles : comme pour un produit, n’hésitez
pas à faire des itérations pour trouver la meilleure façon de
travailler en équipe (celle qui convient à tout le monde).

◉ Le jour de la review, vous pouvez prévoir un support de

présentation et des vidéos de démonstration des fonctionnalités
pour éviter les imprévus du direct, le célèbre « effet démo ».

◉ Ne négligez pas la rétrospective ! Que ce soit en Scrum ou en

Kanban, l’amélioration continue est essentielle et cet événement
permet à l’équipe de se mobiliser autour d’actions communes à
mettre en place.
Construire le produit

Construire le produit
124 125
MODULE №3

MODULE №3
CHAPITRE 12 temps de trajet est un peu plus incertain… Enfin, si pour vous rendre à
votre travail vous devez prendre deux lignes différentes sur plusieurs arrêts
chacune, il devient presque impossible de prédire avec certitude le temps

Planifier et donner de trajet nécessaire. Vous pouvez émettre une hypothèse, mais les éventuels
aléas (retard, incident, forte affluence) pourront vous retarder.

de la visibilité Date connue ou hypothèse de livraison

Parce qu’elle est au cœur du delivery, votre équipe Produit génère des
attentes chez l’ensemble des parties prenantes. Vous devez régulièrement
répondre aux questions souvent redoutées : quand le produit sera-t-il
livré ? Combien coûte le développement de la fonctionnalité ? Bien qu’il soit
difficile, voire risqué, de prédire la date de livraison d’une fonctionnalité, il
est indispensable de pouvoir donner de la visibilité à vos parties prenantes.
Dans ce chapitre, nous verrons quels sont les outils pour donner cette
visibilité et s’organiser efficacement sans y passer trop de temps.
Vous l’avez compris, il est impossible d’évaluer avec certitude la
complexité d’implémentation d’une fonctionnalité, et par conséquent la
date à laquelle elle pourra être livrée. La date de livraison est donc une
hypothèse qui doit être ajustée à mesure des développements.
Il se peut que vous deviez parfois faire face à des contraintes fortes
(événement annuel, refonte médiatisée de l’image de marque, contrat
incontournable), pour lesquelles on vous demandera de vous engager sur
une date. Si des aléas viennent mettre en péril cette date imposée, vous
pouvez jouer sur trois variables d’ajustement :

◉ Retarder le lancement ;

◉ Réduire le périmètre en livrant moins de fonctionnalités que prévu ;

Prévoir l’atterrissage des ◉ Augmenter les coûts en renforçant les équipes.
fonctionnalités En tant que Product Manager, vous devez expliquer ces éléments à
vos parties prenantes et vous accorder ensemble sur la marche à suivre.

Pourquoi est-il difficile de prédire ?

Lorsqu’on crée un produit numérique, le développement de chaque

nouvelle fonctionnalité est unique et nécessite une implémentation
spécifique. Il ne s’agit pas ici de développer une pièce d’un produit physique
réalisé à grande échelle et où il serait possible de connaître à l’avance les
détails de la production : matériaux nécessaires, temps pour produire,
processus de production. Pour chaque nouvelle fonctionnalité, le temps
nécessaire à sa réalisation ne sera connu que lorsque celle-ci sera terminée.
Construire le produit

Construire le produit
L’incertitude est une composante du développement et du Product
Management. Lorsque vous préparez le backlog (chapitre 10), vous
manipulez des éléments plus ou moins certains et de tailles différentes.
Ayez en tête que plus vos User Stories sont petites, plus fiables seront les
prédictions. Prenons l’exemple d’un trajet entre votre domicile et votre
lieu de travail. Si vous travaillez à cinq minutes à pied de chez vous, vous
pouvez facilement prédire le temps nécessaire pour vous rendre au bureau.
En revanche, si vous habitez à trois arrêts de métro de votre bureau, le
126 127
MODULE №3

MODULE №3
Plus de développeurs pour aller plus vite ? Les outils pour aider la prédictibilité

La croyance selon laquelle plus une équipe de développement est
grande, plus elle peut produire vite est généralement erronée. Et
peu importe le framework avec lequel vous travaillez ! En réalité, plus
l’équipe est large (à partir de 8 personnes), plus elle peut avoir du mal à
s’organiser, communiquer et répartir le travail de façon à ce que tout
le monde puisse travailler en parallèle, nuisant ainsi à la productivité.
De plus, vous devez consacrer plus de temps à préparer le delivery, au
détriment de vos autres activités de Product Manager. Une équipe plus
petite (5 ou 6 personnes) vous permet de dégager plus de temps pour
la discovery, l’analyse des feedbacks, la mesure de l’impact… Un renfort
ponctuel peut toutefois être efficace si les développeurs qui viennent
prêter main-forte peuvent travailler rapidement et en autonomie sur
votre périmètre. Si une longue montée en compétence est nécessaire,
là aussi, vous risquez de perdre plus de temps qu’autre chose.
Ratio de développeurs par PO d’après l’étude LPC 2022
Les estimations et la vélocité en Scrum
Les estimations
Le travail de prédictibilité est amorcé lors de la présentation du backlog
aux développeurs. L’estimation des User Stories par l’équipe est le premier
élément pour affiner sa compréhension de la complexité.
L’estimation exprime la complexité pour réaliser la User Story et peut être
annoncée sous différents formats dans le but de constituer un référentiel de
comparaison d’un élément à l’autre. On choisit généralement un sizing en
taille de T-shirt (XL, L, M, S) pour les Epics ou un point de complexité pour
les User Stories (suivant la suite de Fibonacci : 1, 2, 3, 5, 8, 13).
Les User Stories doivent être estimées par l’équipe de développement,
idéalement en groupe. Voici comment se déroule une session d’estimation :

36,7 % 1. Vous décrivez l’attendu fonctionnel de chaque User Story ;

2. Chaque développeur évalue simultanément la complexité de la User

25,4 % Story en utilisant le référentiel de l’équipe. Si les valeurs données
sont différentes, les développeurs sont invités à échanger et se
mettre d’accord sur une estimation rapidement (limiter le temps
12, % d’échange à quelques minutes) ;

6,4 % 6, % 6,4 % 3. Et s’il n’y a pas de consensus ? On prend l’estimation la plus haute !
3, %
1,7 %
Grâce à chaque estimation, vous disposez d’informations
0 1-2 3-4 5-6 7-8 + de 8 # # supplémentaires qui enrichissent votre référentiel, vous permettant de
Aucun, Pool Je ne comparer la complexité des différents éléments du backlog.
on fait du partagé de sais pas
no-code dév. : il n’y a
ou on pas de dév.
outsource dédié
le dév.
Construire le produit

Construire le produit
128 129
MODULE №3
L’extreme quotation pour estimer
jusqu’à 100 User Stories en 1 heure
L’extreme quotation est une technique d’estimation qui permet d’évaluer
en un temps réduit un maximum de User Stories. L’atelier s’organise
avec vous et toute ou une partie de l’équipe de développement. Il se
déroule de la façon suivante :
◉ En amont de l’atelier, l’ensemble des User Stories ou Epics
à estimer sont écrites sur des Post-it. L’animateur prépare
également un tableau dont chaque colonne représente une
valeur de complexité (soit 1, 2, 3, 5, 8… selon Fibonacci soit XS,
S, M…) ;
◉ Vous présentez rapidement les sujets à estimer à l’équipe de
développement de façon à ce qu’elle comprenne l’attendu, mais
sans entrer dans les détails de la solution technique ;
◉ L’équipe identifie la User Story la moins complexe et la plus
complexe pour les placer aux extrémités du tableau. Elles
serviront de référence pour comparer la complexité du reste
des User Stories ;
◉ Lors d’un premier tour d’estimation silencieuse, chaque
développeur prend un Post-it et le place dans la colonne
correspondant à la complexité estimée ;
◉ Une fois tous les Post-its placés, l’équipe s’accorde un temps
de réflexion silencieuse pour prendre connaissance des
estimations avant de procéder à un second tour d’estimation.
Pendant ce second tour, les développeurs déplacent librement
et sans se concerter les Post-its dans d’autres colonnes en les
mettant en évidence s’ils ne sont pas d’accord avec l’estimation
initiale ;
◉ Une fois le second tour terminé, on considère que tous les Post-
its qui n’ont pas été déplacés sont estimés convenablement.
L’équipe peut alors discuter et s’accorder sur les estimations
des autres Post-its, limitant ainsi les discussions aux seuls
Construire le produit
sujets qui font débat.
130
MODULE №3
Gardez bien en tête que le temps passé à estimer n’améliore pas forcément
la précision de la prévision. Comme le dit John Cutler, expert Produit et
coach de renom « Au lieu de vous concentrer sur de “meilleures” estimations
(…) concentrez-vous sur : travailler plus petit, livrer fréquemment, exposer le
travail aux utilisateurs/clients plus rapidement, tester les hypothèses plus tôt,
limiter les dépendances, avoir un code moins fragile, limiter les transferts. Vos
estimations vont s’améliorer. »
Le mouvement no estimate
Si les estimations sont un outil pour l’équipe Scrum, elles ne sont
pas une obligation pour le bon fonctionnement du delivery. À noter
d’ailleurs que le Scrum guide n’en parle pas. Pour le mouvement no
estimate (pas d’estimation) porté par Vasco Duarte, l’un des leaders de
la communauté Agile :
◉ Estimer prend trop de temps ;
◉ Les estimations ne sont pas fiables ;
◉ Les estimations ne sont pas les seuls indices pour la prédictibilité.
Si vous pensez que le rituel d’estimation vous fait perdre en efficacité,
essayez cette approche en suivant quelques bonnes pratiques :
◉ Mettez en place des alternatives comme plus de communication
avec les parties prenantes, des itérations plus courtes, un
découpage fonctionnel plus fin… ;
◉ Appuyez-vous sur l’expertise de l’équipe pour confirmer que
le contenu de votre sprint est réalisable (définir un indice de
confiance) ;
◉ Testez le fonctionnement avec l’équipe et réajustez au fur et à
mesure des itérations.
Construire le produit
131
MODULE №3
La vélocité de l’équipe
La vélocité représente la capacité de votre équipe à produire, c’est-à-
dire le nombre de points que peut réaliser une équipe au complet sur un
sprint. Elle est calculée à partir des développements réalisés lors des cycles
précédents.
La vélocité d’une équipe évolue avec le temps. Si elle est peu certaine
lorsqu’une équipe est nouvellement formée, elle augmente et devient
très fiable à mesure que l’équipe monte en compétence et optimise son
fonctionnement. Enfin, elle peut parfois diminuer si un développeur
est absent, si la motivation ou le moral de l’équipe diminue ou si des
problématiques techniques ralentissent les développements (un code qui
devient difficile à maintenir, un processus long de testing…).
La vélocité est un outil de prédiction qui permet de donner de la visibilité
à l’équipe et aux parties prenantes. Il ne s’agit pas d’un outil de contrôle et
tout comme pour les estimations, il y a toujours une marge d’erreur et
d’imprédictibilité. Voici quelques règles à garder en tête afin de l’utiliser à
bon escient :
◉ Les estimations ne sont pas des engagements, mais des
appréciations qui permettent d’organiser le développement ;
◉ Plus une équipe est mature et régulière, plus ces appréciations
s’affinent et se renforcent comme un indicateur de prédictibilité ;
◉ C’est en comparant l’estimation et la réalisation qu’on adapte de
façon empirique ses prévisions futures et que l’on peut affiner la
visibilité ;
◉ La vélocité n’est pas comparable entre les équipes, chacune
ayant leur propre référentiel d’estimation ;
◉ La vélocité n’est pas une mesure du travail individuel, le delivery
d’une fonctionnalité pouvant être assuré par plusieurs personnes
de l’équipe.
Construire le produit
Le lead time et le débit en Kanban
Le lead time
Le lead time mesure en jours le temps total nécessaire pour réaliser
un élément du backlog, depuis sa création jusqu’à la livraison. Cela inclut
le temps de développement, mais également le temps de refinement, les
temps d’attente…
132
MODULE №3
Le calcul du Lead Time
Lead time
User story Début des User story
créée développements livrée
Ainsi, le lead time donne une indication sur le temps nécessaire pour livrer
une fonctionnalité. En partant du principe que votre fonctionnalité contient 4
User Stories de taille équivalente et qu’il faut 3 jours pour valider une User Story,
émettez l’hypothèse que 12 jours sont nécessaires pour livrer la fonctionnalité.
Le débit
Le débit représente le nombre d’éléments complétés à l’issue du
processus. En prenant les éléments du backlog, le débit sera le nombre
d’éléments livrés sur une période donnée (par exemple une semaine). En
faisant le ratio du nombre d’éléments par rapport au débit, vous obtenez
une estimation du temps nécessaire pour livrer une fonctionnalité à vos
utilisateurs. Dans notre exemple de fonctionnalité contenant 4 User Stories,
et en considérant un débit de 2 User Stories terminées par semaine, comptez
deux semaines pour livrer la fonctionnalité.
Planifier les développements
Anticiper les dépendances avec les autres équipes
Gérer les dépendances fait partie du quotidien des Product Managers,
particulièrement au sein d’organisations où plusieurs équipes doivent
collaborer. Les dépendances apparaissent lorsqu’une équipe ne peut pas
atteindre son objectif en toute autonomie et nécessite le développement
d’une fonctionnalité, d’un chantier technique ou la résolution d’un bug
par une autre équipe. Afin de planifier le plus efficacement possible les
Construire le produit
développements, il est important de détecter les dépendances le plus
en amont possible, notamment grâce aux discussions menées pendant
les refinements. Une fois les dépendances identifiées, vous devez vous
coordonner avec les Product Managers des équipes impactées afin de
vous accorder sur les priorités et ajuster vos développements. Si besoin,
vos Product leaders peuvent également vous aider à aligner vos différentes
priorités.
133
MODULE №3

MODULE №3
Qu’est-ce que le PI planning ?
Réaliser un release plan

Le release plan est utilisé pour planifier le développement des

Le PI planning (Product Increment planning) est une cérémonie de
planning à grande échelle. D’une durée d’un à deux jours, il réunit
dans la même pièce les différentes équipes impliquées dans le
développement d’un produit. Au cours de cette cérémonie, les équipes
planifient les développements des 8 à 12 semaines à venir en identifiant
et en prenant en compte les dépendances entre tous.
fonctionnalités à court terme, contrairement à la roadmap qui donne la
cadence de la stratégie à moyen/long terme. Complémentaire à la roadmap,
le release plan doit contenir :
◉ Le nom de la release et la date. Vous pouvez indiquer une date
précise si elle est fixe ou un horizon de temps (mois, semaine, etc.) ;

◉ Les fonctionnalités principales contenues dans la release

Itération Itération Itération Itération
1.1 1.E 1.T 1.]

Release plan de l’équipe Activation

Milestones Bêta V1

Release 1 Release  Release Ì

Team A Fonctionnalité 1 Fonctionnalité
Identifer des restaurants prooimitt de soi

Filtrer la liste de restaurants Pré´±isualiser le détail de

Team B Dépendance 3 Améliorer la géolocalisation par rapport à mon adresse carte du restaurant depuis la
map

Visualiser les restaurants A\uster le raXon de

sur une carte recherche «à proximité»
Team 4 Dépendance 1

Encourager la première Module «Suggestion de la semaine»

Team D Dépendance commande

Ofrir un code de réduction Suggérer des restaurants Permettre à l’utilisateur

lors de la première d’indiquer qu’il n’est pas
commande Suggérer des épiceries intéressé

Vous pouvez construire votre release plan en utilisant par exemple

le template Go product roadmap de Roman Pichler, auteur et formateur
reconnu. Malgré son nom qui peut porter à confusion, celui-ci à l’avantage
Construire le produit

Construire le produit
de présenter la temporalité, l’objectif, les fonctionnalités et éventuellement
les métriques à suivre après la mise en production pour mesurer l’atteinte
de l’objectif fixé.

134 135
MODULE №3

MODULE №3
La Go Product Roadmap (template)
Nos conseils
date / période
◉ Pour faciliter les estimations, comparez deux éléments du backlog
nom de la entre eux pour identifier le plus complexe. Au fur et à mesure,
Release 1 Release ! Release # vous pouvez déterminer quel élément est de taille M par rapport à
release
un L par exemple, et ainsi établir un référentiel.

objectif ◉ Vous serez parfois tiraillé·e entre vos parties prenantes qui
exigent une date de livraison précise, et votre équipe qui craint
qu’une date ne soit perçue comme un engagement ferme. Soyez
pédagogue, rappelez qu’il est important de donner de la visibilité
pour permettre aux autres équipes de s’organiser, mais aussi que
les prévisions peuvent bouger.

◉ Lorsque vous faites votre release plan, pensez à garder de la bande

fonctionnalités passante pour les plus petits sujets que vous n’aurez pas planifiés
comme la correction d’anomalies ou de petites améliorations.
Pour cela, évitez de surcharger les releases et indiquez qu’un
pourcentage de la capacité de l’équipe sera dédié à ses sujets.

métriques suivies

Le release plan sert avant tout à piloter et synchroniser l’équipe autour

de l’objectif commun. Tout comme les autres outils de l’équipe Produit,
il est mis à jour au fur et à mesure de l’avancement des développements
(après chaque fin de sprint ou mise en production) afin de refléter au mieux
la situation actuelle.
Construire le produit

Construire le produit
136 137
MODULE №3

MODULE №3
CHAPITRE 13 Exemple de management visuel

Ready to dev In roress In test Ready to Done

Suivre l’avancement
release

et gérer les imprévus Fast lane

(user story
prioritaires)

À mesure que les développements avancent, les estimations liées à

la date de livraison d’une fonctionnalité se précisent. Vous pouvez ainsi
donner plus de visibilité à vos parties prenantes. Bonne nouvelle, des outils
existent pour vous aider à suivre l’avancement de l’équipe Produit et ajuster
vos estimations en toute transparence.

US Bloquées

Suivre l’avancement des
développements
L’importance du management visuel
Particulièrement plébiscité en Kanban, le management visuel est un
outil puissant pour suivre les développements et mettre en évidence les
blocages éventuels. À partir des indicateurs de cycle time (chapitre 11) ou
lors de vos échanges réguliers avec l’équipe, vous pouvez identifier lorsqu’un
élément du backlog passe plus de temps que prévu dans une étape et prend
ainsi du retard. Nous vous conseillons alors d’utiliser un code visuel propre
à votre équipe pour mettre en évidence ce blocage (un flag sur Jira, une
gommette sur un Post-it, etc.). Au cours des jours suivants, vous pouvez
ainsi surveiller l’avancement du sujet plus attentivement et prendre des
actions concrètes pour débloquer la situation si nécessaire.
Construire le produit
Le burn-down
Le burn-down permet de suivre l’avancement des développements
sur un sprint, plusieurs sprints ou plusieurs semaines. Le burn-down est
une représentation graphique du périmètre restant à faire, c’est-à-dire
l’ensemble des User Stories qui ne remplissent pas encore les critères de
votre Definition of Done (chapitre 14). L’abscisse du graphique montre le
temps (sprint, jour ou semaine) tandis que l’ordonnée indique le nombre
de points de complexité ou de User Stories du périmètre. En utilisant les
indicateurs de vélocité ou de débit (chapitre 12) vous pouvez tracer la
trajectoire idéale à avoir. En mettant régulièrement à jour le burn-down en
fonction du rythme réel de développement, il est plus facile de comparer
l’avancement des développements à vos prévisions.
Burn-down d’un sprint Burn-down d’un projet
Story point Nb d’us et tâches
25 30

Construire le produit
20 Traeire 25
idéale
20
15
15
Travail réalisé
10
10
5 5
Jours Se>@ines
2 4 6 8 10 12 14 2 4 6 8

138 139
MODULE №3

MODULE №3
Le burn-up En cas d’imprévu, ajuster et informer
Similaire au burn-down, le burn-up se construit aussi sur la base du
nombre de points de complexité ou de User Stories. Cette fois, le graphique Traiter un blocage sur un sujet en cours
représente le périmètre réalisé et est particulièrement utile pour faire le de développement
suivi sur plusieurs sprints ou semaines. En mesurant la vélocité ou le débit
de façon régulière, vos hypothèses se précisent sur : Malgré tous vos efforts d’estimation et de prédictibilité, il arrive parfois
qu’un imprévu bloque l’avancée des développements :
◉ La date d’atterrissage du périmètre choisi (MVP, 1re version…).
◉ La solution technique envisagée n’est pas réalisable ;
◉ Le périmètre que vous serez en mesure de livrer à une date donnée.
◉ Un problème de dette technique vous empêche d’avancer comme
prévu ;
Exemple d’utilisation d’un burn-up
◉ Une dépendance n’avait pas été détectée en amont ;
Story point / Nb. d’us Estimation Story point / Nb. d’us
moyenne ◉ Une absence imprévue dans l’équipe.
160 160
Estimation
optimiste Estimation
120
Si cela se produit, rapprochez-vous rapidement des bonnes personnes
120 pessimiste
pour identifier et résoudre le problème. N’hésitez pas à libérer du temps à
l’équipe pour mener un travail d’investigation plus poussé, redécouper la
80 80
User Story pour livrer une partie du périmètre seulement ou bien revoyez la
priorisation pour résoudre le problème avant de passer sur un autre sujet.
40 40

2 4 6 8
Sprints /!
10 nb. de 2 4 6 8
Sprints /!
10 nb. de
Ajuster les timings et donner un indice
semaines semaines de confiance
Lors de la semaine 7/sprint 7 on pourra Le dea pourra sortir entref
livrer entre 108 et 158 points les sprints 6 et X Les outils que nous vous avons présentés plus haut vous aident à
détecter d’éventuels retards dans les développements. Vous devez utiliser
ces éléments pour ajuster vos hypothèses de livraison et votre release plan
(chapitre 12). C’est encore plus vrai si d’autres équipes sont impactées par
la livraison d’une fonctionnalité. Il peut s’agir d’une autre équipe qui est
dépendante de ce développement pour avancer ou d’un autre département
— le marketing ou le service client — qui attend la livraison de la
fonctionnalité pour lancer une campagne ou répondre à des clients.

En complément de ces réajustements de temporalité, vous pouvez

utiliser un indice de confiance sur la date de livraison à communiquer
Construire le produit

Construire le produit
également à vos parties prenantes. Votre indice de confiance est influencé
par différents éléments comme le niveau de dépendance par rapport à
une autre équipe, le niveau d’incertitude quant à la solution technique
envisagée, ou le nombre de parties prenantes devant intervenir dans la
validation des développements. Bien sûr, plus vous vous rapprochez de la
fin des développements, plus l’incertitude sur la date d’atterrissage diminue
et plus votre indice de confiance augmente.
140 141
MODULE №3

MODULE №3
Nos conseils
◉ Communiquez régulièrement et rendez accessible l’information
sur l’avancement des développements. Cela peut vous éviter de
devoir répondre de manière individuelle aux questions des parties
prenantes.

◉ Soyez transparent·e sur les éventuels blocages en expliquant les

raisons des retards et les moyens mis en place pour y remédier.

◉ Soyez vigilant·e lorsque vous utilisez les burn-up et burn-down

pour communiquer. Seuls, ces outils peuvent être utilisés à
mauvais escient, pour évaluer la performance des équipes ou la
capacité à produire. Ils se concentrent sur le résultat sans mettre
en lumière les causes des éventuels retards ou blocages.
Construire le produit

Construire le produit
142 143
MODULE №3
CHAPITRE 14
Livrer les
fonctionnalités
Quand les développements touchent à leur fin et les fonctionnalités sont
presque prêtes à être livrées, vous devez vous assurer que ces dernières
répondent bien aux critères d’acceptation des User Stories et correspondent
à la Definition of Done, sans mettre en défaut le produit existant.
Tester les fonctionnalités
Dans l’équipe, chacun a un rôle à jouer pour couvrir les tests techniques
et fonctionnels de chaque fonctionnalité et permettre de mettre à disposition
des utilisateurs des fonctionnalités de qualité :
◉ Les développeurs testent leurs développements en intégrant
des tests techniques ;
◉ Les Product Designers et Product Managers réalisent des tests
fonctionnels visant à valider la conformité des développements par
rapport à l’attendu décrit dans les User Stories et aux maquettes ;
◉ Les Testeurs rédigent, exécutent et maintiennent des
campagnes de tests fonctionnels poussés, automatisés ou non.
Construire le produit
144
MODULE №3
Zoom sur les tests techniques
◉ Les tests unitaires vérifient si le produit fonctionne bien au
niveau de l’implémentation du code. Ils sont des garde-fous
contre les régressions.
◉ Les tests d’intégration vérifient si l’application dialogue bien
avec les autres parties applicatives.
◉ Les tests de performance, de charge ou de résilience véri-
fient si l’application est robuste et résiste aux nombreuses
utilisations.
Réaliser les tests d’acceptation
Les tests d’acceptation vérifient que les fonctionnalités développées
remplissent les critères d’acceptation des User Stories (chapitre 10). Vous
pouvez rédiger les tests d’acceptation en utilisant le BDD (Behaviour-
Driven Development). Inventé par Dan North, le BDD consiste à rédiger
des tests décrivant le comportement attendu de la fonctionnalité dans un
langage compréhensible par tous et avec des exemples concrets. L’objectif
est de faciliter la compréhension de l’attendu fonctionnel entre vous, les
développeurs, les testeurs et de facilement tester les User Stories. Lors de
la validation d’une User Story, vous pouvez vous référer à la liste de critères
d’acceptation, dérouler l’ensemble des scénarios de test et ainsi vérifier que
chaque critère est bien respecté.
Vous pouvez uniformiser la syntaxe des tests d’acceptation en utilisant
le langage Gherkin. Ce langage est basé sur une syntaxe standardisée, qui se
présente sous la forme suivante :
GIVEN (étant donné que) : les prérequis à la bonne exécution du test.
WHEN (quand) : action à réaliser.
Construire le produit
THEN (alors) : résultat attendu.
La structure Gherkin facilite non seulement la lecture, mais permet
également d’être réutilisée pour alimenter l’automatisation de tests.
145
MODULE №3

MODULE №3
Pour chaque User Story, et plus particulièrement pour chaque critère
d’acceptation de votre User Story, vous pouvez ainsi rédiger un ou plusieurs
Règle métier
tests en Gherkin. L’objectif n’est pas de paraphraser les règles métier, mais Règle métier
Règle métier
N’utiliser le code qu’une
bien de donner des exemples précis, notamment pour des cas d’erreurs ou Appliquer la remise sur
Renseigner un code valide seule fois lors de la
les paniers de plus de 25€
des cas à la marge. première commande

Cas à la marge Cas à la marge

Tests d’acceptation d’une User Story
Given
de l’équipe Activation Un utilisateur n’ayant jamais
fait de commande ET ayant
un panier égal à 28€ sur
User story Thiga Eats
En tant que nouvel utilisateur, je souhaite utiliser mon code de réduction de 10% sur ma
When
première commande, aon de prooter de mon o re de bienvenuen
L’utilisateur renseigne le
code WELCOME puis clique
sur le bouton «Appliquer le
codeG
Règle métier
Règle métier Then
Règle métier N’utiliser le code qu’une
Appliquer la remise sur Une remise de e0T
Renseigner un code valide seule fois lors de la
les paniers de plus de 25€ s’applique sur sa commande
première commande et le total de la commande
devient 25,20€
Given
Un utilisateur n’ayant jamais
fait de commande ET ayant
un panier égal à 28€ sur
Thiga Eats
When
L’utilisateur renseigne le
code WELCOME puis clique
sur le bouton «Appliquer le
codeG
Then
Une remise de e0T
s’applique sur sa commande
et le total de la commande
devient 25,20€

Cas passant

Given
Un utilisateur n’ayant jamais fait de commande ET ayant un
panier égal à 28€ sur Thiga Eats
Note : le cas passant est
When identique pour toutes les
L’utilisateur renseigne le code WELXkWE puis clique sur le
règles car il doit respecter
l’ensemble des critères
Assurer les tests de non-régression
bouton «Appliquer le code» d’acceptation pour –tre valide
Then Avant de déployer une nouvelle fonctionnalité, il est important de vous
Une remise de 10% s’applique sur sa commande et le totaƒ assurer qu’elle n’impacte pas négativement le fonctionnement global du
de la commande devient 25,20€
produit. Pour cela, menez des tests dits de non-régression. Ces tests peuvent
toutefois rapidement devenir chronophages. Vous devez donc prioriser les
Cas non­passant Cas non­passant Cas non­passant
cas à tester (les parcours à fort trafic, les cas d’usages les plus critiques…).
Given Given Given
L’automatisation des tests est également une stratégie intéressante pour
Un utilisateur n’ayant jamais Un utilisateur n’ayant jamais Un utilisateur réalisant une
fait de commande ET ayant fait de commande ET ayant commande de 28€ sur Thiga faciliter les campagnes de tests de non-régression. Selon les organisations, les
un panier égal à 28€ sur un panier égal à 23€ sur Eats ET l’utilisateur a déjà tests automatisés peuvent être mis en place directement par les développeurs
Thiga Eats Thiga Eats utilisé le code
lors de l’implémentation d’une User Story ou par un testeur automaticien.
When When When
L’utilisateur renseigne le L’utilisateur renseigne le L’utilisateur renseigne le
code BIENVENUE puis clique code WELCOME puis clique code WELCOME puis clique
Construire le produit

Construire le produit
sur le bouton «Appliquer le sur le bouton «Appliquer le sur le bouton «Appliquer le
code» code» code» Adapter vos efforts de test
Then Then Then
Un message d’erreur Un message d’erreur Un message d’erreur En fonction de la maturité de votre produit, du type de fonctionnalité,
s’a iche en rouge sous le s’a iche en rouge sous le s’a iche en rouge sous le du contexte concurrentiel ou légal, votre stratégie de test pour les nouvelles
champ «Le code renseigné champ «Xe code n’est champ «Le code n’est
n’est pas bon» valable que pour les valable que lors de la fonctionnalités ne sera pas équivalente. En équipe, vous devez définir la pro-
Le total de la commande paniers de plus de 25€» première commande» fondeur des tests que vous souhaitez mener. Elle sera reflétée à travers le
reste 2ë€ Le total de la commande Le total de la commande
reste 23€ reste 2ë€ nombre de tests d’acceptation à dérouler et dans l’investissement dans la
146 147
MODULE №3
Quality Assurance (QA). Ayez néanmoins en tête que vous ne pouvez probable-
ment pas couvrir l’ensemble des cas à la marge. Acceptez que pour certains
utilisateurs minoritaires, le fonctionnement ne sera pas totalement optimisé.
Dans une équipe qui requiert une QA minutieuse, le renfort de testeurs
dédiés à l’équipe est un avantage de taille. Toutefois, si vous n’avez pas de
testeurs, assurez-vous de bien collaborer avec l’équipe de développement
et vous libérer du temps pour tester de manière convenable. Lorsque cette
situation devient trop contraignante et influe sur la qualité de la discovery
(car vous avez peu de temps à y consacrer) ou la vélocité de l’équipe (car les
développeurs passent trop de temps sur les tests), proposez à votre Product
leader de mettre en place une réelle équipe QA qui pourra vous aider dans
l’optimisation et l’automatisation des tests.
Déployer des fonctionnalités
Vérifier la Definition of Done
Tout comme la Definition of Ready (chapitre 11), la Definition of Done
(DoD) est un contrat passé avec l’équipe de développement, et regroupe
sous forme de liste l’ensemble des critères que doit respecter une User Story
pour être considérée comme terminée. Votre rôle est notamment de vérifier
qu’une revue de code a été réalisée, que les tests d’acceptation sont validés,
que la documentation est à jour et que le taggage est bien implémenté.
Definition of Done de l’équipe Activation
DoD — Équipe activation
Les tests unitaires sont implémentés
Les tests d&acceptation ont été passés
Le :roduct 9esi1ner a .alidé l&2= con@ormément
aux maquettes
Construire le produit
L&2V a été testée sur l&en.ironnementS
de pré-production
La h` a .alidé l&2V
Les tests de non-ré1ression sont passés a.ec
succès
148
MODULE №3
La DoD doit rester factuelle, réaliste et être exhaustive. Néanmoins,
elle peut évoluer pour réajuster le niveau de qualité lorsque nécessaire.
Une fois que vos User Stories valident la DoD, vous pouvez déployer les
fonctionnalités en production.
Quand mettre en place une réunion Go/No Go
de déploiement ?
Lorsque vous travaillez sur un sujet risqué qui nécessite une validation
par une équipe spécifique, ou lorsque vous lancez une nouvelle
fonctionnalité qui impacte plusieurs équipes et qui requiert une
coordination des activités de lancement (plusieurs mises en production
successives dans le cas d’un partenariat, formation d’équipes sur le
terrain…), vous devez porter une attention particulière à la décision de
mettre en production. Dans ce cas, mettez en place une réunion où les
parties prenantes peuvent décider de déployer ou non, et surtout de
valider les étapes de lancement.
Livrer en continu ou en release
Lorsque l’équipe considère que la fonctionnalité peut partir en
production, vous avez le choix entre livrer la fonctionnalité immédiatement
aux utilisateurs ou attendre pour mettre à disposition un ensemble de
fonctionnalités cohérentes. Voici les différentes approches :
◉ La livraison en continu : les fonctionnalités sont mises en
production dès lors que les User Stories remplissent les critères
de la Definition of Done. L’avantage de cette approche est qu’elle
permet de livrer le plus rapidement possible les fonctionnalités afin
de récolter du feedback. Néanmoins, cette approche implique un
découpage en User Stories indépendantes qui apportent une valeur
pour être livrées seules aux utilisateurs.
◉ La création de release : plusieurs fonctionnalités sont regroupées
pour former un incrément Produit cohérent à livrer. La release
permet de livrer un bloc fonctionnel plus complet aux utilisateurs.
Construire le produit
Cette approche est à privilégier lorsque les équipes ont de fortes
dépendances ou lorsque vous travaillez sur un produit pour
lequel le niveau d’exigence est élevé. Pour une API bancaire par
exemple, le risque de livrer aux utilisateurs un mode dégradé d’une
fonctionnalité sur laquelle on itérera plus tard est trop important.
On préférera livrer une release plus complète permettant d’assurer
le niveau de qualité et de sécurité attendu par les utilisateurs.
149
MODULE №3

MODULE №3
Les activités post-déploiement
Nos conseils
Vérifier la production
◉ N’attendez pas que vos User Stories soient terminées pour
Une fois la livraison effectuée et si votre produit vous le permet, tester ! Tester en local avec les développeurs peut aider à détecter
n’hésitez pas à faire une vérification rapide en production. Si vous détectez quelques ajustements très rapidement.
un problème ou une anomalie, vous pouvez :
◉ Les tests fonctionnels ne sont pas uniquement l’affaire des Product
◉ Réaliser un rollback en revenant à la version antérieure de Managers, surtout si vous n’avez pas de testeurs dans l’équipe.
l’application pour restaurer instantanément le bon fonctionnement Les développeurs peuvent réaliser des tests croisés au moment
de votre produit, puis enquêter sur le problème sereinement ; du code review pour vérifier le fonctionnel développé par un pair.

◉ Réaliser un hotfix en livrant rapidement un correctif. ◉ Assurer un haut niveau de qualité produit est un processus au-delà
des tests ! Plus vous collaborez en amont des développements
sur le refinement et la rédaction des critères d’acceptation avec
Activer les fonctionnalités avec un feature flag votre équipe, ainsi que sur le respect de la DoR, plus vous validerez
facilement l’étape de tests.
Un feature flag ou feature toggle est une technique permettant d’activer
ou désactiver facilement une fonctionnalité en production, sans nécessité
de déploiement spécifique. Grâce au feature flag, vous pouvez livrer vos
fonctionnalités en production et ne les activer que plus tard ou que pour
une cible dédiée. Cette technique présente de nombreux avantages :

◉ Offrir plus de flexibilité à l’équipe en dissociant le déploiement de

la mise à disposition de la fonctionnalité aux utilisateurs ;

◉ Faciliter le rollback en cas de problème en désactivant la

fonctionnalité le temps de réaliser les correctifs nécessaires ;

◉ Rendre disponible progressivement une fonctionnalité en l’activant

pour un public limité avant de la rendre accessible à l’ensemble des
utilisateurs ;

◉ Faciliter la gestion des tests de propositions de valeur (chapitre 8)

ou expérimentations (chapitre 18) en les activant sur des cibles pré-
cises en un temps limité.
Construire le produit

Construire le produit
150 151
MODULE №3
CHAPITRE 15
Gérer le lancement
des fonctionnalités
Votre nouvelle fonctionnalité est disponible et vous voulez la faire
connaître ! Pour ce faire, il vous faut communiquer à la fois en interne et en
externe pour faciliter son adoption et vous assurer de récolter rapidement
des feedbacks. Les Product Marketing Managers seront vos plus grands
alliés pour construire une stratégie de Go-To-Market efficace et cohérente.
Les activités du Product Marketing
Manager
Communiquer sur les nouveautés peut nécessiter un effort plus poussé
avec une réelle stratégie de positionnement et de Go-To-Market. Réel lien
entre la partie commerciale et la partie Produit, le·la Product Marketing
Manager (PMM) va notamment vous aider à :
◉ Étudier le marché pour connaître l’environnement concurrentiel,
comprendre qui est l’acheteur et contribuer à la stratégie Produit
(chapitre 1) ;
◉ Trouver le message impactant qui met en valeur les caractéristiques
et les avantages des fonctionnalités ;
◉ Aider à bien vendre le produit, coordonner la communication et
s’assurer d’une mise sur le marché sans douleur ;
Construire le produit
◉ Coordonner les lancements de plusieurs fonctionnalités ou produits.
152
MODULE №3
Le Product Marketing, lien entre la partie commerciale et
le Product Management
Sales
& business
Product
marketing
Product
management Tech
Informer les équipes en interne
Communiquer et collecter du feedback
La communication auprès des parties prenantes est une activité cœur
des Product Managers. Un des temps forts sur lequel il faut porter une
attention toute particulière est la sortie de nouvelles fonctionnalités pour
communiquer sur les changements, l’impact attendu, le périmètre… Pour
cela, vous disposez de plusieurs leviers vous permettant notamment d’assurer
que les parties prenantes soient au courant des nouvelles fonctionnalités :
◉ La release note (interne) : c’est un message succinct pour
communiquer rapidement sur les nouveautés. Dans votre release
note interne, décrivez brièvement la fonctionnalité, rappelez
l’impact attendu, donnez le lien vers la documentation pour trouver
des informations plus détaillées et remerciez toutes les personnes
qui ont contribué à la sortie de cette nouvelle fonctionnalité.
Construire le produit
153
MODULE №3

MODULE №3
Une release note interne de l’équipe Activation Gérer le lancement de vos nouvelles
fonctionnalités

Communiquer sur les nouveautés

Maintenant que vos équipes internes sont alignées, il est temps de

◉ La review : c’est un rendez-vous pour faire la démo de la
fonctionnalité et recevoir du feedback en instantané. La review
vous permet d’échanger plus en profondeur sur les spécificités et le
fonctionnement de votre fonctionnalité, répondre aux questions de
vos parties prenantes et collecter du feedback en direct.
Documenter efficacement
La communication de vos nouvelles fonctionnalités passe aussi par la
documentation. Documenter vous permet d’affiner la maîtrise des subtilités
de votre produit et vous fait gagner du temps lorsque vous devez expliquer
plus en détail son fonctionnement. Consolider la connaissance Produit au
même endroit permet de créer une unique source de vérité. Vous pouvez ainsi
inciter les équipes à se référer à la documentation lorsqu’ils en ont besoin.
penser à informer vos clients (ceux qui achètent) et vos utilisateurs (ceux
qui utilisent) des améliorations. Cette activité pourra être réalisée par votre
Product Marketing Manager. En l’absence de PMM, vous devez prendre une
partie de la responsabilité et la partager avec l’équipe marketing et/ou
l’équipe commerciale. Essayez d’identifier les besoins clés des équipes pour
qu’elles puissent prendre le relais : envisagez un briefing pour expliquer
pourquoi vous avez développé ce produit ou cette fonctionnalité, faites-
leur une démonstration… Identifiez les canaux de communication les plus
appropriés pour votre lancement. Pour vous aider, voici quelques idées :
◉ La release note (externe) : affichée directement dans votre produit,
votre newsletter ou sur le store pour une application mobile, c’est
un bon moyen d’attirer l’attention de votre utilisateur ou client
sur de nouvelles fonctionnalités, tout en renforçant le lien qu’ils
entretiennent avec votre marque.

Pour être comprise de tous, il est important que la documentation

soit claire, concise et sans jargon technique. Pour ce faire, rédigez la
documentation d’un point de vue utilisateur, expliquez pourquoi vous avez
décidé d’implémenter la fonctionnalité et en quoi elle consiste avant de
détailler son fonctionnement pas à pas. Vous pouvez aussi maintenir un
glossaire pour les termes spécifiques au métier et ajouter des captures
d’écran pour faciliter la compréhension. Pensez également aux supports
annexes tels que les FAQ et How-to pour former les équipes service client
qui devront répondre aux questions des utilisateurs.
Construire le produit

Construire le produit
Voyez la documentation comme un produit, elle est le reflet de
votre propre produit et doit donc évoluer avec lui. Répartir l’effort de
documentation dans le temps rend la tâche moins rébarbative, tout en
évitant de perdre de l’information. Pour veiller à l’actualiser à chaque
itération, vous pouvez intégrer dans votre Definition of Done le fait d’avoir
rédigé la documentation de la fonctionnalité.

154 155
MODULE №3

MODULE №3
Une release note externe de l’équipe Activation Accompagner les utilisateurs

Avant un lancement, évaluez la nécessité de prévoir un onboarding

pour accompagner vos utilisateurs et pensez à la manière dont ils vont
9:41
s’approprier le produit ou la fonctionnalité. Est-elle bien visible au cours du
parcours ou nécessite-t-elle un accompagnement spécifique ? Si oui, la mise
en place d’un parcours d’onboarding est probablement nécessaire. Celui-ci
consiste à présenter la fonctionnalité au sein même de votre application. De
manière séquentielle, présentez à l’utilisateur le bénéfice puis le parcours
qui a été pensé pour lui. Essayez de déclencher l’onboarding à un moment
pertinent et présentez-le une seule fois en permettant à l’utilisateur de le
passer s’il le souhaite.

Nos conseils
◉ Soyez transparent·e et adaptez votre langage aux différents
interlocuteurs. Plus vous prendrez soin de clarifier, simplifier
sans utiliser de jargon… meilleurs seront les retours que vous
pourrez recevoir sur vos fonctionnalités.

◉ L’objectif de la communication interne et de la documentation est

d’informer et partager la connaissance. Misez sur des formats
percutants : message Slack, quiz, vidéos, rendez-vous mensuels…

◉ Bloquez du temps pour documenter ! Le vendredi par exemple,

quand les urgences de la semaine sont passées, est un moment
idéal…
◉ Les campagnes d’acquisition et awareness : si vous venez
de lancer une fonctionnalité majeure ou une nouvelle offre qui
nécessite une communication particulière, pensez à des campagnes
d’acquisition ou d’awareness via des campagnes publicitaires,
newsletter ou un e-mail bien ciblé.
Construire le produit

Construire le produit
156 157
 MODULE №3
L’essentiel
de ce module

1. Le backlog est un outil regroupant les éléments qui constituent le

produit. Il évolue et se précise au cours des activités de refinement.

2. Le backlog refinement est un ensemble d’activités menant à des

discussions en équipe et qui ont pour objectif de s’accorder sur une
vision commune des fonctionnalités à livrer et de les spécifier.

3. L’Agilité est le cadre qui vous permet de livrer les fonctionnalités

Produit le plus rapidement possible par petits incréments successifs.

4. Vous ne pouvez pas prédire une date exacte de sortie pour vos
fonctionnalités, mais des outils peuvent vous aider à émettre une
hypothèse, quitte à la réajuster en cours de développement pour
donner de la visibilité à vos parties prenantes.

5. Le release plan est complémentaire à la roadmap et permet de

planifier le développement des fonctionnalités à court terme.

6. La qualité est l’affaire de toute l’équipe, différents types de

tests fonctionnels et techniques vous permettent de valider les
développements.

7. En plus des tests, d’autres moyens vous assurent de livrer des

fonctionnalités de qualité et dans de bonnes conditions : les critères
d’acceptation, la Definition of Done, la livraison en continu, le feature
flag…

8. Lors des lancements, pensez à communiquer de manière proactive

Construire le produit
en interne auprès de vos parties prenantes et en externe auprès de
vos utilisateurs.

9. Les Product Marketing Managers sont une aide précieuse pour

assurer un lancement efficace de nouvelles fonctionnalités.

159
4—
Améliorer
en continu
« Les équipes Produit
doivent adopter une
culture d’expérimentation,
d’apprentissage et
d’amélioration continue. Il
s’agit d’être adaptable, et
d’utiliser les données et
les feedbacks pour guider
la prise de décision. »
— Melissa Perri
MODULE №3
Le cycle de vie du produit ne s’arrête pas à sa mise
en production ! L’amélioration continue d’un produit est
essentielle pour garantir sa réussite à long terme. Le monde
est en constante évolution, les tendances du marché et les
attentes des utilisateurs changent rapidement. Il est de votre
responsabilité de garantir que votre produit reste compétitif
et pertinent en mesurant l’impact sur les utilisateurs et
l’entreprise. Vos pratiques en tant qu’équipe et le travail de
collaboration avec vos parties prenantes sont aussi clés pour
la réussite du produit. Dans ce module, nous vous aiderons
à définir les mesures de succès, collecter et analyser les
données pour faire des choix pour le produit. Nous aborderons
comment concilier discovery et delivery en continu pour faire
évoluer votre produit, qu’il s’agisse d’enrichir, d’optimiser ou
Construire le produit
de supprimer des fonctionnalités. Nous verrons comment
veiller à assurer la qualité du produit à long terme. Enfin, nous
verrons quelles démarche et posture adopter pour collaborer
avec l’équipe et les parties prenantes pour faire vivre votre
produit et ainsi maximiser son impact.
161
MODULE №4
CHAPITRE 16
Définir les mesures
de succès
L’une de vos principales responsabilités est de vous assurer que le produit
dont vous êtes responsable apporte de la valeur, à la fois aux utilisateurs et à
l’entreprise. Aussi, pour mesurer le succès d’un produit, de nombreux facteurs
doivent être pris en compte, tels que la satisfaction client, la fréquence
d’utilisation, la croissance des revenus, la part de marché… Nous verrons
dans ce chapitre comment mesurer le succès des fonctionnalités du produit et
les mesures les plus pertinentes à mettre en place.
Comment mesurer le succès
Être data-informed
À chaque étape du processus Produit, la donnée vous aide à prendre les
bonnes décisions grâce à des signaux que vous devrez interpréter. S’il ne
s’agit pas de vous laisser dicter vos choix par les chiffres, on attend de vous
d’être data-informed, c’est-à-dire d’enrichir vos intuitions et vos observations
pour soutenir vos décisions. « Sans data, vous êtes juste une autre personne
avec une opinion. Sans opinion, vous êtes juste une autre personne avec de la
data » comme le dit si bien le statisticien américain W. Edwards Deming.
Être data-informed signifie collecter des données pour en générer des
insights (chapitre 3). À vous de partager et d’échanger des informations
avec vos parties prenantes, confronter les analyses pour en tirer des
Améliorer en continu
apprentissages et faire des choix.
162
MODULE №4
Data, KPI, Métrique : quelle différence ?
◉ La data est une donnée brute. Elle est collectée, stockée et
traitée afin d’être utilisée pour suivre des métriques ou des
KPIs, comme le nombre d’utilisateurs actifs par exemple.
◉ Une métrique est une mesure obtenue à partir de données
brutes. Elle transforme ces données en mesure significative
qui permet d’évaluer la performance d’un produit, comme le
nombre d’utilisateurs actifs mensuel par exemple.
◉ Un KPI est un indicateur de performance clé qui mesure les
éléments les plus importants pour votre produit et l’atteinte
de vos objectifs à long terme. Il évalue l’état de santé de votre
produit, comme 75 % d’utilisateurs actifs mensuels sur le
trimestre par exemple.
Mesurer le succès à différents niveaux
Le succès de votre produit peut se mesurer à différents niveaux. Vous
pouvez suivre des KPI liées à l’atteinte de vos objectifs, l’impact de vos
fonctionnalités, mais aussi à la performance générale du produit.
Mesurer l’atteinte de vos objectifs
Lorsque vous définissez des objectifs pour votre équipe, vous devez
aussi définir des KPIs associés pour vous permettre de mesurer l’atteinte de
ces objectifs (chapitre 2). Ce sont les principaux KPIs à suivre pour évaluer
l’atteinte des ambitions que vous vous êtes fixées.
Mesurer l’impact de vos fonctionnalités
Lorsque vous lancez de nouvelles fonctionnalités, il est probable qu’elles
ne répondent pas parfaitement aux besoins de vos utilisateurs, et même si
vous avez pris la peine de tester soigneusement vos pistes de solution en
amont. Vous serez probablement amené à réaliser des ajustements et itérer
Améliorer en continu
en fonction des retours clients. Pour vous aider à mesurer cet impact, nous
vous conseillons de suivre des métriques liées à vos fonctionnalités. On
peut suivre par exemple :
163
MODULE №4
◉ L’usage et l’engagement des utilisateurs (taux d’usage, nombre
d’utilisations par utilisateur) ;
◉ La conversion et le taux de rebond ;
◉ Les performances techniques (temps de chargement, taux de crash).
Mesurer la performance du produit
Votre produit ou le périmètre sur lequel votre équipe intervient, de
par sa contribution à la performance générale de l’entreprise, a un impact
global que vous pouvez suivre grâce à des métriques d’impact telles que :
◉ L’usage du produit (engagement, adoption, rétention) ;
◉ Le business apporté par le produit (conversion, revenu) ;
◉ La satisfaction de vos utilisateurs (NPS, CSAT) ;
◉ La stabilité et la performance technique globale de votre produit.
Il se peut que vous suiviez déjà partiellement ces métriques si elles
sont liées directement à vos objectifs. Toutefois, vos objectifs trimestriels
peuvent vous pousser à vous concentrer uniquement sur une partie de votre
périmètre. Cela ne vous empêche pas de garder un œil sur les métriques
globales afin de vous assurer que les performances sont maintenues.
Mesurer, oui, mais quoi ?
Mesurer l’outcome
D’une manière générale, les mesures d’output (production) telles que
la vélocité (nombre de points de complexité, lignes de code, bugs…), le
développement de fonctionnalités (nombre de User Stories, nombre de
lancements…), le respect des deadlines (time-to-market) ne sont pas de
bons indicateurs de succès. S’ils peuvent être pertinents pour planifier les
Améliorer en continu
développements et donner de la visibilité (chapitre 12), ils ne mesurent pas
la création de valeur. Se concentrer sur ces mesures peut mener une équipe
à tomber dans le build trap ou le piège à produire des fonctionnalités… sans
se soucier de l’impact. En décrivant ce danger, la coach et autrice américaine
Melissa Perri met en avant l’importance pour une équipe Produit de se
concentrer sur la valeur pour les utilisateurs et l’entreprise. Ainsi, nous
vous conseillons de préférer suivre des mesures d’outcome (impact).
164
MODULE №4
Éviter les métriques de vanité
Les métriques de vanité (également appelées vanity metrics) sont des
métriques qui donnent l’impression que le produit fonctionne bien, mais
qui ne reflètent pourtant pas l’impact réel d’une action ou d’une décision. Il
est souvent difficile de les interpréter correctement.
Une bonne métrique doit aider à la prise de décision. Pour être
actionnable, elle doit :
◉ Être facile à mesurer et à comprendre ;
◉ Mesurer une évolution plutôt qu’un chiffre absolu.
Métriques de l’équipe Activation
Pour l’équipe, dont la mission est de maximiser le nombre d’utilisateurs
effectuant une première commande, on considère comme métriques
de vanité :
◉ Le nombre de nouveaux utilisateurs : bien qu’un nombre élevé
paraisse impressionnant, il ne reflète pas nécessairement
la qualité de ces nouveaux utilisateurs et leur propension à
réaliser une commande. Vous pouvez être tentés de gonfler
le nombre de nouveaux utilisateurs grâce à des techniques
agressives d’acquisition, mais cela ne vous aidera pas pour
autant à remplir votre mission.
◉ Le nombre de recherches de restaurants : un grand nombre
de recherches peut sembler positif, car il pourrait signifier
un fort intérêt des utilisateurs à réaliser des commandes.
Pourtant, il peut tout autant indiquer une forte difficulté pour
les utilisateurs à trouver ce qu’ils cherchent. La métrique est
difficilement interprétable et actionnable.
Améliorer en continu
165
MODULE №4
L’équipe utilisera plutôt les métriques suivantes :
◉ Pourcentage de croissance du nombre d’utilisateurs effectuant
une première commande : ici on s’intéresse uniquement aux
utilisateurs véritablement intéressés par le service, tout en
mesurant les progrès au cours du temps.
◉ Pourcentage de nouveaux utilisateurs effectuant une première
commande : cela permet d’évaluer la qualité des efforts
d’acquisition.
L’utilisation simultanée de ces deux indicateurs permet de s’assurer
d’attirer de plus en plus de nouveaux utilisateurs au cours du temps
et que ces derniers sont bien ciblés et intéressés par votre produit.
Les leading et lagging metrics
Pour obtenir une vue d’ensemble de la performance de votre produit,
il est important de mesurer à la fois les leading et les lagging metrics.
Les leading metrics aident à prendre des décisions éclairées, tandis que
les lagging metrics permettent de mesurer l’impact à long terme et les
domaines qui nécessitent des améliorations.
Les lagging metrics, littéralement « métriques en retard », désignent
les mesures de résultats passés. On les appelle « lagging », car l’impact
sur ces métriques arrive trop tard pour être actionnable. Il est le reflet de
décisions ou d’actions passées. C’est le cas notamment du chiffre d’affaires
qui représente le résultat annuel, mais se mesure en fin de cycle, lorsqu’il
est trop tard pour l’influencer. Si ces mesures sont indispensables, elles
sont difficiles à impacter directement par les fonctionnalités mises en
production.
À l’inverse, les leading metrics, que l’on pourrait traduire par « indicateurs
principaux », mesurent le changement immédiat. Ils peuvent être suivis
en temps réel et sont plus faciles à faire évoluer par le biais de nouvelles
fonctionnalités.
Améliorer en continu
Pour faire bouger vos lagging metrics, décomposez-les en plusieurs
leading metrics que vous pourrez impacter plus facilement. En faisant
augmenter le nombre d’utilisateurs ou de nouveaux clients, on peut prédire
une augmentation du chiffre d’affaires.
166
MODULE №4
Lagging et leading metrics de l’équipe Activation
L’équipe souhaite faire évoluer le chiffre d’affaires généré par les
premières commandes. Il s’agit d’une lagging métrique, difficile à
impacter directement. Elle identifie donc plusieurs leading métriques :
chiffre d’affaires première commande = nombre de nouveaux
utilisateurs * taux de conversion * panier moyen.
Ainsi, pour augmenter le chiffre d’affaires, l’équipe peut :
◉ Augmenter le nombre de nouveaux utilisateurs ;
◉ Augmenter le taux de conversion ;
◉ Augmenter le panier moyen.
Les Pirate Metrics
Si vous ne savez pas par où commencer, les Pirate Metrics également
connues sous le nom de AARRR framework, offrent un bon point d’entrée
pour cadrer vos KPIs. Créées par l’entrepreneur et investisseur Dave
McClure, ces métriques reposent sur cinq enjeux calqués sur les étapes de
la vie d’un utilisateur :
◉ Acquisition : mesure de performance des canaux par lesquels vos
utilisateurs accèdent à votre produit (nombre de visites par mois,
taux de conversion, coût d’acquisition…) ;
◉ Activation : mesure la capacité à activer vos utilisateurs, c’est-à-dire
les inciter à utiliser votre produit de façon significative (pourcentage
d’utilisateurs qui effectuent une action clé pour la première fois) ;
◉ Rétention : mesure la capacité à retenir vos utilisateurs activés
dans le temps (taux de rétention) ;
◉ Recommandation : mesure la propension de vos utilisateurs
Améliorer en continu
à en recruter de nouveaux par recommandation (pourcentage
d’utilisateurs qui font des recommandations, taux de conversion
des utilisateurs référés…) ;
◉ Revenue : mesure la monétisation de votre produit (conversion
d’utilisateurs gratuits en utilisateurs premium payants, le Customer
Lifetime Value…).
167
MODULE №4

MODULE №4
Pirate Metrics de l’équipe Activation

Acquisition
Acquisition
Visiteurs / mois sur la homepage
Visiteurs / mois sur la home page

Activ#tion
Visiteurs faisant une premi+re commande

R]tention
Visiteurs faisant k commande / mois

Recoxx#nz#tion
Nombre de parrainages

Revenue
Customer lifetime value =
(Panier moyen * taux de
marge) * fréquence *
durée de vie

Nos conseils
◉ Pensez à noter le KPI de votre fonctionnalité dans votre description
d’Epic pour cadrer l’ambition dès le départ et en mesurer l’impact
une fois livrée.

◉ Si vous avez défini vos objectifs sous format OKR, vous pouvez

Améliorer en continu
Améliorer en continu

identifier un KR qui est une leading metric pour mesurer l’impact

direct de vos actions et un KR qui est une lagging metric pour
mesurer l’impact long terme sur le produit.

◉ Pour suivre régulièrement le succès, passez en revue vos

indicateurs clés de performance (KPIs) chaque semaine ou chaque
mois. Portez une attention particulière au suivi lors des livraisons
de grandes fonctionnalités.
168 169
MODULE №4
CHAPITRE 17
Collecter et suivre
les données
La collecte et le suivi des données quantitatives et qualitatives sont
essentiels pour évaluer le succès d’un produit. Ces données permettent
de comprendre les besoins et les attentes des utilisateurs, d’identifier les
forces et les faiblesses d’un produit, et de prendre des décisions stratégiques
éclairées. Dans ce chapitre, nous explorerons les méthodes et les outils pour
les recueillir et les visualiser.
Collecter les données quantitatives
Qu’est-ce qu’un plan de taggage
Un plan de taggage, également appelé plan de marquage ou plan de
tracking, est un document qui décrit la manière dont les tags sont utilisés
pour collecter des données sur un site Web ou une application mobile. Les
tags sont des éléments de code qui permettent de remonter les données
sur le comportement des utilisateurs, tel que les pages visitées, les actions
effectuées, les temps de visite, etc.
Le plan de taggage détermine les événements à suivre (généralement
les actions de l’utilisateur), les variables à collecter et les règles de
déclenchement des tags.
Il est généralement élaboré en collaboration avec un Product analyst et
Améliorer en continu
les développeurs. Le plan de taggage assure une collecte de données précise
et fiable, et doit évoluer en même temps que le produit.
170
MODULE №4
Exemple de plan de taggage
Selon les organisations, plusieurs profils peuvent en être responsables.
Voici les différents cas de figure :
◉ Chaque équipe s’occupe de son plan de taggage. Dans ce cas, il
est fréquent qu’il n’y ait pas ou peu de référentiels communs et des
disparités entre les équipes ;
◉ Un référent analytics s’occupe de centraliser et rédiger les
spécifications : il accompagne l’équipe dans l’implémentation (mais
c’est bien l’équipe qui implémente), valide le bon fonctionnement et
maintient un référentiel commun ;
◉ Une équipe dédiée s’occupe de maintenir le plan de taggage.
Dans le cas de systèmes complexes, ou de larges portfolios de
produits ou de marques, il est possible qu’une équipe dédiée soit
chargée de créer et maintenir le plan de taggage.
Améliorer en continu
Créer le plan de taggage
Le plan de taggage doit être défini avant le développement, lorsque
vous décidez quelles mesures vont permettre d’évaluer l’impact d’une
fonctionnalité. Lorsque vous élaborez le plan, prévoyez un taggage
suffisamment granulaire pour permettre une analyse du comportement
de vos utilisateurs. Au moment d’évaluer le taux d’abandon d’un parcours
utilisateur, pensez à le faire pour chaque étape individuelle plutôt que pour
171
MODULE №4
l’ensemble du parcours. Si vous ne le faites pas, il est possible que vous
vous rendiez compte que les performances de votre fonctionnalité sont
insuffisantes, sans savoir quoi faire pour améliorer la situation.
Il est également indispensable de prévoir le taggage nécessaire au suivi
de vos objectifs Produit. Sans cela, vous ne pouvez pas savoir comment les
livraisons affectent vos objectifs.
Que ce soit pour le taggage des fonctionnalités ou du produit en général,
voici quelques bonnes pratiques :
◉ Écrivez en anglais ;
◉ Utilisez des mots racines précis et compréhensible par tous ;
◉ N’utilisez que des verbes d’action en quantité limitée ;
◉ Faites des mix entre mot racine et verbe d’action ;
◉ Produisez un onglet par page ou fonctionnalité ;
◉ Ajoutez un état d’avancement ;
◉ Pensez à faire la QA pour vérifier que les données remontent bien.
Une fois le plan réalisé, l’implémentation des tags peut se faire via des
outils de gestion de tag ou en dur dans le code par les développeurs.
Collecter les données qualitatives
Expliquer les données quantitatives
grâce au qualitatif
Lors du lancement de nouvelles fonctionnalités, collecter et analyser
les données quantitatives ne suffit pas. Les données quantitatives vous
apportent des informations sur le « quoi », mais sans vous expliquer le
Améliorer en continu
« pourquoi ». Il est par exemple possible qu’une nouvelle fonctionnalité ne
rencontre pas le succès escompté, sans pour autant comprendre les causes
de ce manque d’engouement. Pour comprendre le pourquoi, rapprochez-
vous de vos utilisateurs pour expliquer les analyses quantitatives par des
retours qualitatifs.
172
MODULE №4
L’analyse conjointe de la donnée quantitative et qualitative est
importante afin de bien comprendre les problèmes utilisateur. Attention
toutefois, il ne s’agit pas ici de demander aux utilisateurs comment
améliorer votre produit ou comment faire évoluer une fonctionnalité. Si
votre produit doit être imaginé et réalisé dans le but de répondre à une
problématique utilisateur, être user-centric ne veut pas dire répondre à
tous les désidératas des utilisateurs. Chercher à comprendre leurs besoins
reste votre principal objectif. S’ils vous proposent des solutions, intéressez-
vous plutôt aux problèmes sous-jacents les menant à demander telle ou
telle solution. Ceux-ci peuvent vous servir de bases d’hypothèses pour
relancer une discovery.
Organiser la collecte qualitative
Pour collecter des feedbacks sur les fonctionnalités que vous venez de
lancer, vous pouvez procéder de façon active en allant à la rencontre des
utilisateurs, ou de façon passive en laissant les utilisateurs vous remonter
des informations. Pour cela, plusieurs techniques s’offrent à vous :
◉ Envoyer un questionnaire ou un sondage par mail aux utilisateurs
ayant utilisé la fonctionnalité ;
◉ Ajouter un module de feedback à une étape clé du parcours
pour inciter l’utilisateur à laisser une note ou un commentaire ;
◉ Réaliser des interviews utilisateur suite à une évolution du produit
(chapitre 6).
◉ Analyser les parcours pour identifier les frictions grâce à des
outils de session recording ou heatmaps ;
◉ Prendre connaissance des retours sur les app stores ou sur Google ;
◉ Inciter les équipes service client, commerciales et customer
success à vous communiquer les retours. Vous pouvez mettre en
place des supports standardisés pour faciliter les échanges (canal
de communication privilégié, réunions de partage, template de
feedback à remplir…).
Améliorer en continu
173
MODULE №4
Bonnes pratiques pour bien suivre
les données
Less is more
En matière de données quantitatives comme qualitatives, less is more !
Pour résumer, ne collectez que les données dont vous avez besoin. Plus
vous disposez de données, moins vous avez de focus et moins celles-ci
sont actionnables. Définissez vos critères de succès avant de réfléchir
à quelle donnée collecter (chapitre 15). Vous gagnerez du temps lors de
l’implémentation de votre plan de taggage, lors de la collecte de données
et lors de l’analyse. Considérez également l’aspect éthique (et réglementé !)
de la collecte de données. N’oubliez pas que vous avez une responsabilité
envers vos utilisateurs : celle de ne collecter, transformer et stocker que des
données vous permettant d’améliorer votre produit.
Systématiser le suivi
Il est indispensable de mesurer l’impact des fonctionnalités que vous
livrez en production. Pour ne pas oublier, vous pouvez ajouter une étape
à votre board Kanban. Une fois les fonctionnalités livrées, placez-les dans
une colonne « à monitorer ». Le délai à partir duquel vous pouvez constater
un impact peut varier selon votre secteur d’activité, votre périmètre, la
fonctionnalité elle-même.
L’analyse des données vous permet de tirer des apprentissages, d’enrichir
et d’optimiser votre produit (chapitre 18). Ainsi, les User Stories resteront
dans cette colonne jusqu’à ce que vous décidiez que l’impact souhaité est
atteint ou bien que vous créiez une nouvelle opportunité ou des User Stories
d’évolution à partir des données analysées
Ajouter une colonne dédiée au monitoring
au board de l’équipe
Améliorer en continu
à faire en dev. à doer À monitorer
174
MODULE №4
La visualisation des données
Afin de visualiser et analyser les données, vous disposez de plusieurs
outils. Privilégiez ceux qui offrent des fonctionnalités de traitement
et de mise en forme de la donnée. Ils vous feront gagner du temps et
vous aideront à extraire les informations essentielles. Pour des mesures
d’audience et d’usage, les outils analytiques tels que Google Analytics, AT
Internet ou encore Amplitude sont de vrais alliés. Pour réaliser des analyses
de parcours, des outils tels que Contentsquare ou Hotjar sont tout à fait
adaptés.
La visualisation de données peut également être utilisée à des fins de
communication interne. Les dirigeants d’une entreprise n’ont ni le temps
ni l’envie de décortiquer un jeu de données. Il est de votre responsabilité
de rendre la donnée lisible rapidement, simplement et efficacement au sein
de vos reportings ou lors de vos comités de pilotage. Vous pouvez utiliser
un fichier Excel tout comme un support plus poussé, avec notamment de
la data visualisation, via un outil tel que Looker Studio (ex. Google Data
Studio) ou encore Tableau. Pour choisir les données importantes à partager,
référez-vous à vos objectifs et aux indicateurs clés de performance que
vous avez définis (chapitre 15).
Nos conseils
◉ Bloquez du temps dans votre agenda de manière régulière
pour structurer la remontée des données et faire l’analyse. Les
découvertes que vous ferez progressivement vous permettront
d’accélérer la connaissance de votre produit et de renforcer vos
convictions.
◉ Lorsque vous analysez les données collectées, pensez à des logiques
de parcours utilisateur en étudiant ce qu’il se passe avant et après.
Une donnée isolée de son contexte est rarement une information
fiable.
◉ Organisez des sessions « pop-corn time » pour visualiser en équipe
Améliorer en continu
les sessions de recording d’utilisation de votre produit, ou parcourir
les différents dashboard. Invitez également vos parties prenantes
clés pour les engager et partager avec eux cette connaissance.
175
MODULE №4
CHAPITRE 18
Faire évoluer
le produit
néfastes de votre produit et le rendez plus responsable.
Lorsque l’on fait du produit, il faut garder en tête que la livraison de
nouvelles fonctionnalités n’est pas une fin en soi. C’est à vous de faire
évoluer votre produit en l’enrichissant de nouvelles fonctionnalités, mais
toujours dans le but de répondre à de nouveaux besoins. Optimiser ou
retirer les fonctionnalités existantes sont aussi de solides options. Pour
y parvenir, envisagez la discovery et le delivery non pas comme une
succession d’étapes linéaires, mais comme un processus cyclique où les
deux phases sont menées en parallèle et en continu.
Enrichir, optimiser, supprimer
Enrichir en étant responsable
Votre produit s’enrichit de nouvelles fonctionnalités au fur et à mesure
que vous traitez de nouvelles initiatives de votre roadmap. Chaque nouvelle
initiative est l’occasion de vous interroger sur la responsabilité de votre
produit. Quelle que soit la mission de votre entreprise, vous pouvez
intégrer progressivement des changements qui rendront votre produit plus
responsable. Cette responsabilité peut être abordée sous différents angles :
◉ Utilisateur : les messages affichés sur votre produit sont-ils clairs
et transparents ? Traitez-vous les données utilisateur de façon
responsable et en vous assurant d’avoir leur consentement ? Votre
Améliorer en continu
produit est-il accessible pour tous ? Fiable ? Limite-t-il la frustration
en cas d’erreur ou de bug ?
◉ Environnemental : comment pouvez-vous limiter la consommation
énergétique de votre produit ? Limiter le poids des pages, l’envoi d’e-
mails inutiles, les temps de chargement ?
176
MODULE №4
◉ Économique : votre produit génère-t-il des déséquilibres
économiques au détriment de vos utilisateurs ? Vos offres payantes
sont-elles honnêtes ou génèrent-elles une dépendance injustifiée
empêchant l’utilisateur de résilier son abonnement par exemple ?
En vous posant ces questions, vous contribuez à prévenir les effets
Les 8 traits de caractère responsables d’un produit
par Fabrice Des Mazery, auteur de Responsables :
◉ Honnête : il ne ment pas, n’embellit pas la réalité, ne cache rien,
ne fait pas de promesse qu’il ne puisse tenir à 100 % ;
◉ Méritant : il mérite le temps, l’attention et les émotions qu’il
demande à ses utilisateurs. Le retour sur engagement de
l’utilisateur doit être positif ;
◉ Ouvert : il n’exclut personne qui puisse légitimement bénéficier
de ses services ;
◉ Prend soin : il fait attention à son utilisateur et le protège de
conséquences néfastes, lui et ceux qui l’entourent ;
◉ Fiable côté données : il n’écoute pas aux portes, ne soutire
pas d’informations, n’utilise ni ne partage des données sans
consentement et protège l’accès à ces données ;
◉ Prédictible : ses réactions sont compréhensibles, ses décisions
claires et les voies de recours accessibles ;
◉ Frugal : il limite sa consommation côté serveurs, côté réseaux
et côté terminal de l’utilisateur ;
◉ Équilibré : il ne crée pas de dissymétrie de pouvoir économique
direct, au bénéfice de ses utilisateurs et au détriment d’autres
acteurs économiques.
Améliorer en continu
177
MODULE №4

Optimiser en menant des expérimentations
Lorsque vous analysez le succès des fonctionnalités, vous pouvez
constater que certaines performances ne sont pas au rendez-vous ou
pourraient être améliorées. Pour y parvenir, vous pouvez mettre en place
une démarche d’expérimentations.
Définissez d’abord un objectif clair à atteindre, par exemple, améliorer
le taux d’utilisation d’une nouvelle fonctionnalité ou le taux de conversion
d’une landing page. Afin d’obtenir des résultats que vous pouvez interpréter,
assurez-vous que chaque expérimentation est constituée des éléments
suivants :
◉ La supposition ;
MODULE №4
Parfois, vos expérimentations viseront à comparer les performances
de deux ou plusieurs versions d’une page ou d’une fonctionnalité. Ces
expérimentations sont menées en soumettant, de façon aléatoire, une partie
des utilisateurs à chacune des versions et en comparant les performances
de chacune. Pour ce faire, les types de tests à privilégier sont :
◉ Les A/B tests qui consistent à ajuster un élément unique d’une
page ou d’une fonctionnalité, comme la couleur ou le wording d’un
bouton par exemple, et à comparer les performances des versions A
et B pour identifier laquelle convertit le mieux ;
◉ Les tests multivariés qui consistent à comparer les performances
de deux ou plusieurs versions en ajustant plusieurs variables,
comme deux landing pages différentes.

◉ L’hypothèse ;

◉ Le test ; A/B test et test multivarié

◉ L’apprentissage.
A VS. B A VS. B VS. C
9:41 9:41 9:41 9:41 9:41

Café Lafayette Café Lafayette Starbucks - Lafayette Café Lafayette Café Lafayette

Expérimentation de l’équipe Activation Adresse de livraison : 23 rue Taitbout

Paris, FR, 75009

Type de livraison : en mains propre

Adresse de livraison : 23 rue Taitbout
Paris, FR, 75009

Type de livraison : en mains propre

Adresse de livraison : 23 rue Taitbout
Paris, FR, 75009

Type de livraison : en mains propre

Adresse de livraison : 23 rue Taitbout
Paris, FR, 75009

Type de livraison : en mains propre

Adresse de livraison : 23 rue Taitbout
Paris, FR, 75009

Type de livraison : en mains propre

Estimation pour un livraison Estimation pour un livraison Estimation pour un livraison Estimation pour un livraison Estimation pour un livraison
Priorité Priorité Priorité Priorité Priorité

La supposition : Je suppose que si tant d’utilisateurs ne profitent pas

Standard Entre 17 et 94 min Standard Entre 17 et 94 min Standard Entre 17 et 94 min Standard Entre 17 et 94 min Standard Entre 17 et 94 min

Planiuer Planiuer Planiuer Planiuer Planiuer

Ma commande + Ajouter des articles Ma commande + Ajouter des articles Ma commande + Ajouter des articles Ma commande + Ajouter des articles Ma commande + Ajouter des articles

de leur code de parrainage, c’est que le champ n’est pas suffisamment 1 Impossible Breakfast Sandwich
6,95 €
1 Impossible Breakfast Sandwich
6,95 €
1 Impossible Breakfast Sandwich
6,95 €
1 Impossible Breakfast Sandwich
6,95 €
1 Impossible Breakfast Sandwich
6,95 €

visible. Ajouter un code promo ou parrainage

Ajouter
Sous-total 6,95 €
Ajouter un code promo ou parrainage Modiifer Ajouter un code promo Modiifer Ajouter un code promo Modiifer

Frais
Sous-total 6,95 € Ajouter un code parrainage Modiifer
Sous-total 6,95 €
Service 0,70 €
Sous-total 6,95 € Frais Frais
Sous-total 6,95 €
Livraison 1,99 €
Frais Service 0,70 € Service 0,70 €
Frais

L’hypothèse : Si je place le champ au-dessus du bouton valider, cela

Service 0,70 € Livraison 1,99 € Livraison 1,99 €
Total 9,64 € Service 0,70 €
Livraison 1,99 €
Ajouter un code promo ou parrainage Total 9,64 € Livraison 1,99 € 9,64 €
Total
9,64 € Ajouter
Total Ajouter un code parrainage

devrait améliorer le taux d’usage du code de parrainage.

Contrats sur les services En cliquant sur le bouton pour passer votre
commande, vous acceptez le Contrat sur les services de livraison avec
Thiga (RCS 841 983 828)
Vous renoncez pour rappel à votre droit de rétractation ayant pour objet
les services de livraison. Vous avez la possibilité de recourir à un
médiateur de la consommation ici.
Contrats sur les services En cliquant sur le bouton pour passer votre
commande, vous acceptez le Contrat sur les services de livraison avec
Thiga (RCS 841 983 828)
Vous renoncez pour rappel à votre droit de rétractation ayant pour objet
les services de livraison. Vous avez la possibilité de recourir à un
médiateur de la consommation ici.
Contrats sur les services En cliquant sur le bouton pour passer votre
commande, vous acceptez le Contrat sur les services de livraison avec
Uber Eats France SAS (RCS 841 983 828H
Vous renoncez pour rappel à votre droit de rétractation ayant pour objet
les services de livraison. Vous avez la possibilité de recourir à un
médiateur de la consommation ici.
FINALISER LA COMMANDE
Total 9,64 €
Ajouter
Contrats sur les services En cliquant sur le bouton pour passer votre
commande, vous acceptez le Contrat sur les services de livraison avec
Thiga (RCS 841 983 828) Contrats sur les services En cliquant sur le bouton pour passer votre
commande, vous acceptez le Contrat sur les services de livraison avec
Thiga (RCS 841 983 828)
Vous renoncez pour rappel à votre droit de rétractation ayant pour objet
les services de livraison. Vous avez la possibilité de recourir à un
médiateur de la consommation ici. Vous renoncez pour rappel à votre droit de rétractation ayant pour objet
les services de livraison. Vous avez la possibilité de recourir à un
médiateur de la consommation ici.

Le test : Si je positionne le bouton au-dessus, alors le taux d’usage du

FINALISER LA COMMANDE FINALISER LA COMMANDE FINALISER LA COMMANDE
FINALISER LA COMMANDE

code augmentera de 50 %.

L’apprentissage : Si le test est validé, je déploie le nouveau design.

Améliorer en continu
Améliorer en continu

178 179
MODULE №4

Supprimer des fonctionnalités
Au cours du cycle de vie d’un produit, la pertinence, l’impact et
l’utilisation des fonctionnalités varient. Lorsqu’on travaille en continu,
il faut veiller à ce que votre produit ne devienne pas un empilement de
nouveautés et que celles-ci continuent de contribuer à délivrer de la valeur.
Parfois, l’ajout ou le retravail de fonctionnalité peut venir cannibaliser
d’anciens comportements ou rendre obsolètes des morceaux de votre
produit. En analysant les données et grâce à des audits ponctuels, vous
devez détecter les fonctionnalités qui ne sont pas ou plus utilisées et faire
du tri en supprimant celles-ci. Supprimer des fonctionnalités inutiles
permet de garder le focus sur les fonctionnalités essentielles, simplifier
la navigation et la compréhension du produit pour vos utilisateurs et
améliorer la maintenabilité.
Tuer son produit
Si vous hésitez à conserver ou tuer votre produit, posez-vous les
questions suivantes :
◉ N’est-il plus viable financièrement (et ce, depuis un certain
temps) ? Génère-t-il encore assez de revenus, ou la marge est-
elle quasi entièrement mangée par les coûts de maintenance
MODULE №4
Discovery et delivery en parallèle
et en continu
Le dual track
Pour avancer de façon efficace sur votre roadmap, assurez-vous que
les activités de delivery et de discovery sont menées en parallèle. Alors
que le delivery de certaines fonctionnalités est en cours, vous devez aussi
anticiper les futurs développements en faisant de la discovery sur les
prochaines opportunités prioritaires. Cette approche est communément
appelée le dual track : les cycles de discovery et delivery coexistent et se
nourrissent. Ainsi les cycles de discovery ont pour principal objectif de
connaître et prioriser les problèmes et opportunités à résoudre. Les cycles
de delivery suivent votre rythme de développement avec pour objectif de
livrer progressivement des incréments Produit apportant de la valeur. Enfin,
les feedbacks et données suivant les livraisons nourrissent à nouveau la
discovery. La boucle est bouclée !
Le dual track
Opportunité Fonctionnalité

devenus trop élevés en raison d’une forte dette technique ?

◉ Avez-vous assez de ressources pour le gérer correctement

Discovery
en matière d’équipe de développement, de qualité, de support
client ? Le travail de ces équipes ne serait-il pas plus profitable
si elles étaient sur un autre produit ?
Mesurer et

◉ Est-il en concurrence avec plusieurs produits ou fonctionnalités apprendre

de la même société, que ce soit au niveau du marché ou des

équipes ?

Deivery

Améliorer en continu
Améliorer en continu

180 181
MODULE №4
Le piège à éviter est de se laisser happer par le delivery et les urgences
du quotidien. Pensez à garder du temps pour les activités de discovery…
Pour que cette parallélisation puisse se mettre en place, vous devez :
◉ Avoir un delivery efficace vous permettant de dégager du temps
pour des activités de discovery ;
◉ Encourager votre équipe à prendre de l’autonomie. Appuyez-
vous sur votre lead technique pour ne pas être sollicité en
permanence lors du delivery ;
◉ Organiser votre discovery de façon à récolter des données en continu.
Faire de la discovery en continu
Certaines équipes pensent parfois à tort que la discovery prend du temps
et qu’elle est difficile à mettre en place. Elles se limitent par conséquent
à quelques grands chantiers de recherche utilisateur par an. Veillez à ne
pas tomber dans ce piège : plus vous espacez les points de contact avec
vos utilisateurs, plus les efforts nécessaires pour comprendre leurs besoins
seront élevés. Teresa Torres, autrice de Continuous Discovery Habits fait
clairement la distinction entre la discovery en mode projet — où plusieurs
semaines sont nécessaires pour recruter des utilisateurs, organiser et
mener des interviews, analyser les résultats et préparer une restitution —
et la discovery en continu qui consiste à s’assurer que vous êtes en contact
chaque semaine avec vos utilisateurs sous une forme ou une autre. La
discovery en continu facilite le travail en dual track. Pour y parvenir, vous
pouvez par exemple réaliser les activités suivantes :
◉ Collecter du feedback de façon passive via un formulaire sur le
site par exemple, et analyser ce feedback chaque semaine ;
◉ Faire de la double écoute avec le service client ou analyser les retours
utilisateur via le formulaire de contact, les reviews des stores ou autre ;
◉ Mettre en place des A/B tests grâce à des outils adaptés ;
◉ Tester votre solution auprès de membres de votre entourage. Même
Améliorer en continu
s’il ne s’agit pas forcément d’utilisateurs correspondant tout à fait
à votre cible, vous pourrez néanmoins collecter des informations
intéressantes et identifier des éléments récurrents ;
182
MODULE №4
◉ Réaliser une interview exploratoire par semaine avec un
utilisateur correspondant à votre cible. Si la création d’un pool
d’utilisateurs disponibles pour une interview demande un peu
d’organisation en amont, une fois votre communauté créée vous
pourrez facilement réaliser des interviews régulières ;
◉ Suivre régulièrement la donnée quantitative, en incorporant par
exemple un moment de partage des chiffres clés lors de votre review
ou vos points récurrents.
Nos conseils
◉ Avant de vous lancer dans une expérimentation, assurez-vous de
pouvoir collecter des résultats rapidement (objectifs clairs, trafic
suffisamment important pour obtenir des résultats significatifs).
Si ce n’est pas le cas, lancez la fonctionnalité, monitorez de prêt et
désactivez la fonctionnalité en cas de problème (grâce au feature
flag).
◉ Si vous décidez de supprimer une fonctionnalité ou un produit,
gardez en tête que des utilisateurs, même peu nombreux, peuvent
dépendre de vous. Informez-les en avance, soyez transparent·e
sur ce qui motive votre décision et proposez des alternatives
lorsque c’est possible.
◉ Mener delivery et discovery chaque semaine demande un peu
d’organisation ! Pour cela, pensez à bloquer des créneaux dédiés
dans votre agenda pour traiter les demandes des développeurs,
préparer les développements à venir, réaliser les activités de dis-
covery et faire l’analyse des performances.
Améliorer en continu
183
MODULE №4
CHAPITRE 19
Traiter les anomalies
et la dette technique
Améliorer votre produit passe aussi par la gestion des anomalies et de
la dette technique. En tant que Product Manager, vous devez vous assurer
que les anomalies sont traitées de manière efficace. Vous aurez également
à prioriser les chantiers techniques, en gardant en tête les besoins des
utilisateurs et les objectifs de l’entreprise, afin de garantir la qualité du
produit et son succès sur le long terme.
Gérer les anomalies
You build it, you run it !
Dès lors que vos fonctionnalités sont en production, d’éventuelles
anomalies (bug) peuvent vous être remontées. Contrairement aux méthodes
de développement en cascade où le produit est transmis de l’équipe de build
(qui développe la solution) à l’équipe de run (qui en assure le maintien et
le support), on recommande aujourd’hui une approche où les développeurs
ayant conçu la solution en sont également responsables. You build it, you
run it (vous le concevez, vous en êtes responsable) ! Les avantages sont
multiples :​​
◉ Les développeurs ayant conçu la solution sont aussi ceux qui la
connaissent le mieux. Ils sont donc immédiatement opérationnels
et ne sont pas dépendants d’un transfert de connaissances ;
Améliorer en continu
◉ Par extension, cela permet d’être plus réactif face à un incident
minimisant le temps nécessaire pour intervenir. Dans les
organisations ayant conservé une équipe build et une équipe run, on
constate que cette dernière est rapidement limitée dans sa capacité
d’intervention. En effet, elle peut rarement identifier et mettre en
place un correctif en autonomie ;
184
MODULE №4
◉ Cela permet aux développeurs d’être au plus près des utilisateurs
et de récolter leurs feedbacks en direct. Cela les incite souvent à
concevoir une solution plus robuste pour minimiser les besoins
d’intervention.
Détecter et prioriser des anomalies
Une gestion efficace des anomalies en production s’articule autour de
quatre étapes.
1. Détection : les tickets de bug sont créés par la personne qui les détecte.
Il peut s’agir de vous en tant que Product Manager, notamment lorsqu’un
bug est remonté directement par un utilisateur, mais également d’un
membre de l’équipe, du service client ou de toute autre personne
interagissant avec le produit. Les tickets d’anomalie contiennent la
description des étapes pour reproduire le problème, le résultat constaté
ainsi que le résultat normalement attendu. Lorsqu’une anomalie est
détectée en production, elle doit être traitée immédiatement. Cela ne
signifie pas que vous devez corriger immédiatement le bug, mais plutôt
que vous devez en prendre connaissance le plus rapidement possible,
tenter de le reproduire, et, le cas échéant, documenter les éléments
pertinents à la reproduction du bug. Enfin, vous devez communiquer
avec les parties prenantes concernées.
2. Priorisation : Toutes les anomalies n’ont ni la même importance ni
la même urgence. Il faut donc accepter de ne pas toutes les corriger.
Une anomalie qui intervient en production doit être traitée plus
rapidement qu’une anomalie qui intervient sur une version en cours
de développement ou de test. De la même façon, une anomalie détectée
sur le chemin critique de vos utilisateurs, et empêchant le bon
déroulement des actions principales, n’a pas la même criticité qu’une
anomalie survenant sur une fonctionnalité peu utilisée ou représentant
un problème mineur.
3. Correction : les anomalies les plus prioritaires sont corrigées
immédiatement. Selon la criticité du bug, n’hésitez pas à ajouter
des scénarios de tests supplémentaires afin d’éviter que l’anomalie
ne se reproduise lors de prochaines releases. Les anomalies moins
Améliorer en continu
critiques peuvent être priorisées avec les autres User Stories lors de la
planification des prochaines releases.
185
MODULE №4

4. Validation : une fois l’anomalie corrigée, elle doit être testée comme
une User Story classique et livrée en production. Si le bug est très
critique, on peut pousser ce que l’on appelle un hotfix, c’est-à-dire une
release dédiée uniquement au correctif. Si la criticité est plus modérée,
on peut intégrer le correctif à la release en cours. Une fois le correctif
en production, informez les personnes concernées.
MODULE №4
◉ La fiabilité : un utilisateur qui est confronté à un logiciel ou une
application instable et dont le comportement est aléatoire reviendra
peut-être une deuxième fois, mais jamais une troisième.
Maîtriser le niveau de dette technique

Faire un produit qui ne nécessite pas de maintenance, dont les évolutions

sont faciles et rapides à mettre en œuvre et qui est d’une grande fiabilité
Préoccupez-vous de la dette technique est très utopique. La dette technique est inévitable et parfois délibérée.
Dans certains cas, l’équipe peut faire le choix conscient de créer de la dette
technique afin de livrer une fonctionnalité dans les délais exigés.
Qu’est-ce que la dette technique ?
Lorsqu’un élément de dette technique (volontaire ou non) est identifié,
La dette technique est une métaphore du développement logiciel inventée souvent grâce à votre équipe de développement, il vous faut identifier la
par l’informaticien Ward Cunningham. Il s’inspire du concept existant de tactique pour la résorber. Votre travail de Product Manager consiste à
dette financière et l’applique au domaine du développement logiciel. Ainsi trouver le bon compromis pour maximiser l’évolutivité et la fiabilité de
dans les développements, le code endetté de votre produit correspond au votre produit, tout en minimisant le temps consacré à la maintenance.
capital et les bugs représentent les intérêts. Dès lors que vous ajoutez de
nouvelles fonctionnalités, le capital augmente et génère davantage de bugs et
de maintenance. Si les remboursements sur le capital ne sont pas réguliers,
les intérêts demeureront importants. La dette technique représente donc
des parties de code non utilisées ou bien dans lesquelles il est difficile
d’effectuer des modifications et donc des évolutions. Afin de faire évoluer
votre produit dans le temps et ne pas être bloqué par une maintenance trop
importante, veillez à maîtriser la dette technique. Le meilleur avocat de
cette philosophie vis-à-vis de vos parties prenantes, c’est vous !

La dette technique concerne à la fois la maintenance, la fiabilité et

l’évolutivité de votre produit.

◉ La maintenance : qu’elle soit corrective (corriger les défauts et les

bugs liés à une application) ou adaptative (adapter une application
afin que celle-ci continue de fonctionner sur des versions plus
récentes des briques techniques sur lesquelles elle s’appuie), la
maintenance d’une application ou d’un logiciel est au cœur de
votre travail et touche directement les équipes de développement.
Plus cette maintenance est conséquente, plus votre équipe de
développement passera du temps à corriger des bugs et moins elle

Améliorer en continu
Améliorer en continu

livrera de fonctionnalités.

◉ L’évolutivité d’un produit : l’essence même du Product Management

est de proposer des fonctionnalités qui s’adaptent le mieux aux vrais
besoins utilisateur. Si le produit n’évolue plus fonctionnellement, il
finira par dégringoler. Aussi, un manque d’évolutivité nécessitera des
interventions sur le code plus longues et difficiles pour développer
de nouvelles fonctionnalités.
186 187
MODULE №4

Le Technical Debt Quadrant
Ce framework de Martin Fowler de Thoughtworks catégorise la dette
technique en quatre types :
Excessive et imprudente
Dpiip rodutip sr dpt équt pt qut
déctdpei déltbérémpei dp 9strp du
Volontaire
MODULE №4
Dans certains cas, une attention particulière doit être mise sur la dette
technique pour la résorber. Pour s’y attaquer, accordez une partie de la
capacité de l’équipe à la gestion de la dette pour améliorer les performances
petit à petit. Ainsi, vos développeurs pourront mettre en place :
◉ La Boy Scout Rule. Always leave the code you are working on a little
bit better than you found it (laissez toujours le code sur lequel vous
Modérée et prudente travaillez un peu mieux que vous ne l’avez trouvé). Cela permet à
votre équipe de s’attaquer à la dette technique quasi gratuitement.
Le principe est simple : à chaque fois que quelqu’un touche un bout
Uep dpiip com lèipmpei déltbérép de code, il doit le rendre meilleur que l’état dans lequel il l’a trouvé.
our ltvrpr à ipm t uep vprttoe du Une simple question d’amélioration continue !

“qutck sed dtriy” srcp qudpllpt ep roduti ep vsui pui!êirp st ls ptep

puvpei rpedrp lp ipm t eécpttstrp
our coecpvotr lpur codp ro rpmpeis
Ex : ttip ddp!commprcp qut réslttp uep
grsedp sritp dp toe CA pedsei ls
értodp dp 1o%l. pt 9oecitoeesltiét
dotvpei toritr svsei cpiip értodp.
ddêirp rpmbourtép tt lpt teiérêit toei
tufttsmmpei pitits
Ex : uep sritp dp codp rsrpmpei
modtfép.
◉ Des tâches de refactoring. Le refactoring ou réusinage de code,
consiste à retravailler le code source d’un logiciel sans ajouter de
fonctionnalités ni corriger de bugs, mais en améliorant sa lisibilité
pour simplifier sa maintenance ou le rendre plus générique.

◉ Un debt backlog. Le debt backlog répertorie la dette détectée et les

actions de dette volontaire prises par l’équipe. Lorsque vous faites
Dpiip touvpei dup à dpt équt pt Dpiip ipchetqup pxttisei dset lpt un tel choix, n’oubliez pas de renseigner les éléments qui ont motivé
tgeorsei lpt rsitqupt dp coecp itoe équt pt mêmpt lpt lut votre choix, les tâches pour corriger la dette prise, l’estimation du
Involontaire

pi ddsrchtipciurp lpt lut bsttqupts px értmpeiépt csr teévtisblps

Ex : tisriu t our lptqupllpt tl pti lut
tm orisei dp vsltdpr uep tdép ou
ddêirp lp rpmtpr à tp lsecpr tur ue
msrché qup ddécrtrp du codp dp
qusltié.
temps que la correction prendrait ainsi que la date attendue pour
Souvpei cp edpti qudà ls fe ddue roopi
qup ldoe tp rped répllpmpei com ip dp
rembourser cette dette. Le backlog permet d’avoir une vision claire
cp qup ls coecp itoe sursti dû êirp, de la dette à résorber afin de la prioriser selon vos besoins et vos
mêmp tt lp codp pi ldsrchtipciurp mtt prévisions de roadmap.
pe lscp toei irèt boet pi irèt btpe
petét.

Nos conseils
Minimiser la dette technique ◉ La description du bug ainsi que la modification à faire pour le
résoudre sont essentielles pour prioriser et corriger le problème
Vous vous demandez certainement maintenant comment produire le correctement. Pensez à proposer un template avec des champs
moins de dette technique tout en continuant à livrer vos fonctionnalités obligatoires à remplir pour les parties prenantes qui les remontent.
dans les temps et comment vivre avec une dette technique existante en
essayant tout de même de la minimiser. ◉ Pour corriger des petites anomalies qui ne sont pas souvent
priorisées (bug d’affichage, corrections de wording…), organisez

Améliorer en continu
Améliorer en continu

Avant toute chose, la dette technique est liée de façon plus globale à
la qualité. Lorsqu’une culture de la qualité est présente au sein de l’équipe
et auprès des parties prenantes, lorsque les efforts sont réalisés en amont
grâce à la préparation des User Stories, des tests, du pair programming, de
la DoD, la livraison régulière du code… une partie du problème lié à la dette
technique est déjà résolu.
188
de temps de temps des sessions de corrections de bug en
réunissant les Product Designer et développeurs. L’avantage est
de corriger un maximum d’anomalies en fixant une limite de temps
dédié !
◉ Ne prévoyez pas de sprint entier dédié au refactoring ! Ils
font passer un mauvais message. En situation de crise, c’est
l’aveu que vous avez perdu le contrôle de votre produit.
189
MODULE №4

MODULE №4
CHAPITRE 20 Afin de vous organiser, la première étape est d’identifier qui sont vos
parties prenantes et quelle importance elles ont pour la conception de
votre produit. Pour cela, vous pouvez utiliser la power-interest grid (matrice

Travailler en équipe pouvoir-intérêt) conçu par Ackermann and Eden, experts en stratégie,
professeurs et auteurs du livre Making Strategy : The Journey of Strategic

et collaborer avec les

Management, qui vous permet d’identifier quatre groupes de stakeholders :

◉ Les players sont vos stakeholders clés avec qui vous collaborez de

parties prenantes
En tant que chef d’orchestre de votre produit, vous êtes au cœur
des interactions avec votre équipe et les parties prenantes. Vous devez
vous assurer d’une bonne collaboration et d’un fonctionnement efficace
et agréable de l’équipe. Une grande partie de vos activités font appel
à votre maîtrise de compétences telles que l’écoute, le leadership et la
communication.
manière proche, car ils ont un intérêt fort dans ce que vous faites
avec votre équipe. Ils ont également une forte capacité à influer sur
vos décisions. Ils participent aux activités de discovery (module 2)
et vous remontent directement des demandes (chapitre 3) ;
◉ Les context setters ont un fort pouvoir, mais un intérêt direct
limité pour votre produit. Ils ne sont pas impliqués au quotidien,
mais vous devez vous assurer qu’ils sont satisfaits et les consulter
pour les décisions importantes ;
◉ Les subjects montrent un fort intérêt pour votre produit bien qu’ils
aient peu d’influence. Ce sont vos ambassadeurs. En les impliquant
dans votre processus, ils peuvent potentiellement devenir des players.
En les laissant de côté, vous les ferez basculer dans la crowd ;

◉ La crowd a peu d’influence et un faible intérêt pour votre produit.

Vous pouvez simplement informer.
Collaborer avec vos parties prenantes
En somme, votre mapping vous permet de cibler le niveau d’implication
de vos parties prenantes afin de les engager sur les bons sujets, au bon
Identifier les parties prenantes clés moment, et d’obtenir le support des bonnes personnes sur les bonnes
décisions.
Les parties prenantes (stakeholders) sont toutes les personnes impactées
par votre produit et qui peuvent influencer, d’une manière ou d’une autre,
vos décisions. Vous pouvez identifier :

◉ Les stakeholders externes : utilisateurs du produit ;

◉ Les stakeholders internes : Product leaders, marketing, équipe

commerciale, support, finance, légal, autres équipes Produit.

Améliorer en continu
Améliorer en continu

Les interactions avec vos stakeholders externes se font à des moments

ciblés lors d’entretiens utilisateur et pendant vos activités de discovery.
Pour ce qui est de vos stakeholders internes, les interactions peuvent
s’avérer un peu plus complexes. En effet, vous devez établir une relation de
confiance et une collaboration efficace avec plusieurs personnalités ayant
des intérêts différents. De plus, plus votre périmètre est large, plus vous
avez de stakeholders à gérer.
190 191
MODULE №4

MODULE №4
La Matrice Pouvoir — Intérêt n’y aura pas de miracle et la date de livraison ne va pas avancer par magie »
: voici quelques messages à faire passer avec diplomatie. N’oubliez jamais
que vous êtes le·la gardien·ne de la valeur du produit. Votre rôle est de vous
assurer de la cohérence des évolutions avec les objectifs de votre produit.
Voici quelques conseils pour dire non avec diplomatie :
Subjects Players
Impliquer Coll43orer
◉ Ne dites pas non trop rapidement ;

◉ Demandez pourquoi (ne passez pas à l’étape suivante si vous n’avez

intérêt

pas le pourquoi) ;

◉ Reformulez la demande ;

Cro98 Context Setters ◉ Repartagez les objectifs Produit ;

InCormer Consulter
◉ Appuyez-vous sur votre priorisation ;

◉ Encouragez la contribution ;
pouvoir
◉ Donnez des perspectives.

Faire des choix et savoir dire non
Vos stakeholders, et plus particulièrement les players, émettent
régulièrement de nouvelles demandes (chapitre 3). Et elles sont souvent
transmises en urgence, en fonction des actualités de l’entreprise, de
l’activité du business ou des évolutions réglementaires. Par exemple, les
commerciaux peuvent vous demander de faire une évolution Produit pour
vite signer un contrat avec un client important, sans oublier le service
juridique qui peut vous solliciter pour une évolution RGPD que vous devrez
traiter en urgence… La capacité de production de l’équipe n’étant pas
extensible, vous devrez vous assurer de :
◉ Bien comprendre les enjeux des demandes en les précisant et
en identifiant leur criticité. Posez simplement les questions : « Pour
qui ? Pourquoi ? Pourquoi maintenant ? Que se passe-t-il si l’on ne
fait rien ? » ;
Communiquer et vulgariser
La communication est un élément indispensable dans la gestion des
parties prenantes et c’est à vous de donner le bon niveau d’information,
mais aussi de gérer la fréquence pour optimiser vos activités. Ritualisez
les échanges pour vous assurer d’avoir des contacts réguliers en organisant
notamment :
◉ Le kick-off. Que ce soit au début d’un trimestre, au lancement
d’un nouveau produit, d’une fonctionnalité ou d’un partenariat
majeur, nous vous conseillons de réaliser un kick-off pour présenter
les objectifs, la roadmap et les différentes étapes, les personnes
impliquées… Cette réunion est un point d’information qui permet
d’aligner toutes les parties prenantes ;
◉ La review. Ce rituel vous permet de communiquer sur les nouvelles
fonctionnalités, d’informer sur les étapes à venir et de récolter du

Améliorer en continu
Améliorer en continu

feedback (chapitre 11) ;

◉ Faire les bons choix et informer les stakeholders des décisions.
Vous aurez bien souvent besoin de refuser certaines demandes et
même si elles viennent du leadership.
Savoir dire non est une compétence essentielle que vous devez maîtri-
ser. « Non, tout n’est pas pour tout de suite » ; « Non, telle fonctionnalité n’a
pas forcément sa place dans cette version, voire dans le produit », « Non, il
192
◉ Les points de synchronisation. Rendez-vous régulier qui vous
permet d’avoir un échange privilégié en plus petit comité avec un
service, un groupe de stakeholders ou une personne. Il est l’occasion
de traiter les nouvelles demandes et répondre aux interrogations de
manière plus détaillée.
193
MODULE №4
En plus des rendez-vous et contacts, nous vous conseillons de faciliter
l’accès à l’information concernant vos activités et vos décisions. Aussi, vos
parties prenantes peuvent s’y référer lorsqu’elles le souhaitent. Appuyez-
vous sur la documentation que vous avez mise en place, sur des supports
que vous pourrez mettre à jour régulièrement : votre roadmap, un compte
rendu de la review, un récapitulatif des avancées du delivery, un update
des grandes deadlines… Ces supports doivent être autoporteurs et faciles
à comprendre pour les parties prenantes concernées. Ainsi, un effort de
vulgarisation, de simplification et d’explication doit être fait pour ne pas
rentrer dans les détails techniques et vous adapter au vocabulaire employé
par les métiers.
Enfin, pensez à des formats plus concis avec une prise de recul pour
communiquer plus globalement sur l’impact de votre équipe et produit.
Une newsletter et/ou une présentation ad hoc vous permettent de mettre en
lumière le travail effectué par l’équipe.
Bien travailler avec votre équipe
Faire preuve de leadership
D’une manière générale, en tant que Product Manager de l’équipe, vous
embrassez au même titre que les développeurs, les valeurs de l’Agilité, dont
la collaboration et l’entraide. Comme vous n’avez pas de lien hiérarchique
avec l’équipe, vous devez adopter une posture de coach plutôt que manager. Il
s’agit de motiver en donnant la direction, de vous assurer que les ressources
soient employées à bon escient pour servir les objectifs et permettre à
l’équipe d’être autonome afin de prendre les meilleures décisions. Aussi,
comme le souligne Marty Cagan dans son best-seller Empowered, vos
combats sont de vous assurer d’avoir :
◉ Un bon alignement de l’équipe ;
◉ Un bon niveau d’autonomie.
Ce rôle peut être difficile à appréhender, voilà pourquoi nous vous
Améliorer en continu
conseillons quelques actions :
◉ Soyez présent·e pour l’équipe. Vous avez fourni un effort
important de cadrage et de préparation, mais rappelez-vous que
sans l’équipe (Product Designers, développeurs…) vous n’arriverez
pas à franchir la ligne d’arrivée. La résolution des problèmes est
un sport collectif ! Restez donc disponible pour aider un maximum
votre équipe ;
194
MODULE №4
◉ Faites preuve d’adaptation en fonction des circonstances.
L’équipe vous accordera plus facilement sa confiance si elle sent
qu’elle peut s’adapter rapidement et qu’elle est capable de proposer
des alternatives ;
◉ Redescendez les informations clés à votre équipe. Vos
développeurs ne sont pas simplement des exécutants. Plus vous les
embarquez dans des problématiques avec des éléments de contexte,
plus vous leur partagez les objectifs à atteindre et les progrès, et
plus ils se sentiront partie intégrante du succès du produit ;
◉ Faites briller votre équipe. Vous serez amené·e à être plus visible
que le reste de l’équipe et auprès des parties prenantes. Il est donc
important de rappeler que les succès du produit sont le fruit d’un
travail collectif. Par exemple, n’oubliez pas de citer les développeurs
qui ont contribué aux succès dans vos communications et lors des
reviews.
Les Product Managers doivent-ils avoir un bon niveau
technique ?
Ce sont des questions que peuvent se poser beaucoup de Product
Manager : « dois-je maîtriser les bases de développement ? Est-il important
de pouvoir manipuler des APIs ? Dois-je pouvoir faire des requêtes SQL dans
la base de données ? » En somme, quel niveau technique devez-vous avoir ?
Avoir une appétence pour les sujets techniques est important, mais
vous ne devez pas nécessairement en maîtriser les compétences. Votre
quotidien est de collaborer avec les développeurs sur des fonctionnalités
Produit, de comprendre les contraintes techniques et de faire des choix.
Soyez attentif·ve aux conversations techniques pour déceler des signaux
faibles concernant le travail à faire : une fonctionnalité va entraîner un
effort important de maintenance, une solution alternative pourrait réduire
la complexité technique… Pour cela, vous devez avant tout faire preuve de
curiosité, savoir comment est construit votre produit et comprendre les
principaux concepts techniques (le front-end, le back-end, les API).
Vous devez également être à l’aise pour discuter de solutions techniques
Améliorer en continu
avec vos développeurs en jonglant entre un vocabulaire métier et un
vocabulaire technique pour vous assurer de la bonne compréhension.
Enfin, il est important de comprendre les difficultés du développement.
Ayez bien en tête le problème du context switching. Cerner un sujet pour
commencer à entrer dans le cœur du développement prend du temps et les
changements récurrents de sujets affectent la concentration et l’efficacité.
Ayez en tête que déranger un développeur, ne serait-ce que 5 minutes,
195
MODULE №4

MODULE №4
coûtera plus cher que 5 minutes seulement… De plus, le multitasking et Supports de rétrospectives de l’équipe Activation
l’accumulation des sujets sont source de ralentissement en développement.
C’est pourquoi il est important de cibler les sujets et de temporiser si
nécessaire. Exemple de rétro 1 Exemple de rétro œ Exemple de rétro ©

Rétro sprint 12 Rétro sprint 1 Rétro sprint 1

Améliorer le fonctionnement de Liked Ce que j’ai aimé Mad Stop

l’équipe
Learned Ce que j’ai a==Di: Sad Start
L’équipe Produit doit livrer de la valeur le plus rapidement possible. Elle
est donc le moteur du produit et sa bonne santé a une influence sur sa
performance. Sans cela, vous ne pouvez pas avancer. Il faut donc en prendre
soin et tout faire pour éviter que les rouages ne se grippent. Veillez à : LaIked Ce qui m’a maMqué Glad Continue

◉ Vous assurer que chacun·e se sente écouté·e ;

Lon[ed Xor Ce que j’ai dé:iDé
◉ Comprendre que l’amélioration continue de la qualité ou les
interactions entre les individus sont des sujets essentiels ;

◉ Insuffler une dynamique collective ; actions actions actions

◉ Réagir lorsque l’équipe rencontre des difficultés.

La rétrospective est un moyen facile à mettre en place pour travailler

sur ce sujet. Lors de la rétro, l’équipe identifie les éléments du processus
de développement qui ont bien fonctionné et ceux qui sont à améliorer.
L’équipe construit ainsi un plan d’action d’amélioration qu’elle s’engage à
mettre en place dès le prochain cycle. Pour profiter pleinement des bénéfices
de la rétro, il est nécessaire d’établir un climat de confiance. Vous devez
ainsi créer un environnement où l’équipe peut échanger ouvertement. Pour
cela, appuyez-vous sur plusieurs formats d’animations. En voici quelques
exemples :
◉ « Mad, Sad, Glad » ;
N’hésitez pas à identifier un rôle tournant dans l’équipe afin de varier la
responsabilité de l’animation. Pensez aussi à organiser de façon ponctuelle
(une fois par trimestre, suite à la fin d’un gros projet, etc.) une rétrospective
plus large, en invitant votre équipe élargie et vos parties prenantes par
exemple. Elle permettra à l’équipe d’améliorer sa collaboration avec les
stakeholders clés, et à l’organisation d’améliorer sa gestion des projets
stratégiques.

◉ « Start, Stop, Continue » ;

Améliorer en continu
Améliorer en continu

◉ « 4 L : Liked, Learned, Lacked, Longed for » ;

◉ Le « Speed Boat ».

196 197
MODULE №4
Nos conseils
◉ Lorsque vous arrivez sur un nouveau périmètre, prenez le temps
de rencontrer vos stakeholders et les membres de l’équipe
individuellement. L’objectif est d’apprendre à les connaître pour
assurer une future bonne collaboration.
◉ Dans un contexte où vous avez de nombreux stakeholders,
identifiez des personnes référentes qui seront vos interlocuteurs
privilégiés pour co-construire.
◉ Cassez les silos entre votre équipe et vos parties prenantes ! Pour
cela, invitez vos stakeholders à venir prendre la parole auprès de
l’équipe et faites participer de temps en temps votre équipe aux
réunions stratégiques.
◉ Certaines équipes ajoutent à leur backlog les actions priorisées à
l’issue de la rétrospective. Cela vous permet de rendre visibles les
actions à mener et de vous assurer de leur avancement.
Améliorer en continu
198
L’essentiel
de ce module
1. Le succès se mesure à différents niveaux : l’atteinte de vos objectifs,
l’impact d’une fonctionnalité, la performance globale de votre
produit.
2. Une bonne métrique mesure l’outcome (l’impact d’une
fonctionnalité) et non l’output (la livraison de la fonctionnalité) et
permet de prendre des décisions éclairées quant à l’évolution de
cette fonctionnalité.
3. Vous devez être data-informed, c’est-à-dire prendre des décisions
en utilisant les données quantitatives (le quoi), mais également les
retours qualitatifs (le pourquoi).
4. Pour faire évoluer votre produit, enrichissez-le de nouvelles
fonctionnalités, optimiser les fonctionnalités existantes ou
supprimer les fonctionnalités obsolètes.
5. La discovery et le delivery doivent être menés en parallèle et en
continu afin de mettre en place une approche Produit efficace.
6. Les anomalies (bugs) doivent être évaluées et priorisées vis-à-vis
des autres éléments du backlog. Les anomalies les plus critiques
sont corrigées immédiatement.
7. La dette technique est inévitable lorsqu’on développe un produit,
mais elle doit être maîtrisée et suivie afin d’être résorbée au fil du
temps.
8. Vos qualités d’écoute active, de vulgarisation et votre capacité à dire
non sont essentielles pour nouer une relation de confiance avec vos
parties prenantes.
9. Vous devez faire preuve de leadership auprès de votre équipe.
Donner du sens, collaborer et communiquer doit faire partie de vos
activités quotidiennes.
 MODULE №4
CONCLUSION
Votre voyage au cœur du process Produit se termine et vous comprenez
que ce n’est que le début ! Pour chaque étape de strategy, discovery, delivery
et d’amélioration continue, vous disposez des connaissances et des outils
nécessaires que vous pouvez mettre en application dans votre quotidien.

Ce livre a été conçu pour enrichir vos connaissances existantes et

vous fournir de nouvelles perspectives pour exceller dans votre rôle de
Product Manager. Nous espérons que vous utiliserez ces informations pour
continuer à améliorer vos pratiques Produit et à avoir un impact positif sur
vos utilisateurs, votre équipe et votre organisation.

Tel un produit, il est toujours possible de s’améliorer, d’apprendre et

d’innover. Restez curieux·se, continuez à vous former et n’ayez pas peur
d’expérimenter. Bonne chance dans votre parcours de Product Manager !

Pour aller plus loin, voici quelques ressources qui nous ont servi d’inspiration
pour écrire ce livre et qui abordent plus en détail certains concepts clés :

◉ Le Media, Thiga ;

◉ Discovery Discipline, Rémi Guyot et Tristan Charvillat ;

◉ Responsables, Fabrice des Mazery ;

◉ Le Ticket, Kevin Deniau et Tanguy Verluise ;

◉ Good strategy, Bad strategy, Richard P. Rumelt ;

◉ Continuous Discovery Habits, Teresa Torres ;

◉ Escaping the build trap, Melissa Perri ;

◉ Inspired, Marty Cagan ;

Améliorer en continu
◉ Empowered, Marty Cagan ;

◉ Product Roadmap Relaunched, Bruce Mccarthy ;

◉ Running Lean, Ash Maurya ;

◉ The Lean Startup, Eric Ries.

201
 MODULE №4
REMERCIEMENTS

Nous aimerions remercier chaleureusement Emérence Curutchet,

Virginie Coux et Geoffrey Chovet pour leur contribution précieuse. Leur
expertise a grandement permis de développer le contenu de ce livre.

Un grand merci à nos relecteurs attentifs, Benjamin Danel, Sebastian

Nankervis, Elias Ghali, Naban Tuo, Alexis Lamrani, Hortense Bouzoud,
Mathias Frey, Rémi Favre, Romain Monclus, Simon Joliveau, Antoine
Lancesseur. Leurs commentaires éclairés ont permis d’enrichir le contenu
de ce livre.

Nous exprimons également notre reconnaissance envers Rémi Guyot et

Julien Négui, nos éditeurs experts. Leur rigueur et leur sens aigu du détail
ont permis d’améliorer la qualité et la cohérence de notre travail.

Nous adressons également nos remerciements à Céline Winant-Pateron

et l’équipe marketing qui contribue à promouvoir ce livre avec dynamisme
et créativité.

Nous remercions sincèrement Christopher Parola pour son soutien

précieux. Sa préface éclairée donne une perspective unique à ce livre.

Nous tenons à exprimer notre reconnaissance envers Christelle

Améliorer en continu
Perrin de Médianes qui a été une partenaire précieuse tout au long de ce
voyage éditorial. Sa sensibilité artistique et son professionnalisme ont été
indispensables pour donner à ce livre sa forme finale.

Enfin, nous tenons à exprimer notre gratitude envers toutes les

personnes du Thicrew qui ont contribué à la réalisation de ce livre par leur
relecture, leur soutien ou leur conseil.
203
 REMERCIEMENTS
GLOSSAIRE Agilité
L’Agilité est une approche de gestion et de développement axée sur la
collaboration et l’adaptation au changement. Elle favorise des livraisons
itératives et continues. L’approche Agile est décrite dans un manifeste
regroupant 4 valeurs et 12 principes.

Voir chapitre 11

API
Les API (Application Programming Interface) permettent de faire communiquer
front-end et back-end au travers d’échange de données. Elles servent aussi
à faire communiquer des back-ends de différents services. Une API est
comme un contrat entre deux systèmes où une demande avec une donnée
en entrée permet d’obtenir de nouvelles données en retour.

Back-end
Le back-end est la partie algorithmique, celle où on retrouve l’implémentation
des différentes règles métier et qui permet d’accéder à la base de données.

Backlog
Un backlog est un ensemble ordonné d’éléments à réaliser pour délivrer le
produit.

Voir chapitre 10

Critères d’acceptation
Les critères d’acceptation sont les conditions qu’une fonctionnalité doit
remplir pour répondre aux besoins utilisateur. Ils peuvent être validés
grâce à des tests dits tests d’acceptation.

Voir chapitres 10 et 14

205
GLOSSAIRE

GLOSSAIRE
Definition of Done (DoD)
CSAT
La Definition of Done est un contrat passé avec l’équipe de développement,
Le CSAT (Customer Satisfaction Score) est une mesure utilisée pour évaluer et regroupe sous forme de liste, l’ensemble des critères que doit respecter
la satisfaction des utilisateurs vis-à-vis d’une expérience spécifique. Il est une User Story pour être considérée comme terminée.
généralement obtenu en posant une question à laquelle les clients peuvent
répondre en utilisant une échelle de notation, par exemple de 1 à 5, pour Voir chapitre 14
indiquer leur niveau de satisfaction et en définissant le seuil à partir duquel
on considère un utilisateur satisfait.

Definition of Ready (DoR)

Customer Lifetime Value La Definition of Ready est un contrat passé avec l’équipe de développement, et
regroupe sous forme de liste les éléments attendus pour qu’une User Story
La Customer Lifetime Value (valeur de la vie du client) est une mesure qui passe en développement.
estime la valeur financière totale qu’un client apporte à une entreprise tout
au long de sa relation avec celle-ci. Il prend en compte les revenus générés Voir chapitre 10
par le client, les dépenses liées à la fidélisation et à l’acquisition de ce client,
ainsi que la durée de vie prévue de la relation client.

Customer success
Le customer success est une fonction axée sur la satisfaction et la réussite
des clients d’une entreprise. Il vise à aider les clients à tirer pleinement parti
des produits proposés par l’entreprise et à obtenir une valeur maximale de
leur investissement. Les professionnels du customer success travaillent en
étroite collaboration avec les clients, fournissant un soutien, des conseils,
des formations et des ressources pour garantir leur satisfaction à long
terme.
Cycle time
En Kanban, le Cycle time permet de mesurer le temps pour passer d’une
étape à une autre, et permet de détecter les goulots d’étranglement.
Delivery
Le delivery fait référence au processus de mise à disposition d’un produit,
d’une fonctionnalité auprès des utilisateurs. Cela implique la planification, la
coordination et le développement nécessaires pour livrer le produit tout en
veillant à la qualité.
Voir module 3
Design thinking
Le Design thinking est une méthode de conception itérative centrée sur
l’utilisateur. Elle permet de faire émerger de nouvelles idées en creusant
d’abord les problèmes utilisateur avant de concevoir et tester des solutions
pour y répondre.

Voir chapitre 11
Discovery
La discovery est un processus de dérisquage qui, à travers un contact
régulier avec les utilisateurs, des ateliers et outils adaptés, permet de définir
la meilleure solution pour répondre aux besoins de vos utilisateurs.

Voir chapitre 5
206 207
GLOSSAIRE
Epic
Une Epic est une brique fonctionnelle à valeur et décrit une partie de la
solution à développer pour répondre au problème identifié. L’Epic est un
conteneur de plusieurs User Stories qui, lorsqu’elles sont développées,
contribuent à délivrer la valeur ciblée.
Voir chapitre 10
Fonctionnalité
Une fonctionnalité est un ensemble de solutions qui ont été dérisquées
en discovery. Les fonctionnalités peuvent passer en delivery pour être livrées
aux utilisateurs.
Voir chapitre 4
Front-end
Le front-end est la partie visible de l’application, les interfaces pour les
utilisateurs (aussi appelé IHM pour Interface Homme-Machine).
Go-To-Market
La stratégie Go-To-Market ou lancement de produit permet d’amener un
produit sur le marché en découpant chaque étape du lancement et structurer
chacune des actions en amont, lancement et post-release.
Heatmap
Une heatmap (carte thermique) est une représentation visuelle qui met en
évidence les zones d’intérêt sur une interface. Elle permet de visualiser les
zones où les utilisateurs cliquent, passent le plus de temps, ou interagissent
le plus fréquemment.
208
GLOSSAIRE
Hotfix
Un hotfix est une mise à jour logicielle qui est appliquée rapidement pour
corriger un problème spécifique, généralement pour résoudre des bugs
critiques ou des failles de sécurité. Contrairement à une mise à jour planifiée,
un hotfix est déployé de manière urgente sans attendre la prochaine version.
Voir chapitre 19
Initiative
Les initiatives représentent les sujets de l’équipe et peuvent se présenter
sous forme d’opportunités, pour lesquelles il faudra d’abord passer par une
phase de discovery ou de fonctionnalités, qui sont déjà passées en discovery
et qui peuvent passer en delivery.
Voir chapitre 4
Insight
Un insight donne une explication contextualisée de faits constatés, qu’il
s’agisse de problèmes ou constats positifs.
Voir chapitre 3
Kanban
Kanban est un framework Agile qui préconise de visualiser le travail de
l’équipe dans un tableau pour suivre et optimiser les différentes tâches et
fonctionnalités. Cette approche permet d’améliorer la collaboration, de
limiter le travail en cours et d’optimiser le flux de travail, favorisant ainsi
une livraison plus rapide et une meilleure qualité des fonctionnalités
développées.
Voir chapitre 11
209
GLOSSAIRE
KPI
Un KPI (Key Performance Indicator) est un indicateur de performance clé
qui mesure les éléments les plus importants pour votre produit et l’atteinte
de vos objectifs à long terme. Il évalue l’état de santé de votre produit (par
exemple : 75 % d’utilisateurs actifs mensuels sur le trimestre).
Voir chapitre 16
Lead time
En Kanban, le lead time mesure en jours le temps total nécessaire pour réaliser
un élément du backlog, depuis sa création jusqu’à la livraison.
Voir chapitre 12
Lean Startup
L’approche Lean Startup met à disposition une multitude de concepts et
outils (Lean Canvas, MVP, boucle d’apprentissage) permettant de réduire le
« gâchis » de temps et d’argent souvent observé lors de la conception d’un
produit.
MVP
MVP (Minimum Viable Product) signifie « produit minimum viable », mais
s’apparente surtout à un processus. Le concept repose sur la boucle Build-
Measure-Learn de la méthodologie Lean Startup et permet de tester un
produit ou une fonctionnalité minimale auprès d’une cible restreinte pour
répondre à un problème spécifique. L’objectif du MVP est de recueillir les
retours des utilisateurs et apprendre rapidement afin d’itérer et d’améliorer
le produit par la suite.
Voir chapitre 8
210
GLOSSAIRE
NPS
Le NPS (Net Promoter Score) est une mesure utilisée pour évaluer la
satisfaction et la fidélité des utilisateurs. Il est basé sur une simple question :
« Sur une échelle de 0 à 10, dans quelle mesure recommanderiez-vous notre
produit/entreprise/service à un ami ou un collègue ? ». Les réponses sont
ensuite classées en trois catégories : les promoteurs (notant 9 ou 10), les
passifs (notant 7 ou 8) et les détracteurs (notant de 0 à 6). Le NPS représente
la différence entre les promoteurs et les détracteurs.
OKR
OKR (Objectives and Key Results) est une méthode de définition et de suivi
des objectifs stratégiques d’une entreprise. Elle consiste à fixer des objectifs
clairs et mesurables, et définir les résultats clés à atteindre.
Voir chapitre 2
Onboarding
L’onboarding sur un produit est le processus de familiarisation et de mise
en route lorsqu’un utilisateur commence à utiliser le produit. Son objectif
est de faciliter l’adoption du produit et d’assurer une expérience utilisateur
optimale dès le début.
Opportunité
Une opportunité est un sujet relativement gros dont il faut s’occuper, qui
peut être découpé en plusieurs sous-opportunités dont on ne connaît pas
encore les solutions. L’opportunité doit d’abord passer par une phase de
discovery pour en préciser le problème à résoudre et les solutions pour y
répondre.
Voir chapitre 3
211
GLOSSAIRE
Persona
Un persona est un utilisateur type fictif, basé sur des données utilisateur
dont il est censé représenter et synthétiser les objectifs et les motivations.
Voir chapitre 6
Proposition de valeur unique
UVP (Unique Value Proposition) est l’expression unique de la valeur d’un
produit, qui le distingue de la concurrence et attire les clients. C’est une
déclaration concise qui met en évidence les avantages spécifiques et les
raisons pour lesquelles les clients devraient choisir le produit plutôt qu’un
autre.
Voir chapitre 5
Release
Une release est une version spécifique d’un logiciel, d’une application ou d’un
produit qui est prête à être mise à disposition des utilisateurs. Les fonction-
nalités et les corrections de bugs sont regroupées et livrées en tant qu’en-
semble cohérent, identifié par un numéro de version ou un nom spécifique.
Voir chapitre 13
Release plan
Le release plan est utilisé pour planifier le développement des fonctionnalités
à court terme. Il définit l’ordre des différentes versions, en prenant en compte
les priorités et les contraintes.
Voir chapitre 12
212
GLOSSAIRE
Rétrospective (rétro)
La rétrospective est un rendez-vous qui permet de faire un bilan d’une
période passée (un sprint, un trimestre, un projet). L’objectif de la rétrospective
est pour l’équipe Produit ou l’équipe élargie (avec les parties prenantes) de
détecter des actions d’amélioration continue à mettre en place.
Voir chapitres 11 et 20
Roadmap
Une roadmap est une représentation graphique simplifiée permettant de
communiquer et de partager efficacement une intention stratégique afin de
mobiliser, d’aligner et de coordonner les efforts des parties prenantes pour
atteindre un ou plusieurs objectifs.
Voir chapitre 4
Scrum
Scrum est un framework Agile axé sur la collaboration, l’itération et
la livraison continue de fonctionnalités. Il se caractérise par des cycles
de développement courts appelés « sprints », des réunions régulières de
planification et de revue, et une équipe auto-organisée.
Voir chapitre 11
SQL
SQL (Structured Query Language) est un langage de programmation utilisé
pour manipuler des bases de données relationnelles. Il permet d’effectuer
des opérations telles que la création, la modification et la suppression de
données, ainsi que la gestion des structures de la base de données.
213
GLOSSAIRE

Taux de conversion
Le taux de conversion est une métrique utilisée pour mesurer le pourcentage
d’utilisateurs ou de visiteurs qui effectuent une action souhaitée, telle que
faire un achat, s’inscrire à une newsletter ou remplir un formulaire.
GLOSSAIRE
Vélocité
La vélocité, utilisée en Scrum, est une mesure de la quantité de travail
qu’une équipe peut accomplir lors d’un sprint. Elle sert à estimer la capacité
de l’équipe et à planifier les futurs sprints.

Voir chapitre 12
Taux de rebond
Le taux de rebond est une métrique utilisée pour mesurer le pourcentage
de visiteurs qui quittent un site après avoir consulté une seule page, sans
effectuer aucune autre action.

UI
L’UI (User Interface) ou interface utilisateur en français, englobe
essentiellement tous les éléments graphiques visibles qui permettent à
un utilisateur d’interagir avec le produit. Elle inclut les éléments tels que
les menus, les boutons, les icônes, les formulaires et les autres éléments
graphiques qui permettent aux utilisateurs de naviguer et d’effectuer des
actions.

User Story
Une User Story (US) est une description fonctionnelle détaillée. Une User
Story décrit un besoin utilisateur et précise comment faire évoluer le
produit pour y répondre.

Voir chapitre 10

UX
L’UX (User eXperience) est le domaine qui se concentre sur l’expérience
globale d’un utilisateur, son ressenti, son comportement, lorsqu’il interagit
avec un produit. L’UX englobe tous les aspects de cette expérience,
notamment l’ergonomie et la facilité d’utilisation. L’UX met l’accent sur
la recherche utilisateur, la conception centrée sur l’utilisateur et les tests
d’utilisabilité pour optimiser la satisfaction et l’engagement des utilisateurs.

214 215
 Notes Notes

216 217
 Notes Notes

218 219
 Notes Notes

220 221
 Notes Notes

222 223
 Vous voulez en savoir plus ?

Retrouvez nos précédents livres sur le site thiga.co

224
Que vous soyez néophyte ou expert en Product Management, ce livre
est fait pour vous ! Cette discipline occupe une place essentielle dans les
organisations qui mettent les solutions numériques au premier plan de
leur stratégie.

Tout comme le sportif qui fait son entraînement quotidien ou le musicien

qui révise ses gammes, il y a des fondamentaux du Produit auxquels les
Product Managers reviennent sans cesse, et ce quel que soit leur niveau
de séniorité. Vous apprendrez comment :

• Définir une vision Produit et une roadmap orientée objectifs ;

• Concevoir les fonctionnalités adaptées aux utilisateurs ;
• Améliorer votre produit en continu après la mise en production ;
• Adopter la bonne posture pour collaborer avec vos parties
prenantes et travailler en équipe.

Préface de Christopher Parola, Chief Product Officer de Yousign :

« Vous trouverez dans ces pages non pas une formule magique ou un
framework supplémentaire, mais plutôt un mélange d’observations et
de conseils concrets sur la manière de construire et de maintenir un
produit numérique solide. »

« Chloé et Floriane ont réussi l’impossible : couvrir TOUTES les facettes

de la gestion d’un produit digital, avec la plus grande pédagogie » — Rémi
Guyot, auteur de Discovery Discipline et ex-Chief Product Officer chez
BlaBlaCar.