table des matiÈres - thiga.fr · par des missions de conseil en stratégie et en organisation...

6

TABLE DES MATIÈRES

À propos de Thiga ............................................................................. 7

Introduction ....................................................................................... 9

Les auteurs et les contributeurs ...................................................11

Chapitre 1 : Qu’est-ce qu’une organisation Produit ? ....................15

Chapitre 2 : Comment piloter les objectifs

d’une équipe Produit ? ....................................................................29

Chapitre 3 : Comment découper les équipes ? .............................45

Chapitre 4 : Comment gérer les adhérences ? .............................63

Chapitre 5 : Quels profils Produit recruter lorsque

mon organisation passe à l’échelle ? .............................................85

Chapitre 6 : Comment industrialiser

le Product Discovery ? ..................................................................109

Chapitre 7 : Comment gérer les retours utilisateurs

à l’échelle ? ....................................................................................125

Conclusion .....................................................................................142

Glossaire ........................................................................................146

Les organisations orientées Produit / 7

À PROPOS DE THIGA

Notre manifeste

Chez Thiga, nous aimons en faire un peu plus. Pas un peu trop. Juste un peu plus.Ce qu’il faut pour toujours être à la pointe, et continuer à nous amuser sur des pro-blématiques inédites. Depuis nos débuts, nous créons des liens forts avec nos équipes et nos clients, ce qui nous permet d’être ce pure player du Product Management qui n’a jamais cessé de repenser son métier.

Nous sommes convaincus que ce sont nos collaborateurs qui font la différence, et c’est pourquoi nous privilégions les affinités des Thiguys avec les projets, car cela ne les rend que meilleurs.

Notre qualité d’experts sur nombre de sujets nous permet de passer une bonne par-tie de notre temps à transmettre tout ce que nous savons. À partager régulièrement toutes les nouveautés et bonnes pratiques du marché. Nous sommes aussi obsédés par les grandes idées qu’exigeants sur les petits détails d’exécution.

Nous avons l’expertise pointue d’un cabinet de conseil et l’état d’esprit agile d’une start-up et nous mettons un point d’honneur à faire notre métier sérieusement, sans jamais nous prendre au sérieux.

Product Management. Redefined

Thiga est un cabinet international de conseil et d’innovation en Product Management.

8

Pour toutes ces raisons, nous avons développé une approche nouvelle des métiers de Consultant, de Product Manager, de Product Owner et de Product Designer.

Une façon différente de penser les problématiques de nos clients et de les accom-pagner dans la construction de ce qui se fait de mieux sur le marché des Produits digitaux. Nos activités

Par des missions de conseil en stratégie et en organisation Produit, au travers de notre organisme de formation Thiga Academy ainsi que par l’immersion de Product Managers, Product Owners et Product Designers d’excellence, nous aidons les en-treprises à construire des Produits numériques à succès.


INTRODUCTIONEn 2015, nous publiions notre premier livre Product Academy I : “Le guide des Pro-duct Managers et Product Owners d’élite” avec l’ambition d’apporter un éclairage pragmatique sur les métiers du Product Management, alors relativement nouveaux en France. En 2017, nous éditions le second volume de Product Academy, dédié au Growth, recensant des conseils actionnables pour décupler la croissance des Pro-duits numériques.

Pour ce troisième ouvrage, nous avons décidé de nous attaquer avec le même état d’esprit aux organisations Produit, c’est-à-dire à l’ensemble des processus, rôles, rituels et outils permettant d’imaginer, de concevoir et d’améliorer des Produits nu-mériques en continu. Le choix de cette thématique repose sur plusieurs constats :

• Une multitude de CPOs (Chief Product Officers) avec lesquels Thiga interagit quo-tidiennement se pose des questions fondamentales relatives à leur organisation sans parvenir à obtenir de réponses précises.

• La littérature (y compris anglo-saxonne) sur les organisations en Product Manage-ment est encore peu fournie et parcellaire.

• Thiga, en tant qu’animateur de premier plan de la communauté Produit française, et fort d’une cinquantaine de Thiguys répartis dans de nombreuses directions Produit, recense continuellement des bonnes pratiques en matière d’organisation et sou-haite les partager avec le plus grand nombre.

Ce livre s’adresse aux CPOs souhaitant structurer leur organisation en vue de faire les meilleurs Produits numériques possibles. Il s’articule autour de 7 chapitres ci-blant leurs problématiques centrales : “Quels profils sont nécessaires au bon fonc-tionnement d’une organisation Produit ?” ; “Comment gérer les adhérences entre mes équipes et le reste de l’organisation ?” ; “Comment piloter les objectifs de mes équipes ?” ; “Comment passer mon organisation à l’échelle suite à une levée de fonds ?” …

10

Cet ouvrage se veut concret et actionnable sans pourtant être dogmatique. Nous pensons, en effet, qu’il y n’a pas d’organisation magique duplicable partout. Une or-ganisation est basée sur un historique, une culture propre à chaque entreprise et est amenée à être perpétuellement adaptée au cours du cycle de vie du Produit.

Les bonnes pratiques recensées dans cet ouvrage reposent sur les retours d’expé-rience des Thiguys ainsi que sur le vécu d’une trentaine de CPOs que nous avons interviewés pour l’occasion.

Bonne lecture !

Alexandre Irrmann-Tézédirecteur général de Thiga


LES AUTEURSAlexandre Irrmann-Tézé : Diplômé de Télécom ParisTech, Alexandre a débuté sa carrière dans les équipes Télécom & Média d’un grand cabinet de conseil en management. En 2014, il co-crée Thiga, cabinet de conseil et organisme de formation spécialisé en Product Manage-ment. Au sein de Thiga, Alexandre dirige des missions d’organisation visant à amé-liorer la manière de créer des Produits numériques. Alexandre est également coach et formateur en Product Strategy auprès de start-ups, PME et grands groupes.

Maria Frih :Après son diplôme obtenu à l’EM Lyon, Maria a pris un poste de Product and Marke-ting Analyst. Rapidement conquise par le métier de Product Manager, elle passe par Lucca avant de rejoindre Thiga quelques mois après la création du cabinet. Depuis son arrivée, Maria a pu travailler pour divers clients en tant que Product Manager, et elle occupe en parallèle de ses missions un rôle de Manager.

Simon Joliveau-Breney : Avant de rejoindre Thiga, Simon a travaillé dans un cabinet de conseil en marketing stratégique spécialisé dans les problématiques Télécom, Média, et digitales. Au sein de Thiga, Simon intervient sur des missions visant à définir la vision de Produits en rupture et des missions d’organisation en Agile Product Management.

Nous n’aurions jamais été capables de mener cet ouvrage à son terme sans l’investissement des Thiguys qui ont conduit les interviews, relu et corrigé. Nous les remercions chaleureusement !• Rémi Favre• Romain Monclus• Julien Michel• Etienne Bousquié• Benjamin Fourio• Fabien Levrey• Claire Bonnet

12

LES CONTRIBUTEURSCe livre été écrit en s’appuyant sur les témoignages des responsables Produit d’une trentaine de sociétés françaises et internationales parmi les plus matures en Pro-duct Management. Nous les remercions pour leur passion, leur gentillesse et leur disponibilité.

• Algolia, Maxime Prades, VP of Product Management• Azalead Jean-Yves Simon, Head of Product• Bankin’, Nicolas Martin, CPO• BlaBlacar, Benjamin Retourné, Lead Product Manager• Captain Contrat, Julien Janson, Product Director• Captain Contrat, Maxime Wagner, Co-founder & COO• Chauffeur Privé, Matthieu Reboul, Lead product Manager• Chauffeur Privé, Rémi Bardoux, Head of Product & Design• Deezer, Fabrice Des Mazery, Head of Product and Growth• Deezer, Benjamin Moitié, Head of effectiveness• Drivy, Nicolas Mondollot, Co-founder & CPO• Drivy, Charles Vahanian, Lead Product Owner• Fixter, Frédéric Dermer, CPO• Gemalto, Frédéric Martinent, Head of Mobile Marketing• Kisio Digital, Laurent Leca, CPO• L’Express, Alexandre Takacs, Director of Product & UX• Leboncoin, Jean-Baptiste d’Anchald, Senior Product Manager• Leboncoin, Abderrahmane Abdallahoum, Head of UX• M6 Web, Renaud Vaillant, Directeur Pôle Digital Consumer• ManoMano, Pierre Fournier, Head of Product• Molotov.tv, Damien Delautier, Head of Product• Ooreka, Augustin Vexiau, Head of Product• OUI.sncf, Yannick Combourieu, Head of Product Management• OuiCar, Teresa Karrer, CPO• SeLoger, Sandy Castagna, Head of Product - Mobile• Sirup lab (ex Evernote), Xavier Delplanque, Digital Product Maker• Spicesoft, Yolène Louison, Product Manager • Vente-Privée, Alexia Boulot, Lead Product Owner• Wynd, Benoît Bourdon, VP Product

15

QU’EST-CE QU’UNE ORGANISATION PRODUIT ?

CHAPITRE 1

16

Offrir une expérience numérique différenciante est devenu aujourd’hui un important facteur de succès pour une entreprise, au-delà des pure players digitaux. Cette exi-gence pousse à placer davantage le “Produit numérique” au cœur des organisations, et à rendre celles-ci plus agiles, dans l’idée d’améliorer les Produits de manière plus fréquente et plus à l’écoute des utilisateurs. Cependant, les organisations tradition-nelles en silo (Marketing, Ventes, Technique…) sont des freins à cette transforma-tion. En tant que CEO ou CPO, je souhaite prouver l’intérêt d’avoir une équipe Produit dédiée et je m’interroge sur la composition de cette équipe.

Chez Thiga, nous préconisons de casser les silos traditionnels des organisations en créant une organisation Produit regroupant toutes les compétences nécessaires pour concevoir, développer et promouvoir des Produits numériques. Cela inclut a minima des Product Owners ou Product Managers, des Product Designers, des dé-veloppeurs, et potentiellement d’autres profils complémentaires.

Solution

Problème


Dans la plupart des entreprises ayant atteint une certaine taille, on retrouve en géné-ral - outre de nombreuses fonctions supports - 3 départements majeurs : Marketing, Ventes et Technique.

Souvent, le Produit - qu’il soit numérique ou pas - n’est qu’un élément du Marketing mix, des fameux “4P” qui incluent également le prix, la communication (promotion en anglais), et la distribution (placement). Il est donc fréquemment pensé par le dé-partement Marketing, avant d’être développé dans un autre département de l’organi-sation. Mais il arrive également qu’il constitue la prérogative d’un autre département, la Technique par exemple.

Notre conviction est très claire : si les compétences liées au Produit sont logées dans un silo (Marketing, Technique, Ventes…), ou éparpillées au sein de l’organisa-tion, cela limitera leur capacité d’action et produira en retour de la dette Produit.Qu’est-ce que la dette Produit ? Ce concept représente le résultat de décisions à visées court-termistes qui se révèlent extrêmement coûteuses à long terme pour votre Produit (en perturbant l’expérience utilisateur, en créant des fonctionnalités difficiles à maintenir ou faire évoluer…).

Le type de dette dépend en général du silo dans lequel on place la fonction Produit : en caricaturant à peine, les Ventes vont par exemple avoir tendance à se faire dic-ter la roadmap par le dernier client rencontré ; la Technique poussera parfois des solutions technologiques pas forcément corrélées à une valeur business ou aura tendance à minimiser le nombre de nouvelles fonctionnalités pour prioriser la sta-bilité du Produit ; enfin, le Marketing peut tendre à développer toujours plus de fonc-tionnalités sans échanger suffisamment avec la Technique et en priorisant des cas d’usage “à la mode”.

Que vous soyez un pure-player du numérique ou pas, le “P” du Produit numérique prend aujourd’hui une importance croissante dans cette équation : offrir une expé-rience numérique différenciante est devenu un facteur de succès pour toute entre-prise. L’émergence de la discipline du Product Management acte le fait que conce-voir et promouvoir des Produits numériques ne peut plus être la prérogative du département Marketing, ni être décorrélé du développement. Plusieurs facteurs vont en effet dans le sens d’une prise d’autonomie du Produit :

18

• L’omniprésence des retours utilisateurs : aujourd’hui, le contact avec l’utilisateur est disséminé partout dans l’organisation, et il est possible de collecter facilement des retours sans forcément passer par les processus traditionnels longs et coû-teux propres au Marketing (focus group, études de marché...)

• L’accélération de l’innovation : les cycles de développement et d’innovation s’accé-lèrent, et nécessitent d’itérer de manière toujours plus rapide sur les Produits. Avoir une équipe pluridisciplinaire chargée du Produit permet de réduire les pesanteurs dans la décision et d’être plus réactif, là où diluer les responsabilités dans plusieurs silos a tendance à ralentir les processus de décision et à dégrader l’expérience client.

• La nécessité d’échouer pour rebondir : il est rare de connaître le succès du pre-mier coup, d’autant plus dans le cadre d’un Produit numérique ; vous devrez sans doute passer par plusieurs expérimentations avant de trouver votre marché. Avoir une équipe Produit pérenne permet de s’assurer qu’on ne perd pas de vue la vision d’ensemble et de long terme.

• Les frontières entre le Marketing web et le Product Management s’estompent, et de nombreuses activités Marketing (connaissance des utilisateurs, pilotage de l’acquisition, mesure et maîtrise de la satisfaction utilisateur) sont aujourd’hui in-dissociables des caractéristiques du Produit lui-même.

Pour créer un Produit réellement différenciant, il faut donc lui donner une place cohé-rente dans l’organisation. Si le numérique est pour vous une activité essentielle, vous aurez tout intérêt à adopter une organisation orientée Produit de type éditeur de logi-ciel, c’est-à-dire en sortant des silos fonctionnels et en créant un département dédié.


Notre vision de l’organisation Produit idéale consiste à regrouper au sein du même département toutes les personnes partageant une même mission : “créer et promou-voir le meilleur Produit numérique possible, pour l’ensemble des utilisateurs, en pre-nant en compte les contraintes et objectifs des parties prenantes internes”. L’équipe Produit doit être au maximum autonome dans l’accomplissement de cette mission (ce qui ne l’empêche pas, bien sûr, de collaborer avec d’autres entités ou d’être sou-tenue par des équipes supports) ; elle dispose de son propre budget ; et elle doit pou-voir arbitrer constamment entre les différents besoins liés au Produit et les prioriser. Logiquement, elle inclut l’ensemble des profils et compétences nécessaires.Son directeur, le CPO - Chief Product Officer (parfois aussi appelé Head of Product ou VP Product), doit rapporter directement au CEO au même titre que le CTO ou le Directeur Commercial.

COMITÉ DE DIRECTION

Chief Product Officer

Product Manager

Product Manager

Équipe produit

(En option) :Product Managers

Squads :Product Owners,développeurs,Product Designers,testeurs

L’organisation Produit idéale

Organisation Produit idéale

20

De quoi se compose cette équipe Produit ?

Un CPO Son rôle consiste à définir la vision pour le Produit à horizon 1 à 3 ans, à aider ses équipes à décliner les objectifs stratégiques en leviers d’action opérationnels (voir chapitre 2 “Comment piloter les objectifs d’une équipe Produit ?”), superviser parfois le recrutement au sein de l’équipe, construire les plans de carrière et arbitrer sur des problématiques de stratégie Produit. Membre du comité de direction, il représente également l’équipe auprès de la direction générale, et peut piloter les éventuels par-tenariats, acquisitions, ou négociations avec des tierces parties.

Un ou plusieurs Product Managers

Ils portent la vision Produit, en déclinant à un niveau plus opérationnel et granulaire les objectifs et la stratégie définis par le CPO. Ils sont la voix de l’utilisateur auprès du CPO. Leur intervention est souvent centrée sur un périmètre fonctionnel donné, ou un ensemble de fonctionnalités. Ils pratiquent la veille Produit, marché ou tech-nologique, pilotent une roadmap à moyen-terme, dérisquent les innovations en s’ap-puyant par exemple sur les pratiques Lean Startup ou Design Thinking et travaillent avec les Product Owners et les développeurs pour articuler la roadmap à 6 mois et les priorités à court terme du Produit. Ils sont capables de construire un modèle éco-nomique, d’évaluer et prioriser des opportunités business. Enfin, ils sont chargés de définir et de suivre les principaux KPIs des Produits et fonctionnalités qu’ils créeront avec les Product Owners : taux d’utilisation, activation, rétention…Dans une organisation Produit de taille importante, on peut mettre en place une hié-rarchie avec plusieurs niveaux, dont des Lead Product Managers se plaçant entre le CPO et les autres Product Managers et assurant la gouvernance globale de plusieurs squads.

Un ou plusieurs Product Owners

Dans certaines organisations, ce rôle peut être cumulé avec celui de Product Manager. De manière générale, si vous avez une équipe Produit réduite, opérez sur un marché peu risqué, ou disposez d’une personne ayant à la fois de bonnes connaissances tech-niques, agiles et marché, il est tout à fait possible de cumuler les deux postes.


Le Product Owner est le représentant des utilisateurs du Produit au sein d’une squad. Son rôle est de maximiser la valeur du Produit, en construisant et priorisant son backlog au quotidien, et en pilotant les sprints de développement. Loin d’être un simple exécutant de la stratégie, il participe à la conception Produit : sur de l’amé-lioration continue ou des itérations sur des solutions déjà en place, il est maître de son backlog, et il participe à la phase de conception pilotée par le Product Manager pour les sujets arrivant dans 3 à 6 mois (voir chapitre 6 “Comment industrialiser le Product Discovery ?”).

Un ou plusieurs Product Designers (UX / UI)

La première responsabilité des Product Designers consiste à mener la recherche utilisateur (en collaboration avec les Product Owners et Product Managers). Ils construisent, priorisent puis testent des hypothèses, que ce soit sur les besoins uti-lisateurs ou les solutions proposées. Ils modélisent également des parcours utilisa-

Product Manager Vision moyen - long terme

3 mois 6 mois 12 mois

Chief Product Officer Vision cible annuelle

Product OwnerVision court - moyen terme

Temporalités des rôles de Chief Product Officer, Product Manager et Product Owner

22

teurs, et créent des prototypes qui pourront ensuite être testés auprès de prospects ou bêta-testeurs.Enfin, ils sont garants du respect des règles d’ergonomie et de la charte graphique.Certains profils sont plus proches de la recherche et des tests utilisateurs (UX) et du prototypage (basse fidélité), et d’autres plus axés sur la conception graphique (UI) et les animations. L’essentiel consiste à avoir toutes les compétences nécessaires dans l’équipe, qu’elles soient réparties entre 1 ou 2 Product Designers.

Un ou plusieurs Growth Product Managers

Ils sont chargés d’assurer la croissance du Produit, en utilisant les techniques d’ac-quisition et de rétention souvent regroupées sous le terme de “Growth Hacking” ou “Growth Marketing”. Les Growth Product Managers sont friands de données à ana-lyser et souvent objectivés sur l’atteinte de KPIs (par exemple : “augmenter le taux d’activation de 10% d’ici 3 mois”). Ils doivent travailler en forte proximité avec les Product Managers et Product Owners car les fonctionnalités et les évolutions Pro-duit restent souvent in fine le principal levier de croissance. Qu’ils disposent d’un groupe de développeurs dédié pour leurs expérimentations, ou partagent une squad avec d’autres Product Owners, l’essentiel consiste à leur offrir de la bande passante de développement pour permettre les tests à haute fréquence. Pour en savoir plus sur ces profils, n’hésitez pas à consulter le Volume 2 de Product Academy : le guide du Growth.

Les autres compétences d’une équipe Produit

Les profils ci-dessus sont les indispensables pour toute équipe Produit. Cependant, d’autres compétences peuvent avoir toute leur place dans cette équipe, en fonction du contexte et des spécificités du Produit.

Data Analyst / Business Intelligence Analyst

Les autres départements de l’entreprise comme le Marketing, mais aussi les Product Owners ou Product Managers sont parfois friands de tableaux de bords et d’ana-


lyses de données, sans pour autant avoir du temps à y consacrer. Aussi, il peut être utile d’avoir au sein de l’équipe Produit un profil de Data Analyst dédié à l’installation, au suivi et au pilotage des analytics. Cette personne est le point d’entrée pour toute question liée aux analytics ; sans être statisticien confirmé, il maîtrise les différentes sources de données disponibles et est également capable de faire des croisements et des analyses pour transformer les données brutes en informations utiles aux équipes qui en ont besoin pour factualiser leur prise de décision.

Data Scientist

De plus en plus d’équipes intègrent également une dimension Data, sous la forme de profils de Data Scientists et de Data Engineers. Les Data Scientists construisent des modèles, des algorithmes, pilotent des démarches de machine learning ; les Data Engineers sont quant à eux chargés de l’ingestion des données, de la maintenance du data lake et de l’industrialisation des travaux effectués par les Data Scientists. Si votre Produit capitalise en grande partie sur la donnée ou intègre des fonctionnalités reposant sur des algorithmes assez poussés (par exemple, un moteur de recom-mandation tel que le feed Facebook), il est indispensable d’avoir ces profils au sein de votre équipe Produit. Dans tous les cas, en fonction de votre budget, l’intégration de profils Data Scientists peut apporter beaucoup à une équipe Produit.

Notez que si vous souhaitez intégrer ces Data Scientists au plus près du Produit et non les spécialiser dans la R&D, vous aurez sans doute besoin d’un Data Product Manager dédié, habitué à transcrire les problématiques business en projets data.

QA (Assurance Qualité / Testeurs)

Un bug ou une rupture de service peut avoir un impact fort sur votre Produit et donc votre entreprise, qu’il s’agisse d’image (mauvais retours utilisateurs, commentaires sur les app stores) ou directement de business : par exemple, pour un site de ré-servation de train comme Oui SNCF, une journée d’indisponibilité se traduit par une perte immédiate de chiffre d’affaires.Si l’assurance qualité est un enjeu fort pour votre Produit, et que les Product Owners et Product Managers ne peuvent pas gérer seuls tous les tests fonctionnels (ce qui est souvent le cas), vous devrez intégrer des compétences QA dans l’équipe Produit : soit en transverse, soit directement dans chaque squad.

24

LE RÔLE DE PROGRAM MANAGER CHEZ ZENDESK

Zendesk est organisée en squads Produit très autonomes, chacune in-tégrant tous les rôles nécessaires à la conception et au développement, représentée par son propre Product Manager.

Pour autant, la gestion des projets transverses impactant plusieurs équipes et la communication entre les équipes sont toujours un défi. Pour cela, un rôle au croisement du chef de projet et du facilitateur a été mis en place : le Program Manager. Son rôle consiste à :• porter des projets transverses d’envergure (refonte technique, confor-

mité, rebranding) en assurant la synchronisation entre les différents Product Managers / Product Owners et Product Designers

• identifier des pistes d’optimisation du travail et de la communication en interne, pour fluidifier les échanges

• repérer les personnes travaillant sur des sujets similaires dans l’orga-nisation pour les mettre en relation

• s’assurer que la documentation est mise à jour et faciliter le partage de la connaissance

Si la communication devient catastrophique dans vos équipes, que les dates butoirs sont de moins en moins respectées ou que les projets transverses patinent, c’est peut-être le signe que vous avez besoin d’un tel profil.

Le cas des développeurs

Nous n’avons pas encore abordé le sujet des développeurs… Pourtant, bien sûr, il paraît impossible de développer un Produit numérique sans bon développeur. De fait, ils sont au cœur du Produit : dans l’idéal, il ne doivent pas être isolés au sein d’un département Tech-nique travaillant en mode “fournisseur” pour un autre département. Ils sont également une source importante d’idées et d’innovations pour le futur de votre entreprise.Doivent-ils pour autant faire partie intégrante de l’équipe Produit ? Une telle approche conduirait dans la plupart des cas à transférer un nombre considérable de déve-loppeurs de la Technique vers le département Produit. Cette approche n’est pas dé-nuée de risques, car le département Produit et son CPO se retrouve alors juge et par-tie sur les questions techniques. Il peut, par exemple, devenir délicat pour un Product Manager de prioriser de la réduction de dette technique au détriment de nouvelles


fonctionnalités très attendues par les utilisateurs… Le maintien d’un département technique mené par un CTO favorise parfois une logique de débat et d’arbitrage entre CTO / CPO qui permet in fine de trouver un équilibre entre “Produit” et “Tech”.

Que les développeurs soient rattachés hiérarchiquement à une entité distincte de l’équipe Produit, ou directement intégrés dans le même département, là n’est fina-lement pas l’essentiel : le plus important est que développeurs, Product Designers, Product Owners et autres profils Produit travaillent ensemble au quotidien dans des équipes pluridisciplinaires et pérennes (voir chapitre 3 “Comment découper les équipes ?”). Il faut également que leurs objectifs soient alignés avec ceux de l’équipe Produit, et non pilotés par leur manager “fonctionnel” côté Technique : pour cela, les OKRs peuvent constituer un outil pertinent (voir chapitre 2 “Comment piloter les objectifs d’une équipe Produit ?”).

Que deviennent les autres fonctions traditionnelles de l’entreprise ?

Les départements fonctionnels Marketing, Ventes, Technique, RH, Finance conti-nuent en général d’exister autour de l’organisation Produit, mais leur rôle est modifié.

Le Marketing se recentre sur 3 des 4P

Dans cette nouvelle organisation, le Marketing laisse au département Produit la main... sur le Produit. Il perd parfois également des responsabilités sur l’acquisition de nouveaux clients ou prospects, qui dans le cadre d’un Produit digital B2C se foca-lise beaucoup sur du Growth Management. Pour autant, il reste de nombreux sujets qui n’ont pas vocation à être gérés par l’équipe Produit. Le Marketing prend ainsi en charge la communication de marque, les études de marché, souvent la stratégie de pricing. Il pilote la production de contenus (articles de blog, brand content), d’autant que les équipes Produit ont souvent du mal à gérer le passage à l’échelle sur ce su-jet. Parfois, il centralise également le CRM et une part non négligeable de la connais-sance client et utilisateur. Une collaboration étroite avec les Product Managers de l’équipe Produit est alors cruciale, le Marketing ne devant pas jouer le rôle d’obstacle entre les équipes Produit et les clients.

26

Il existe un rôle de Product Marketing Manager, qui est bien distinct du Product Ma-nager. En schématisant, le Product Manager a la responsabilité de cerner les besoins utilisateurs, imaginer le Produit ou la fonctionnalité permettant de les résoudre, puis de tester et valider ces hypothèses auprès des utilisateurs - avec les Product Desi-gners - avant de lancer les développements ; tandis que le Product Marketer est en charge de faire connaître le Produit, d’en piloter le lancement et de fournir au reste de la société les armes pour le commercialiser. Ces deux rôles sont difficiles à tenir par une même personne, mais si le Product Marketer est souvent rattaché au pôle Mar-keting, il est important qu’il travaille en proche collaboration avec le Product Mana-ger : le Product Marketer est une source importante d’idées pour le développement du Produit, tandis que le Product Manager se révèle un collaborateur essentiel pour aider le Product Marketer à définir ses messages Marketing. Ce rôle est souvent essentiel dans un Produit B2B, et parfois absent des équipes en B2C.

La Technique devient une équipe de support à toutes les fonc-tions de l’entreprise

Le département Technique regroupe tous les développeurs, managers et experts techniques qui ne sont pas directement attachés à construire le Produit : contraire-ment aux développeurs évoqués plus haut, ceux-ci travaillent sur des outils et problé-matiques internes (tooling, environnements, testing) ; ils développent, configurent ou administrent des logiciels dédiés aux fonctions non Produit (finance, ventes, RH…) ; ils gèrent l’intranet ou les ERP utilisés par les collaborateurs. Enfin, ils assistent sou-vent les équipes Produit car ils regroupent des compétences pointues difficiles à disséminer dans des squads : par exemple, sur les problématiques de sécurité infor-matique, ou de DevOps et Continuous Delivery. Il n’est pas rare de former au sein du département Technique une squad indépendante dédiée au DevOps dont le rôle est de fournir les outils, plateformes et techniques permettant aux différentes squads Produit d’être autonomes sur la livraison et la mise en production.

Comment construire progressivement cette organisation Produit ?

L’organisation Produit telle que définie ci-dessus est, selon notre expérience, celle qui donne les meilleurs résultats en matière de réactivité vis-à-vis des évolutions du marché, d’utilisation des compétences et des talents, de bénéfices perçus par le


client et de minimisation de la “dette Produit”. Les entreprises purement digitales se construisent souvent autour d’un modèle similaire, cependant il arrive qu’en crois-sant elles reconstruisent des silos fonctionnels ; quant aux grandes entreprises “tra-ditionnelles”, il est rare qu’elles soient dotées d’un département Produit autonome et disposant de sa propre ligne de budget dans l’organisation. Il n’est pas évident de transformer son organisation du jour au lendemain pour atteindre ce modèle, mais il est possible d’y arriver progressivement.

Si vous partez d’une organisation très silotée, lancez une expérimentation avec une squad pluridisciplinaire se saisissant d’une problématique orientée utilisateur : choisissez bien le périmètre de cette expérimentation pour que l’équipe puisse être autonome dans la production de valeur pour les utilisateurs, et fixez des objectifs et critères de succès réalistes. Vous devriez être en mesure de prouver la valeur auprès du comité de direction et d’étendre la logique à l’ensemble du périmètre Produit.

En amont de la généralisation de cette nouvelle organisation Produit, recrutez un CPO qui managera tous les profils “Produit” (Product Manager, Product Owner, Pro-duct Designers…). Nommez également une personne - ou une équipe - comme facili-tatrice de la transformation. Cette personne devra :• sensibiliser toute l’organisation (y compris les managers) aux problématiques

d’agilité et de Product Management

• “mettre de l’huile dans les rouages” en promouvant les logiques de collaboration, pour éviter le retour à des logiques de client / fournisseur à la moindre difficulté

• assurer la PMO de la transformation : mise en place de rituels de partage, organi-sation de rétrospectives...

Pour donner du liant à l’organisation, alignez tout le monde sur des objectifs com-muns, que ce soit au niveau des départements (Produit, Marketing, Technique) ou au sein de chaque département, et mettez en place une gouvernance de ces objectifs (voir chapitre 2 “Comment piloter les objectifs d’une équipe Produit ?”).

28

Ressources - pour aller plus loin :

Product Organizational Structure : en 2008 déjà, Marty Cagan du Silicon Valley Product Group militait pour l’émergence d’organisations Produit et fournissait les premières pistes de réflexion.

Where Does Product Management Belong in the Organization? : un bel article sur l’importance de bien positionner le Product Management dans son organisation, surtout lorsqu’elle croît rapidement.


COMMENT PILOTER LES OBJECTIFS D’UNE ÉQUIPE PRODUIT ?

CHAPITRE 2

30

Je suis CPO ou Product Manager et je trouve que les objectifs de mes équipes ne sont pas clairement définis. La stratégie business n’est pas véritablement reflétée dans les métriques mesurées (il s’agit surtout de pilotage du développement) et quand différentes équipes Produit ont des objectifs, ceux-ci ne sont pas toujours cohérents d’une équipe à l’autre.Je constate aussi des problèmes de motivation dans mon équipe (turnover, frustra-tion liée à l’absence de cap ou aux changements incessants de périmètre).

Nous proposons ici une méthode permettant de mettre en place des objectifs en lien avec la stratégie de l’entreprise, transparents, cohérents entre eux, et utiles pour tout le monde : le comité de direction, les managers, les équipes opérationnelles (et en particulier l’équipe Produit).

Solution

Problème


Pourquoi fixer des objectifs ?

Chez Thiga, nous avons la chance d’intervenir au sein de nombreuses entreprises, variées aussi bien en termes de taille que de secteur d’activité ou encore de maturité digitale. Cette position nous a conduit à remarquer des dysfonctionnements récur-rents chez la plupart de nos clients, liés à un manque de visibilité au sein des équipes sur la stratégie ou les objectifs. Combien de fois avons nous entendu des phrases comme : « Je n’ai aucune idée de la stratégie de l’entreprise pour cette année », ou « Je comprends la stratégie globale, mais mes objectifs sont soit trop flous, soit com-plètement inatteignables ». Ou encore, « Je ne sais pas sur quoi je serai jugé à la fin de l’année, mon manager m’a fixé des objectifs qui ne sont pas du tout en lien avec mon Produit »

Ces remarques ne s’appliquent pas qu’aux très grands groupes, logiquement plus verticalisés et hiérarchisés que les start-ups. Même les grosses start-ups ou entre-prises de taille moyenne avec une forte maturité digitale sont parfois touchées par ce problème autour des objectifs. Quand ce n’est pas la stratégie elle-même qui est floue, c’est souvent la place de chacun dans l’implémentation de cette stratégie qui est mal connue : beaucoup de collaborateurs ne voient pas bien en quoi leurs ac-tions et leurs projets se rattachent aux objectifs de l’entreprise, passent leur temps à jongler entre de multiples priorités toutes aussi urgentes les unes que les autres ou consacrent in fine beaucoup d’énergie à des sujets peu importants.

Enfin, l’organisation des entreprises en différentes équipes peut avoir tendance à couper ces équipes les unes des autres, surtout si celles-ci sont pensées pour être autonomes et multi-fonctionnelles comme nous le recommandons : il est courant de ne pas bien sa-voir exactement sur quoi travaille l’équipe voisine, et comment les fonctionnalités qu’elle prépare ou les projets qu’elle mène peuvent impacter son propre travail.

Ces dysfonctionnements sont une préoccupation importante pour un CPO, car ils conduisent très souvent à :• un manque d’implication des équipes, qui ne se sentent pas concernées par la

construction de la stratégie de l’entreprise et la définition de leurs propres objectifs• un manque de sens donné aux actions de chacun, qui peut rendre le travail méca-

nique et répétitif

32

• des problèmes de cohérence et de coordination entre les équipes, qui se traduisent par des Produits de moindre qualité et du gâchis de ressources

• un défaut de valorisation du travail réalisé et des bonnes performances au sein de l’équipe qui pèsent sur le moral collectif

• un Produit incohérent car il est le résultat de décisions contradictoires• un Produit qui n’aide pas l’entreprise (dans son ensemble) à atteindre ses objectifs

(le Produit n’étant parfois qu’un levier parmi d’autres pour atteindre ces objectifs)

Tous ces facteurs impactent au bout du compte la rétention des salariés dans le temps. Il est donc crucial de définir des objectifs pour votre équipe Produit afin de maximiser leur engagement ; mais cela ne veut surtout pas dire écrire sur un coin de table des objectifs pour chacun et les laisser ensuite se débrouiller. Pour minimi-ser ces dysfonctionnements, il faut également mettre en place une réelle démarche autour des objectifs et les placer au cœur de l’organisation : voici comment.

Comment fixer des objectifs ?

Introduction aux OKR

La méthode OKR (Objectives and Key Results) est de plus en plus populaire au sein des entreprises. Les OKR ont été “inventés” chez Intel, et mis en place par Google en 1999. Depuis, Google a systématisé cette approche, et bien d’autres entreprises ont suivi le mouvement, dans la Silicon Valley comme dans le reste du monde.

Cette méthode est très simple et repose sur deux piliers :

• Des Objectifs ambitieux et inspirationnels

• Des Key Results (résultats clés) qui sont des indicateurs chiffrés et bornés dans le temps permettant d’apprécier l’atteinte d’un objectif donné.

Dans la méthode OKR, les Objectifs ne sont pas chiffrés et restent assez généraux. Ce sont les Key Results qui seront chargés de matérialiser les conditions de succès de l’objectif. Ceci permet :

• de préciser l’objectif “Lancer un MVP à succès” peut, par exemple, se décomposer en plusieurs dimensions et indicateurs : taux de rétention, niveau de satisfaction


utilisateur, retombées presse ou média…)

• de fixer un niveau d’ambition chiffré pour chaque dimension

En règle générale, il ne faut pas multiplier le nombre de Key Results : 2 à 5 KR par objectif constitue une bonne fourchette, qui permet de ne pas se disperser sur trop d’indicateurs à la fois. A l’inverse, choisir trop peu de Key Results peut pousser à traiter partiellement certains objectifs, en laissant de côté des dimensions impor-tantes (optimiser un taux de transformation sans prendre en compte la rétention par exemple).

Les OKR stratégiques

Les OKR existent à plusieurs niveaux : un niveau stratégique, et un niveau plus opé-rationnel déterminé par chaque équipe. En effet, la préoccupation majeure de toute équipe Produit et tout CPO consiste à créer un Produit permettant à l’entreprise de rencontrer le succès. Mais la notion même de “succès” peut prendre plusieurs formes ; certaines entreprises par exemple se focaliseront sur un succès financier (chiffre d’affaires, ou profitabilité) de court terme, quand d’autres privilégieront une certaine stabilité, ou encore se préoccuperont également de l’impact social ou éco-logique du Produit. La définition de succès peut varier également en fonction du niveau de maturité du Produit ou de l’entreprise : au début, l’équipe Produit sera for-tement focalisée sur la croissance en matière d’usage (utilisateurs actifs, rétention - voir le Product Academy 2 pour plus de détails), et peut-être moins sur les questions de rentabilité à court terme.

La définition de ce “succès” au niveau de l’entreprise est de la responsabilité du co-mité de direction - ou des fondateurs, dans le cadre d’une start-up. En repartant du “mission statement” (la raison d’être) de l’entreprise, ils doivent définir ce qui sera considéré comme un succès sur l’année à venir, c’est-à-dire les OKR stratégiques de l’organisation. Pour cela, une fois par an en général, le CEO convoque le comité de direction à une réunion pour fixer les objectifs communs de l’entreprise. Selon nous, cette réunion doit être préparée en amont par chaque membre du comité de direc-tion séparément, en collaboration avec leur équipe, pour identifier les ambitions et critères de succès de chaque entité de l’organisation. Au cours de cette réunion, en priorisant ces divers objectifs remontés par les équipes, le management doit arriver à établir une stratégie claire sur l’année autour

34

de quelques objectifs majeurs ; ceux qui n’auront pas été retenus sont transformés en intentions moins prioritaires, qui pourront être repriorisées au besoin au cours de l’année, ou à défaut formeront les premiers objectifs de l’année suivante. Enfin, il faut fixer des Key Results associés à chacun de ces objectifs, en choisissant uniquement des indicateurs que vous savez mesurer et interpréter (voir plus bas la meilleure façon de définir ces KR).

L’équipe produit déclinera ces objectifs stratégiques en objectifs Produit :

OÙ L’ORGANISATION VEUT-ELLE ALLER ?

Des objectifs ambitieux vers lesquels orienter les efforts à l’échelle du comité de direction

MISSION ORGANISATION

objectifs stratégique 1

Key Result Key Result Key Result



Période : année

OÙ LE PRODUIT VEUT-IL ALLER ?

Des objectifs ambitieux vers lesquels orienter les efforts à l’échelle Produit

OBJECTIF STRATÉGIQUE 1

Objectifs Produit 1

Objectifs Produit 2

Objectifs Produit 3

Période : année


COMMENT M6 WEB FIXE SES OBJECTIFS ?

Le pôle Digital Consumer de M6 Web utilise la méthode OKR pour pilo-ter les objectifs des équipes.

Les objectifs stratégiques sont partagés dans le “contrat de perfor-mance”, un document synthétique permettant de formaliser et commu-niquer sur un horizon annuel la mission du département.

Ces objectifs peuvent :être liés directement au business : “être capable de générer de la crois-sance pérenne”concerner d’autres problématiques : “savoir innover”, “mettre en place un management qui fait réussir”

Les objectifs opérationnels sont fixés par les équipes elles-mêmes en lien avec le responsable du portefeuille de Produits numériques.• Un point annuel permet aux équipes de mettre à jour la stratégie de

chaque Produit, et les enjeux majeurs de l’année en lien avec le contrat de performance.

• Au cours de l’année, les objectifs trimestriels sont fixés collaborative-ment par les Product Managers et leurs équipes respectives, au cours d’un atelier dédié. Chacun de ces ateliers se clôture par un vote ayant pour but d’isoler les 2-3 objectifs sur lesquels l’équipe se concentrera au cours des 3 prochains mois.

Comment mesurer l’atteinte des objectifs ?

Les KR sont définis par chaque équipe Produit, trimestriellement, en même temps que leurs objectifs ; ils sont discutés avec le management de la même façon. Nous vous suggérons de commencer par lister tous les KR qui vous semblent pertinents, mais sans les chiffrer, et de les prioriser les uns par rapport aux autres ; puis dans un second temps, de sélectionner les plus prioritaires et de définir pour chacun le niveau d’ambition chiffré associé.

36

Il est, par exemple, possible de formuler les KR de la manière suivante : “réaliser X nouvelles inscriptions pendant la période”, “atteindre Y utilisateurs actifs par jour” en attendant que le chiffrage soit effectué.



ÊTRE RECONNU COMME UN ACTEUR

MAJEUR DU MARCHÉ

Lancer un MVP à succès

Objectifs Produit 2

Objectifs Produit 3

Période : année

X % des utilisateurs font N visites par semaine

Avoir un NPS de Y Avoir un taux de transformation à l’achat de Z%

Une fois que le management a validé les objectifs et les KR proposés par l’équipe, ces derniers doivent être chiffrés, mais également associés à un indice de confiance. Cet exercice est délicat et doit donc également faire l’objet d’une discussion collective. Trouver le bon niveau d’ambition pour un KR dépend de plusieurs facteurs : les moyens disponibles au sein de l’équipe pour atteindre l’objectif, l’historique de per-formance passée sur ce même indicateur, l’évolution du marché et de la compétition, etc. Il n’y a pas de recette magique, gardez simplement en tête que les OKR sont un outil inspirationnel et itératif : il vaut mieux fixer un KR et se mettre au travail, quitte à se rendre compte plus tard que l’on a été trop ou pas assez ambitieux, plutôt que de passer des semaines à débattre du bon chiffre.

A ce titre, l’indice de confiance qui doit être associé à chaque KR est un outil de pilotage important. Un KR doit être considéré comme très ambitieux, donc difficile à atteindre, sans être impossible pour autant. L’indice de confiance traduit ce côté inspirationnel de l’OKR : un bon KR doit avoir un indice de confiance d’environ 50% (une chance sur deux d’atteindre l’objectif), ce qui implique de tirer les équipes vers le haut, tout en assumant le risque que l’objectif ne soit pas atteint.


EXEMPLE D’OKR POUR UN SITE D’E-COMMERCE

Une entreprise d’e-commerce spécialisée dans la personnalisation de vêtements dispose d’un département Produit découpé en 3 équipes, selon les étapes du parcours utilisateur : • L’équipe “Go To Market” qui gère le haut de l’entonnoir : page d’accueil,

page descriptif article, page promotion• L’équipe “Personnalisation” qui gère la création des articles : studio de

création qui permet de personnaliser des t-shirts, des chaussures, etc.• L’équipe “Checkout” qui gère les pages panier, les options d’up-sell et

de livraison.

Les objectifs stratégiques sont définis par le CEO, déclinés dans chacun des départements, puis dans chacune des équipes.

Exemple1/ CEO - Objectif stratégique : proposer la meilleure expérience utilisa-teur du marchéKR : évolution du NPS de +2 points

2/ Equipe “Go To Market”- Objectif : Simplifier l’expérience utilisateur et les rediriger au plus vite vers l’offre qui leur correspond- KR 1 : Faire augmenter le taux d’utilisateurs entamant une création de vêtement personnalisé de 2 à 3%- KR 2 : Diminuer le nombre de clics nécessaires avant d’arriver à une création d’article de 5 à 3- KR 3 : Améliorer l’efficacité des landing pages offres de 30 à 50%

3/ Equipe “Personnalisation”- Objectif : Donner envie à l’utilisateur d’acheter le vêtement créé- KR 1 : Faire croître le taux de conversion du studio de création vers le checkout de 15 à 20%

4/ Equipe “Checkout”- Objectif : Augmenter les dépenses par utilisateur- KR1 : Augmenter le panier moyen de 15 à 18 €- KR2 : Faire croître taux d’upsell de 5 à 10%

38

A la fin de la période fixée (en général, un trimestre), chaque équipe se réunit pour faire le bilan de la période et estimer le pourcentage d’atteinte des différents Key Results, selon les indicateurs fixés en amont. Par exemple, si l’équipe s’était donné comme résultat clé une augmentation du NPS de 5 points et qu’il n’a augmenté que de 2 points à la fin de la période, on considère le KR atteint à 40%.

On peut calculer un taux d’atteinte de l’objectif en fonction de la moyenne de ses KR, en pondérant au besoin les différents KR en fonction de leur importance.

La plupart des logiques d’objectifs dans les entreprises considèrent la non atteinte des objectifs comme un échec. Ce n’est pas le cas dans la méthode OKR ; l’intérêt des OKR n’est pas simplement d’atteindre les objectifs, mais aussi d’apporter de la transparence, d’aligner les équipes, de pousser les organisations et les individus à se dépasser, et d’apprendre ce qu’elles sont réellement capables de produire en un temps donné.L’idéal serait bien sûr d’atteindre chaque trimestre 100% des KR et donc de réaliser chacun des objectifs : si c’est le cas, n’oubliez pas de célébrer cette réussite comme il se doit. Cela dit, rater quelques KR ne doit pas être perçu comme un échec reten-tissant mais surtout comme une occasion importante d’analyser ce qu’il s’est passé pour comprendre le problème : l’OKR était-il trop ambitieux ? L’indice de confiance était-il mal estimé ? L’équipe a-t-elle manqué de moyens ? Des écueils ont-ils été rencontrés sur la période ?

Dans cette optique, il est également préférable de décorréler l’atteinte des OKR d’un système de rémunération par primes ; si vraiment vous voulez lier OKR et rémunéra-tion, faites en sorte qu’une prime puisse être accordée à un collaborateur même si celui-ci n’a pas atteint 100% de ses OKR, pour autant que ceux-ci aient été ambitieux et que le travail effectué pour les atteindre ait été de qualité.

Quelle gouvernance mettre en place autour des objectifs ?

Fixer des Objectifs et KR apporte en soi de la valeur à toute entreprise et toute équipe Produit, mais la méthode ne produit des résultats à long terme que si une gouver-


nance et des pratiques sont mises en place pour la faire vivre. En effet, il est fréquent de voir des entreprises fixer des objectifs, puis les laisser de côté dès le mois d’après et ne s’en préoccuper de nouveau que bien plus tard, lors des entretiens annuels.

Utiliser les initiatives

Avec les Objectifs et les KR, les initiatives sont le troisième et dernier pilier de la méthode OKR : une initiative est une action planifiée ayant pour but de faire évoluer positivement un ou plusieurs KR. Il s’agit tout simplement de la liste de tâches de votre équipe ou de vos collaborateurs.Tout comme les Objectifs et KR, les initiatives doivent être transparentes et suivies dans le temps (sous forme d’un kanban ou autre board visuel, par exemple).



ÊTRE RECONNU COMME UN ACTEUR

MAJEUR DU MARCHÉ

Lancer un MVP à succès

Objectifs Produit 2

Objectifs Produit 3

Période : année

40 % des utilisateurs font 2 visites par semaine

Avoir un NPS de 60

Avoir un taux de transformation à l’achat de 15 %

Lancer 4 campagnes d’acquisition ciblées sur les early adopters en février

Lancer une première version du service en avril

Avoir A/B testé le parcours d’onboarding d’ici juin

Clôturer et planifier les OKR

Nous avons déjà mentionné l’importance de construire les OKR stratégiques à chaque début d’année, et de fixer les OKR par équipe à chaque début de trimestre (le rythme privilégié par la plupart des CPO rencontrés dans le cadre de la rédaction de ce livre). Ces rituels de planification, collaboratifs et itératifs, doivent être sanctuari-sés et du temps doit être consacré à leur préparation.

40

En préalable de la planification, il nous paraît également essentiel d’organiser une ré-union de bilan du trimestre (ou de l’année pour les OKR stratégiques) durant laquelle les équipes procèdent à une revue des différents OKR et à un diagnostic de leur performance. C’est le moment de tirer les enseignements pour la prochaine période : si un objectif n’a pas été atteint, faut-il le prolonger sur la période suivante en fixant un nouveau KR, ou l’abandonner provisoirement voire définitivement ? Si tous les objectifs ont été atteints ou dépassés, faut-il recalibrer le niveau d’ambition pour le prochain trimestre ? La date de cette réunion de bilan doit être fixée à l’avance dans les calendriers, de façon à ce que chacun puisse l’anticiper.

Créer des moments de partage

Les deux rituels évoqués ci-dessus sont nécessaires, mais insuffisants : sur un tri-mestre, il existe un risque réel de laisser glisser les OKR à l’arrière-plan et de les oublier jusqu’à la rétrospective.

Pour faire en sorte que les objectifs soient réellement un facteur d’organisation du travail au quotidien, et donner une cadence à l’équipe, nous préconisons de cadencer le travail de l’équipe Produit (mais aussi possiblement toute autre équipe de l’en-treprise) sur un rythme de type Scrum. Ce cadencement et les rituels qui l’accom-pagnent permettront une boucle de feedback rapide, avec à chaque sprint un travail sur les initiatives permettant in fine d’atteindre les OKR trimestriels.

Il est important de ménager des moments pour la célébration, afin de ne pas se contenter de saluer l’atteinte d’un OKR tous les 3 mois mais aussi de valoriser toute initiative permettant de faire progresser significativement un KR. Cela permet de gar-der le rythme mais aussi de diffuser la culture de la transparence dans l’entreprise.Les équipes agiles organisent une démo à intervalles réguliers, mais ce concept peut être étendu à d’autres équipes dans l’entreprise et d’autres activités. Les Product Designers pourraient présenter la synthèse de leur recherche utilisateur ou un pro-totype récent, le Product Manager évoquer son travail en cours sur de futures fonc-tionnalités ; les forces de vente pourraient, elles, annoncer la signature d’un contrat.


Le Sprint planning inspiré de Scrum permet de déterminer le plan d’action pour les 15 prochains jours (par exemple) :• Quelles sont les 3-4 initiatives que l’équipe compte accomplir au cours du sprint

pour faire progresser un ou plusieurs KR ?• Quels sont les projets qui arriveront au cours du mois et qu’il faut anticiper ?

La rétrospective de fin de sprint permet de partager les indicateurs de santé et de gérer les points d’amélioration continue ; c’est également l’occasion de faire évoluer l’indice de confiance de chaque OKR.

Tout le monde ne pourra pas participer à tous ces événements ; organisez-les par équipe (si possible multi-disciplinaire), mais n’oubliez pas également de communi-quer sur les résultats à travers l’organisation (management visuel, newsletter, points de synchro rapide, channel Slack dédié…). Vous pouvez vous inspirer de ce format de newsletter très simple pour partager la progression sur les OKR :• Liste des objectifs et KR et rappel du niveau de confiance pour chacun (en mettant

en avant ceux qui ont été revus à la hausse ou à la baisse)• Rappel des initiatives effectuées la semaine ou les 15 jours précédents• Proposition d’initiatives pour la période suivante

Q1 Q2 Q3 Q4Janvier Mars Juin

Sprint planning

PlanificationOKR Q2

Sprint

Bilan des OKR Q1

Définition des initiatives au cours du sprint qui feront progresser les OKR

Présenter les résultats du sprint

Mettre à jour les indicateurs de confiance

Démo & Rétro

Septembre

Les OKRs doivent évoluer dans le temps et s’ajuster périodiquement :

Animation et suivi des OKRs

42

Synthèse des principaux rituels autour des OKR

Les erreurs à ne pas commettre lorsqu’on implémente la méthode OKR

La méthode OKR paraît très simple, mais sa mise en pratique est assez exigeante. Si vous souhaitez la piloter efficacement dans votre équipe Produit, gardez bien en tête les écueils suivants :

• Ne définissez pas les OKR de manière “top down” : les rituels liés aux OKR sont l’occasion d’organiser une discussion avec vos équipes et de laisser chacun ex-primer ses ambitions. Laissez votre équipe définir ses propres objectifs, toujours en lien avec les objectifs stratégiques de l’organisation, et négociez avec elles si nécessaire.

• N’oubliez pas de communiquer largement sur les objectifs : chaque équipe doit avoir à tout instant une idée assez claire des objectifs de l’entreprise mais aussi de chaque équipe qui la compose. Mettez en place un outil simple pour que chacun puisse visualiser et suivre ses propres OKR et ceux des autres équipes.

• Ne multipliez pas les objectifs, surtout au début ; la tentation est grande de fixer des dizaines d’objectifs, mais résistez-y. D’une part, trop d’objectifs rendront le suivi des OKR plus complexe ; ensuite, si tout est considéré comme important, rien n’est important au final. Faites des choix, et discutez-les avec votre équipe. Pour une pre-mière implémentation des OKR, nous conseillons de vous focaliser sur un ou deux objectifs, puis de monter en puissance au fil des trimestres.

• Variez les types de KR : ne vous focalisez pas sur un ou deux KPI clés mais réflé-chissez bien à toutes les facettes du succès.

• Adoptez un niveau d’ambition conforme à la maturité et au goût du risque caracté-risant votre équipe, afin d’éviter de la démoraliser : les OKR sont conçus pour être aspirationnels, mais pas pour autant impossibles.

• Evitez autant que possible de définir des objectifs ou Key Results comme des “out-puts” : “continuer le projet”, “livrer la nouvelle version”. Les OKR sont plus efficaces lorsqu’ils manipulent des “outcomes”, qui mesurent la performance effective des équipes.


Ressources - pour aller plus loin

• Radical Focus : Achieving Your Most Important Goals with Objectives and Key Results : Dans cet ouvrage de référence publié en 2016, Christina Wodke explique en détail toutes les étapes pour fixer ses OKR ainsi que les enjeux rencontrés auprès des clients qu’elle accompagne aux Etats-Unis.

• re:Work-Set Goals With OKR : Cette documentation en ligne éditée par Google référence toutes leurs bonnes pratiques, que vous pourrez creuser par catégorie. Nous vous encourageons à aussi regarder cette présentation complète de Google Ventures : How Google sets OKR.

• OKR Examples : Ce site donne de nombreux d’exemples d’OKR, classés par type d’activité. Très inté-ressant pour donner des exemples concrets à vos collaborateurs de ce à quoi pourraient ressembler leurs objectifs.

• Outils pour mettre en place et suivre les OKR : Perdoo, Weekdone, 7Geese, Javelo...


COMMENT DÉCOUPER LES ÉQUIPES ?

CHAPITRE 3

46

Mon organisation Produit a bien grandi, et j’ai dû constituer plusieurs équipes pour prendre en compte de nouveaux sujets. J’ai l’impression que le découpage des péri-mètres entre ces équipes n’est pas optimal, il y a des goulots d’étranglement, beau-coup d’énergie est gaspillée dans des réunions de synchronisation, la réactivité des équipes est en baisse...

Optimiser voire refondre complètement le découpage des équipes peut permettre d’améliorer sensiblement la situation.Différents modes de découpage sont possibles, chacun offrant ses propres avan-tages et inconvénients ; le découpage vertical en équipes pluridisciplinaires orien-tées vers des problématiques client nous semble plus pertinent dans la plupart des cas, mais en fonction de votre contexte il faudra adapter son implémentation.

Solution

Problème


Le découpage des équipes Produit : un dilemme nécessaire

Toute organisation confrontée à des problématiques de croissance va inévitable-ment se scinder au fil du temps en différentes équipes, chacune ayant son propre domaine de responsabilité. C’est également le cas pour les organisations Produit, ce qui pose évidemment la question du découpage de ces équipes (que nous appelle-rons squads). Nous ne traiterons pas ici de la dimension hiérarchique, qui définit les lignes de res-ponsabilités et les relations entre tel manager et tel individu ou équipe ; nous nous focaliserons ici sur une préoccupation majeure des CPO : la répartition des compé-tences dans les équipes et le périmètre fonctionnel qui leur est associé.

L’un des critères principaux de tout découpage est bien sûr la taille maximale de chaque squad. Un consensus semble se former autour d’un nombre idéal de 8 personnes : la fameuse “pizza team”, pouvant confortablement partager en toute convivialité deux pizzas margherita. Il est bien sûr acceptable de déroger à ce chiffre magique et de constituer des équipes allant de 5 à 12 personnes ; gardez cependant en tête qu’au fur et à mesure que les squads croissent, le nombre de liens à mainte-nir entre les individus explose (de 10 pour une équipe de 5 à 66 pour une équipe de 12 !). La communication devient inévitablement plus difficile, les rituels s’éternisent, la productivité individuelle et collective diminue. En plus d’être proportionnellement plus lentes que des équipes plus petites, les squads trop larges ont également ten-dance à sous-estimer la difficulté des tâches, en se révélant souvent démesurément optimistes dans leurs estimations. Il est plus difficile d’avoir un niveau de discussion de bonne qualité et d’aligner tout le monde au sein d’une équipe de taille importante.

Construire des petites squads, c’est une nécessité pour faciliter la communication ; mais il faut également limiter les dépendances et adhérences entre ces squads, au risque de reproduire au niveau collectif les problèmes de communication exposés plus haut. Les squads doivent être les plus autonomes possible et leur périmètre cohérent afin d’éviter le travail en double, les réunions d’alignement interminables et les guerres de périmètre.

48

Le découpage n’est qu’un élément parmi d’autres de l’organisation. Quelle que soit l’approche retenue, il faudra également pour qu’elle fonctionne assurer une cohé-rence méthodologique (Lean Startup, Design Thinking), mettre en place des proces-sus (conception, recherche utilisateur, Growth...), et une gouvernance appropriée (voir chapitre 2 “Comment piloter les objectifs d’une équipe Produit ?”).Néanmoins, même si votre organisation est exemplaire sur tous ces autres do-maines, un mauvais découpage peut poser à lui seul de graves problèmes.

Les 4 caractéristiques d’un mauvais découpage ainsi que leurs conséquences pos-sibles sont listées ci-dessous. Si vous reconnaissez les travers de votre organisation dans au moins l’un de ces constats, c’est qu’il est sans doute temps de changer votre découpage d’équipe.

Mauvais découpage Conséquences observables Impact final

Taille des squads non adaptée

☐ Paresse sociale si la squad est trop grande

☐ Sous-utilisation des profils Produit si la squad est trop petite

☐ Goulot d’étranglement si la squad est trop petite

☐ Faible prédictibilité ☐ Faible vélocité

Squads orientées “output” plutôt que “outcome” (i.e. visant des livrables et non des résultats)

☐ Écarts d’expérience sur les parcours utilisateur

☐ Manque de sens donné au travail des squads

☐ Absence de culture de la mesure

☐ Décisions prises de manière intuitive plus que rationnelle

☐ Faible NPS / satisfac-tion client

☐ Turnover des équipes ☐ Inadéquation entre le

Produit et les attentes du marché

Faible autonomie des squads

☐ Gestion des dépen-dances énergivore : temps passé en réunion, en atelier

☐ Dilution des responsabilités

☐ Phénomène de cascade entre les différentes équipes

☐ Faible vélocité ☐ Turnover des équipes


La bonne nouvelle, c’est que la plupart de ces travers peuvent être évités, en choisis-sant le bon modèle de découpage. La mauvaise nouvelle, c’est qu’il n’y a pas de dé-coupage idéal et unique (tout comme il n’y a pas d’organisation idéale) : tout dépend de votre Produit, de votre contexte et des caractéristiques de votre organisation.

Les 4 modèles de découpage

On distingue schématiquement 4 modèles de découpage des équipes.

Le découpage horizontal

Ce modèle de découpage est souvent appelé découpage en Component Teams (équipes composants). Les squads sont structurées selon une logique technolo-gique, en séparant souvent squads “front” et squads “back”, en créant des squads par canal ( web, mobile, IoT...) ou en construisant des squads dédiées à une couche applicative donnée (par exemple : socle de paiement, service d’emailing...).

La version minimaliste rencontrée le plus fréquemment sur des Produits simples est un découpage en 4 squads : une front-end, une back-end, une équipe iOS et une équipe Android.

Le découpage vertical

Dans ce modèle, les squads sont organisées selon une logique business et orientée utili-sateur : souvent par fonctionnalité (Feature Teams - popularisées notamment par Spotify), mais aussi parfois par étape de parcours utilisateur, persona ou objectif (Impact Teams).

Flou autour du périmètre des équipes

☐ Écarts d’expérience sur les parcours utilisateur Travail redondant dans plusieurs équipes

☐ Problèmes de communication entre les équipes, conflits personnels

☐ Dette Produit☐ Time to market plus

long

50

Quel que soit le mode de découpage retenu, chaque squad est :• pluridisciplinaire : elle regroupe toutes les compétences nécessaires au dévelop-

pement d’un Produit complet, pour accomplir sa mission en autonomie.• multi-composant : elle est capable de travailler sur toutes les couches techniques

du Produit (notamment front et back) et son périmètre englobe une tranche verti-cale du Produit, indépendamment de l’architecture technique.

• stable et durable : une durée minimale d’un an semble faire consensus, pour que l’équipe ait le temps de trouver son rythme de croisière. Si les sujets travaillés par l’équipe deviennent non prioritaires pour l’organisation, il vaut toujours mieux bas-culer la squad sur un nouveau périmètre plutôt que la démanteler entièrement.

• en apprentissage permanent : chaque membre de la squad doit aller au-delà de sa spécialité d’origine afin que les tâches puissent être réalisables par plusieurs per-sonnes, et que chacun ait le sentiment de progresser à titre individuel.

Le découpage vertical permet d’inscrire dans la structure même de l’organisation Produit sa mission : apporter de la valeur aux utilisateurs. Le tout en favorisant l’au-tonomie et la créativité de chaque squad.

Par nature, ce type de découpage pose la question de la gestion des problématiques transverses et de la cohérence entre le travail fourni par chaque squad. Comment s’assurer que l’expérience utilisateur finale est cohérente ? Comment gérer le fait que chaque équipe peut modifier n’importe quelle partie du code du Produit, et im-pacter le travail de toutes les autres (surtout dans le cas d’Impact Teams) ?

Pour pallier ce problème, les entreprises pratiquant le découpage vertical créent sou-vent un échelon intermédiaire : Spotify, qui a beaucoup communiqué sur le sujet, propose un système de tribus regroupant plusieurs squads. Cet échelon apporte de la cohérence, assure la synchronisation des différentes squads et porte des initia-tives transverses.

Des chapters (communautés de pratique) sont également implémentés : ces com-munautés sont transverses aux squads, et organisées par compétence. Ainsi, les Product Owners de chaque squad se réunissent ponctuellement pour partager leurs bonnes pratiques et échanger sur leur backlog ; de même, les Product Designers peuvent partager la recherche utilisateur effectuée au sein de chaque squad ou se mettre d’accord sur des principes d’interface ou parcours.


Enfin, des guilds reproduisent le modèle des chapters mais à l’échelle de l’organisa-tion Produit toute entière, et sont dédiées à des problématiques transverses mobi-lisant des compétences plus diverses et constituant des axes de travail importants pour l’entreprise (par exemple : sécurité, machine learning, atomic design).

Le découpage hybride

Il n’est pas rare que les équipes Produit mélangent découpage vertical et horizontal. Par exemple, dans une organisation en Feature Teams avec une application mobile, l’idéal voudrait que chaque squad dispose de ses propres développeurs iOS et An-droid pour respecter le principe de l’autonomie des équipes et pouvoir livrer de la valeur quel que soit le canal envisagé ; en pratique, une telle solution est coûteuse et parfois contre-productive, les développeurs mobiles étant souvent plus efficaces regroupés ensemble plutôt que disséminés dans des squads différentes.

Certaines entreprises choisissent ainsi de concilier découpage vertical (pour une partie des équipes) et Component Teams pour certains canaux ayant des contraintes spécifiques (mobile, IPTV pour un acteur média…) ou bien des applicatifs socles très importants (back-end de gestion des virements pour une banque).

Tribu 1 Tribu 2

Responsables tribu Responsables tribu

Squad 1 Squad 1

Product Owner

Product Owner

Devs Devs

Product Designers

Product Designers

... ...... ...

Product Designers

Product Designers

Devs Devs

Product Owner

Product Owner

Squad 2 Squad 2

Chapter

Guild

Organisation découpée verticalement

52

Le découpage vertical flexible (par exemple : SAFe)

La quasi-totalité des frameworks agiles, notamment SAFe, LeSS ou Scrum@Scale, préconisent de constituer des équipes pluridisciplinaires à l’instar du modèle vertical (composées donc de développeurs, Product Designers, Product Owners / Product Manager, testeurs…), mais sans forcément les restreindre par nature à un périmètre.

Le framework SAFe propose d’implémenter 3 échelons et 3 niveaux de granularité:• Le portfolio, qui regroupe des Epic Owners et Portfolio Managers, manipulant un

backlog d’epic associées à de grandes priorités stratégiques et business• Le programme, qui regroupe des Business Owners et Product Managers manipu-

lant un backlog de fonctionnalités, planifiées à l’échelle de Product Increments (en général, 5 sprints de 2 semaines)

• Les squads, qui se saisissent des fonctionnalités, les transforment en user stories et les intègrent dans des sprints.

Si les squads peuvent progressivement se spécialiser sur certains sujets ou théma-tiques au fur et à mesure des Program Increments (PI), elles sont par nature non spécialisées et peuvent absorber n’importe quelle fonctionnalité. Tous les 5 sprints, une session de PI Planning permet de planifier les 5 prochains sprints en distribuant les sujets prioritaires aux différentes squads, mais aussi d’anticiper les potentielles adhérences. Il peut arriver toutefois que les squads soient rattachées à un Value Stream, soit un domaine complet de l’entreprise (business unit, Produit…).Voici un exemple de découpage d’équipes possible pour un service de covoiturage (tel que BlaBlaCar ou iDVROOM) :


Découpage horizontal (Component Team)

• Squad Back-end• Squad Front-end (web)• Squad Mobile• Squad Web (front)• Squad Paiement• Squad Sécurité• ...

Découpage vertical (Feature Team)

• Squad recherche conducteur• Squad réservation• Squad transaction • Squad ratings• ...

Découpage vertical (Impact Team)

• Squad Grow : chargée de maximiser le vo-lume d’affaires transitant par la plateforme.

• Squad Monetize : chargée de convertir un maximum d’utilisateurs “freemium” (accès limité mais gratuit à des contenus) en utilisa-teurs “premium” (accès payant) pour maxi-miser le chiffre d’affaires.

• Squad Trust : chargée de maximiser la com-plétion des profils de conducteurs et le taux de complétion des évaluations d’après trajet.

• Squad Care : chargée de diminuer le ratio des utilisateurs qui contactent le call center par rapport au nombre total d’utilisateurs.

• Squad Engage : chargée de maximiser le nombre de fois par an qu’un utilisateur uti-lise la plateforme.

• Squad Satisfy : chargée de maximiser le NPS.

Découpage vertical (Persona Team)

• Conducteur• Passager

54

Quel sera le meilleur modele pour votre organisation Produit ?

Tel que précisé plus haut, il n’y a pas de découpage idéal ; pour autant, chaque type de découpage a ses points forts et ses points faibles, qui peuvent être plus ou moins intéressants en fonction du contexte.Nous avons fait l’exercice d’évaluer ces différents modèles selon les critères qui nous semblent important pour une organisation Produit en nous appuyant sur les expériences pratiques des Thiguys et des CPOs interviewés.

Horizontal Vertical pérenne Vertical flexible

Responsabilisa-tion des squads (sens donné au

travail)

- ++ +

Orientation utilisateur - ++ +

Spécialisation des compétences ++ - --

Autonomie des équipes et gestion des dépendances

-- ++ +

Mutualisation et réutilisation

du code++ + +

Facilité à passer l’organisation

à l’échelle+ - +

Amélioration continue du

Produit- ++ +

Coût des squads * - + +

* + = plus coûteux, - = moins coûteux


Responsabilisation des squads

C’est une évidence, mais toute équipe et tout individu est plus efficace quand son travail a un but, du sens, un impact concret sur le Produit final. Dans une logique de Component Team, les équipes gèrent souvent une petite partie du Produit, guidée par un découpage technique. Les équipes front-end définissent des interfaces, mais doivent généralement composer avec des API créées par d’autres équipes (back-end). Certaines équipes travaillent pour le compte d’autres équipes, selon des be-soins dont ils ne perçoivent pas toujours toute l’importance et des priorités qu’ils ne maîtrisent pas. Enfin, comme les responsabilités sont diluées (la qualité d’une fonc-tionnalité développée dépend de la qualité du travail d’au moins 3 ou 4 équipes diffé-rentes), les équipes organisées dans ce modèle peuvent avoir tendance à rejeter la responsabilité sur d’autres. Les équipes back se plaindront que les fonctionnalités front ont été mal pensées et mal codées, les développeurs front se plaindront d’avoir dû composer avec un modèle de données mal conçu, et ainsi de suite. Pour éviter ces problèmes, il faut promouvoir en interne la co-construction entre équipes et lut-ter contre les relations client-fournisseur qui ont tendance à resurgir à intervalles réguliers lorsqu’on travaille en Component Teams.

Les modèles verticaux (Feature Teams, Impact Teams...) sont plutôt responsabili-sants pour les squads, qui doivent définir leurs propres objectifs, leur vision, leur backlog, toujours dans une logique d’apporter de la valeur à l’utilisateur. La plupart des décisions importantes sont prises au sein des équipes “qui font”, même si elles agissent toujours dans un cadre stratégique donné.

Le modèle SAFe représente selon nous une approche intermédiaire en matière de responsabilisation : les squads sont normalement autonomes et responsabilisées au niveau du Program Increment, mais en fonction de l’implémentation du modèle et du nombre de couches hiérarchiques au-dessus des squads, il peut arriver qu’elles se retrouvent coupées à la fois des utilisateurs et de la stratégie Produit.

56

Orientation utilisateur

Par nature, les équipes verticales (qu’on parle de fonctionnalités ou d’objectifs) sont orientées vers l’utilisateur, puisque leur mode de découpage est pensé en fonction de problématiques utilisateur. Le modèle d’équipes organisées par objectif présente cet avantage par rapport à la Feature Team de ne pas pérenniser telle ou telle fonc-tionnalité : une fois une Feature Team créée, la squad peut avoir tendance à conti-nuer à développer coûte que coûte la fonctionnalité en question même si elle cesse à terme de répondre aux objectifs du Produit, pour justifier sa propre existence.Les équipes verticales intègrent également toutes les compétences nécessaires pour mener des activités de recherche utilisateur sur leur périmètre (voir chapitre 6 “Comment industrialiser le Product Discovery”).

A l’inverse, les Component Teams sont peu orientées utilisateur par nature, car elles reflètent davantage une organisation technique. Par ailleurs, la recherche utilisateur n’est pas portée par chacune des équipe, mais souvent effectuée à un autre niveau de l’organisation au sein d’équipes dédiées (les équipes back-end par exemple étant complètement coupées du contact avec les utilisateurs).

Spécialisation des compétences

Ici, les différents modèles sont en opposition frontale. Les Component Teams sont un environnement favorisant les spécialistes, qui souhaitent approfondir une exper-tise particulière ; elles sont donc particulièrement appropriées à des contextes tech-niques complexes ou faisant appel à des compétences très spécifiques (technolo-gie ou langage de programmation particulier), qu’il vaut mieux regrouper au sein de la même équipe. Par exemple, une équipe dédiée à la Data Science.

A l’inverse, les Feature Teams et les modèles d’agile à l’échelle verticaux tels que SAFe privilégient les profils “en T”, excellant dans une compétence mais ayant une capacité à étendre ponctuellement leur champ d’action à d’autres domaines. Le modèle du déve-loppeur “full stack” capable d’assurer du développement front, back, voire du DevOps se révèle tout à fait adapté à ce genre de squad ; on a vu que la taille d’équipe cible est assez réduite, la squad verticale ne peut donc pas accumuler les profils de spécialiste. Par ail-leurs, ce type de squad a comme vertu non négligeable de réduire considérablement les risques de grippage liés à l’absence d’un ou plusieurs coéquipiers.


Autonomie des équipes et gestion des dépendances

Les Component Teams sont rarement autonomes sur leur domaine. Elles four-nissent en général des briques qui servent à d’autres équipes (pour compléter tout ou partie d’un Produit ou parcours utilisateur), et s’appuient sur des éléments déve-loppés ailleurs dans l’organisation. On retrouve une logique de client-fournisseur où chaque squad peut devenir un goulot d’étranglement pour l’ensemble du processus : par exemple, si les développeurs back-end ont fini de créer toutes les API mais que l’équipe front-end a du retard, toute la fonctionnalité s’en trouve bloquée. Elles sont également tributaires de projets et d’initiatives imposés par d’autres entités dans l’organisation, sans réel contrôle sur leur backlog. La synchronisation des différents backlogs et les chaînes de décision associées rendent chronophage et souvent fastidieuse la gestion des dépendances en Component Teams. La qualité des arbi-trages effectués dans ce modèle est rarement optimale, générant des frustrations.

A l’inverse, la Feature Team et les modèles verticaux en général plaident pour une autonomie complète des squads. Cette orientation permet de :• dégager fréquemment de la valeur pour l’utilisateur• valoriser la créativité et l’expertise de chaque équipe• rapprocher la prise de décision des équipes opérationnelles.

Chaque équipe peut théoriquement avancer à son rythme, sans attendre des déve-loppements effectués par d’autres. Bien sûr, cette autonomie a des limites, et cer-taines adhérences sont inévitables. Les équipes verticales doivent s’aligner entre elles de manière fréquente, pour éviter de développer des fonctionnalités redon-dantes, ou de prendre des options contradictoires. C’est d’autant plus le cas pour les squads organisées par objectifs, qui peuvent toutes impacter la même fonctionna-lité du Produit.Cette synchronisation entre squads, et la gestion additionnelle des projets trans-verses impactant toutes les équipes, est consommatrice en temps et en énergie. Pour autant, nous avons vu plus haut qu’il est possible de simplifier ce processus grâce aux tribus, chapters et guilds. SAFe fait également une place très importante aux activités de planification, qui permettent d’anticiper les dépendances et d’aligner les squads.

58

Mutualisation et réutilisation du code

Les défenseurs du modèle Component Teams arguent que la réutilisation du code constitue l’un de ses avantages. Par nature, chaque équipe component a un péri-mètre clairement délimité, et a tendance à réutiliser et optimiser ses propres compo-sants, qu’elle fait évoluer au gré des besoins des autres équipes.

Les Feature Teams vont avoir plus de latitude pour développer leurs propres solu-tions, et le modèle peut générer donc plus de travail en double et moins de mutuali-sation. Cependant, les guilds et chapters peuvent tout à fait promouvoir la réutilisa-tion de composant ou identifier du refactoring de code à prioriser ensuite par chaque Product Owner. Le code source du Produit appartenant à tous, il est de la responsa-bilité de chaque équipe d’y contribuer correctement (en identifiant les opportunités de réutilisation de l’existant).

Capacité à passer l’organisation à l’échelle

Les organisations qui adoptent le modèle Feature Team ont parfois du mal à gérer le passage à l’échelle, mais aussi les changements de priorité : si une Feature Team est provisoirement débordée, faut-il en créer une autre ? Dans ce cas, que contiendra son backlog ? Faut-il couper la fonctionnalité en deux ? Et si finalement la fonction-nalité sur laquelle travaillait l’équipe se révèle moins pertinente que prévu, que faire ?Le modèle fonctionne bien pour des problématiques sur lesquelles l’entreprise sou-haite investir de manière pérenne, mais n’est pas forcément si facile à piloter en cas de brusque croissance ou de changements rapides de priorité.

Le modèle Component Team pose moins de problèmes, car son périmètre est par nature durable (un composant ne disparaît pas du jour au lendemain). Par ailleurs, l’équipe component, par nature non pluridisciplinaire et donc moins collaborative qu’une équipe verticale, souffre peut-être moins de la contrainte de taille ; dans une certaine mesure, on peut juste ponctuellement ajouter des développeurs à l’équipe. Si celle-ci devient vraiment trop grosse, la question de diviser l’équipe component en deux peut se poser.


Dans le modèle SAFe, les squads étant (en grande partie) indifférenciées, le passage à l’échelle est normalement plus simple : on peut ajouter des collaborateurs à une équipe donnée jusqu’à atteindre la taille maximale d’une pizza team, après quoi il suffit de créer une autre équipe. Plus l’entreprise aura de squads, plus la capacité à délivrer augmente automatiquement, tout en maintenant (si le framework est bien appliqué) la vélocité de chaque squad.

Amélioration continue du Produit

L’amélioration continue est l’une des activités clés d’une équipe Produit. Il ne suffit pas d’enchaîner le développement et la mise en production de nouvelles fonctionnalités : il vaut parfois mieux améliorer l’existant que de commencer quelque chose de nouveau.

Le modèle de découpage vertical est clairement le plus adapté si l’équipe Produit souhaite favoriser l’amélioration continue. Chaque squad étant autonome sur un périmètre et responsable de son backlog, le Product Owner ou Product Manager est libre de prioriser avec son équipe l’amélioration de l’existant ou la création de nouvelles fonctionnalités selon des critères de valeur. Le système limite ainsi la ten-tation de ne faire que des nouveautés (au retour sur investissement souvent très incertain) aux dépens d’améliorations rapides apportant beaucoup de valeur qui ne sont jamais priorisées en mode projet.

Dans le modèle component, l’amélioration continue est portée indépendamment par chaque équipe composant, et doit faire l’objet d’une synchronisation pour éviter que les efforts des uns soient totalement ignorés par les autres. D’après notre expé-rience, comme les roadmaps de chaque composant sont souvent déjà pleines de besoins urgents identifiés par d’autres équipes, la part d’amélioration continue est en général réduite à la portion congrue (ou au bon vouloir du Product Owner). Enfin, comme ce modèle pousse souvent à un découpage des tâches préalables en mode projet, les petites tâches d’amélioration se voient souvent indéfiniment reportées.

Enfin, les framework comme SAFe comptent sur chaque Product Manager ou Pro-duct Owner pour prioriser dans les Program Increments des logiques d’amélioration. Le Product Owner a notamment la capacité à négocier une réduction de sa capacité à développer de nouvelles fonctionnalités pour faire davantage de gestion des inci-dents, de réduction de dette technique ou d’amélioration de l’existant.

60

Coût

A priori, aucun modèle n’est par nature plus coûteux qu’un autre. Cependant, le pas-sage d’une organisation découpée horizontalement à une organisation verticale peut effectivement entraîner une hausse des coûts, pour peu que l’on veuille intégrer à chaque squad l’ensemble des compétences nécessaires. Par exemple, une orga-nisation avec une équipe web de 20 développeurs et une équipe mobile de 4 déve-loppeurs pourrait se transformer en 5 Feature Teams de 5 développeurs chacune (ce qui entraînerait le recrutement d’un développeur supplémentaire). Le passage à un modèle SAFe peut de même se faire à effectif constant, ou nécessiter de muscler les compétences sur la partie Product Management (couche portfolio et programme). C’est d’ailleurs souvent le cas, l’un des objectifs de ce Framework étant de provoquer une transformation globale au niveau de l’organisation.

C’est l’une des raisons pour lesquelles le modèle hybride peut se révéler adapté dans certains cas, en conservant les compétences rares ou certains applicatifs socle dans leur propre Component Team et en transformant le reste de l’organisation en équipes verticales orientées utilisateur.

Enfin, il faut noter que les pertes de temps et inefficiences potentiellement générées par un modèle de découpage inadapté peuvent constituer des coûts cachés : si un modèle vertical se révèle plus efficace au niveau de la gouvernance (en minimisant les réunions, le time to market) ou de la qualité délivrée (grâce à de meilleures dé-cisions prises sur le terrain), il peut largement justifier le recrutement de quelques compétences supplémentaires par rapport à un modèle horizontal.

Conclusion

Le modèle dit “Spotify” organisé verticalement en Feature Teams est aujourd’hui le favori des pure players, et de nombreuses DSI de grandes entreprises ont adopté ou expérimentent des modèles d’agilité à l’échelle tels que SAFe ou LeSS. Cependant, aucune de ces solutions ne représente une solution miracle.


Pour nous, l’essentiel consiste à trouver un découpage qui donne du sens au travail effectué par les équipes, limite les dépendances entre les squads (et donc le temps perdu en réunions) et s’appuie sur des équipes de taille assez réduites (pizza teams).

Ainsi, le modèle Feature Team nous semble par nature plus compatible avec la vi-sion que nous portons sur le Product Management, et nous considérons chez Thiga qu’une équipe 100% organisée en component ne permettra pas d’être aussi efficace sur le long terme.Mais le découpage vertical pose également des problématiques pas toujours évi-dentes à résoudre : sur la gestion du transverse, l’alignement des équipes, le mana-gement des compétences…

La création de modèles hybrides mélangeant des Feature Teams complètement ver-ticales et indépendantes, et quelques Component Teams sur des sujets ciblés peut représenter une voie médiane intéressante, si ce n’est une solution de transition.

Des équipes composants peuvent également être constituées de façon temporaire, par exemple pour faire du rattrapage fonctionnel : dans le cas du lancement d’une application mobile, une squad dédiée peut développer d’un seul coup toutes les fonctionnalités disponibles sur le web et aujourd’hui portées par des Feature Teams ; une fois que l’application a rattrapé son retard fonctionnel, on peut envisager de dé-manteler l’équipe pour rapatrier ses compétences dans les diverses squads Produit.


Scaling Lean and Agile Development: Thinking and Organizational Tools for Large-Scale Scrum et Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Develop-ment with Large-Scale Scrum : incontournables, ces deux ouvrages de Craig Larman & Bas Vodde ont posé les bases de l’Agilité et du Lean à l’échelle. On leur doit entre autres le concept des Feature Teams.

Scaling Agile @Spotify with Tribes, Squads, Chapters and Guilds : en 2012, Henrik Kniberg et Anders Ivarsson ont permis au monde de découvrir l’organisation de Spotify, en précisant le découpage des équipes en fonctionnalités et la gestion des dépendances associées.

Scaling Your Product Team While Staying Agile : dans ce talk de plus d’une heure, Dan Podsedly livre un puissant témoignage des défis liés à l’organisation auxquels il a dû faire face chez Pivotal Software. Un must see.

62

Microservices : si le prétexte initial de ce passionnant article de Martin Fowler et James Lewis est de parler technique (les fameux ‘microservices’), il traite également de façon percutante de comment organiser ses équipes pour mettre en œuvre une architecture moderne.


COMMENT GÉRER LES DÉPENDANCES ENTRE LES ÉQUIPES ?

CHAPITRE 4

64

Je suis CPO et j’ai choisi de redessiner mon organisation Produit pour répondre à la croissance de mon équipe. Je dois à présent gérer les dépendances et adhérences inhérentes au modèle choisi. Une mauvaise synchronisation entre équipes fait que l’on s’aperçoit généralement trop tard du manque de cohérence d’une fonctionna-lité. Cela engendre du travail supplémentaire (impact négatif sur le time to market et obligation de revoir sa roadmap en raison des retards). On peut passer outre en contractant de la dette technique ou de la dette Produit pour livrer coûte que coûte, mais il ne s’agit pas d’une solution pérenne.

Chez Thiga, nous sommes conscients qu’avec de nombreuses équipes contribuant à un même Produit, les adhérences et dépendances sont inévitables : une grande partie de l’efficacité de votre organisation va dépendre de votre capacité à les anti-ciper et les gérer. Nous vous proposons dans ce chapitre des solutions pratiques aux nombreuses situations de friction que peut rencontrer votre organisation, qu’elle obéisse au modèle “Feature Team” ou qu’elle soit une hybridation de différents types de découpage.

Solution

Problème


La croissance d’un Produit s’accompagne généralement d’une augmentation des effectifs. On se retrouve alors à structurer une première squad et à devoir ensuite en créer une deuxième, puis 5, 10, voire plus.Les difficultés commencent à partir de 2 équipes, même si elles peuvent être réso-lues relativement rapidement à ce stade. Mais chaque palier ou changement d’or-ganisation peut faire apparaître son lot de nouveaux problèmes - ou amplifier les problèmes existants.

Entre éparpillement de la vision, dépendances techniques ou organisationnelles et télescopages involontaires, les squads se retrouvent à devoir gérer des situations qui les ralentissent et rendent leur quotidien désagréable. En conséquence, votre time to market s’allonge (chaque équipe étant impactée par les éventuels retards des autres équipes), la prédictibilité baisse, les équipes se lassent et dans le pire des cas la qualité de votre Produit se détériore.

En effet, créer une nouvelle squad équivaut inévitablement à multiplier le nombre de liens à gérer avec le reste de l’organisation. Il existe 2 types de liens :• la dépendance : une squad n’est pas autonome pour délivrer sa roadmap ou at-

teindre ses objectifs car une autre équipe doit réaliser une activité pour qu’elle puisse y parvenir.

• l’adhérence : une squad est autonome sur son périmètre mais son travail peut impacter le travail d’autres squads, et les 2 devront s’aligner pour garantir une cohé-rence globale de l’expérience utilisateur ou de la solution technique.

Dans ce chapitre, nous allons nous intéresser dans un premier temps aux différents types de dépendances et adhérences pouvant exister dans une organisation Produit de type verticale avec des équipes autonomes et multi-disciplinaires et vous pro-poser des pratiques qui vous permettront de les atténuer. Nous parlerons ensuite des principales dépendances et adhérences constatées dans des organisations hy-brides ou moins avancées dans leur transformation, et vous proposerons des pistes de solutions pour chacune.

66

Dépendances, adhérences et leviers à actionner dans une organisation Produit horizontale

Tribu

Adhérences ou dépendances

Squad 1Pizza team

composée de :

-Product Manager /Product Owner

-Product Designer-Data Analyst

-Développeurs : back-end, front-end web, mobile

-Opsetc

Squad 2

IDEM

Squad 3

IDEM

Équipes transverses

RHAchats

Juridique etc.

21

Dépendances et adhérences dans une organisation horizontale

Gestion des dépendances et adhérences entre squads Produit

Dans un modèle vertical, il est fréquent qu’une squad ait besoin qu’une autre squad développe une fonctionnalité, un socle technologique ou corrige un bug avant de pou-voir mettre en production sa propre fonctionnalité : il s’agit d’une dépendance forte. Par exemple, si une squad ayant pour objectif d’améliorer la communication avec l’uti-lisateur a choisi de prioriser dans son backlog une refonte totale du système d’envoi d’emails, les autres squads qui souhaiteraient travailler sur le contact par email avec l’utilisateur devront sans doute attendre que le nouveau module soit terminé, ou mettre la main à la pâte en aidant au développement.


Pour ce qui est des adhérences entre ces mêmes squads, elle surgissent notamment lorsque plusieurs squads travaillent en parallèle sur des sujets impactant un même cas d’usage donc un même parcours utilisateur. Si ces équipes ne communiquent pas correctement, l’expérience utilisateur peut en être pénalisée. Par exemple, dans le cas d’un service de streaming musical, la squad “playlist” pourrait choisir d’afficher une pop-up de confirmation chaque fois que l’utilisateur supprime une chanson de sa play-list ; tandis que la squad “librairie” pourrait prendre le parti de supprimer directement la chanson puis d’afficher une notification contextuelle permettant d’annuler l’action a posteriori. Le résultat n’est pas bloquant, chaque équipe pouvant développer et mettre en produc-tion sa fonctionnalité, mais l’expérience utilisateur s’en trouve dégradée à cause des incohérences, petites ou grosses, qui finissent par apparaître.

Il est possible de passer outre certaines incohérences en contractant de la dette tech-nique ou de la dette Produit pour livrer coûte que coûte, mais il ne s’agit pas d’une solution pérenne : sur le long terme, les désynchronisations entre squads coûtent cher.Ce type de dépendances est souvent inévitable : il s’agit du corollaire de l’autonomie laissée aux équipes. Une organisation verticale ne résoudra donc pas magiquement la coordination entre les équipes : il est nécessaire d’actionner un certain nombre de leviers afin de faire en sorte que le Produit reste cohérent dans son ensemble et que la collaboration entre les squads soit fluide et non cloisonnée. Nous préconisons de ne pas appliquer d’un seul coup l’ensemble de ces solutions mais de choisir celles qui conviennent le mieux à votre organisation, car implémenter toutes ces pratiques en même temps pourrait se révéler très chronophage pour vos équipes.

Levier 1 : Créer une instance d’arbitrage de la roadmap globale

La “kermesse” (terme emprunté à Deezer) est une instance de partage et d’arbitrage de la roadmap organisée avant le début de chaque trimestre. Cet atelier permet à chaque squad de présenter sa roadmap, de l’expliquer aux autres équipes et aux par-ties prenantes et de discuter ensuite les priorités.

68

LA “KERMESSE” DE DEEZER

Deezer a de nombreuses équipes, qui sont regroupées en “start-ups”. Une start-up est ici un domaine particulier du Produit (exemple : Pro-duct Features, Core App, Platform).

Chaque start-up possède ses propres objectifs business et sa road-map interne. Ces objectifs et ces roadmaps sont globalement discutés avec les différentes parties prenantes (comité de direction, Marketing, Ventes, Technique, Produit) lors d’un événement d’une demi-journée, dénommé la “kermesse”. La kermesse se déroule en 3 temps.

Au départ, les responsables de chaque start-up montent un stand (d’où le nom donné à l’atelier) où ils exposent visuellement leur roadmap pour les 3 mois à venir. Puis ils visitent les stands de leurs homologues. Cela permet de créer de la transparence et de la discussion.

Ensuite, les autres participants entrent dans l’arène : tout le monde se réunit et la kermesse commence. Les responsables de start-up ac-compagnés de leurs équipes doivent alors défendre leur roadmap en expliquant pourquoi ils priorisent certaines fonctionnalités ou chan-tiers techniques au détriment d’autres, tout en matérialisant la capacité maximale de réalisation pour le trimestre qui démarre. Des négocia-tions ont lieu, et les roadmaps sont ajustées au fil des échanges.

A la fin, les responsables réalisent une rétrospective pour améliorer le format des ateliers de la kermesse.

Ce format fun, mêlant structure et chaos, a l’avantage de réunir tout le monde dans le même espace, de donner une voix à chacun, de confron-ter les visions et d’aligner les équipes. Il s’agit d’un beau mélange de bottom-up et top-down.

Levier 2 : Mettre en place des instances de planification et de gestion des dépen-dances périodique (ex. le PI Planning)

En plus d’une instance servant à partager et ajuster la roadmap (telle que la “ker-messe”), il est nécessaire de mettre en place des instances de planification et de


Exemple de déroulé d’instance de planification (librement adapté de SAFe)

synchronisation périodiques dédiées notamment à la gestion des dépendances. C’est par exemple ce que propose SAFe avec le PI Planning : tous les 4 ou 5 sprints, l’ensemble des squads se réunit sur 1 à 2 journées complètes pour exposer chacune leur plan validé pour les prochains sprints. Puis elles identifient au cours d’un atelier l’ensemble des dépendances à anticiper, et les impacts éventuels sur la roadmap. Une telle réunion peut paraître chronophage et difficilement gérable, mais notre ex-périence montre que réunir physiquement l’ensemble des parties prenantes autour du Produit est le meilleur moyen de procéder ; une fois les squads alignées, et les dif-férents Product Managers au clair sur les priorités du Produit, le temps économisé sur la globalité du processus est très important.

On ne rappellera jamais assez qu’il est nécessaire que l’ensemble des Product Ma-nagers ait réalisé en amont du PI Planning un vrai travail de conception Produit (voir chapitre 6 “Comment industrialiser le Product Discovery ?”) et qu’ils présentent une roadmap dérisquée et claire pour les 4 / 5 sprints à venir afin d’assurer un PI Plan-ning efficace.

09:30 - 09:45 Introduction • Ouverture de la séance par un sponsor

• Présentation par chaque Product Manager des fonctionnalités à réaliser surle prochain trimestre

• Partage des éventuelles maquettes ou parcours

• Création du program board• Identification des dépendances• Travail entre équipes pour traiter ces dépendances

(architectes et product managers sont présents en facilitation)

• Présentation des résultats de chaque équipe et du plan pour traiter les dépendances

• Rétro du PI Planning• Identification des risques à anticiper et traiter au cours

du trimestre

• /

Présentations des roadmaps

Déjeuner

Ateliers d’équipe (points de synchro toutes les 45 min)

Restitution

Rétrospective

09:45 - 12:30

12:30 - 13:30

13:30 - 16:30

16:30 - 17:30

17:30 - 18:30

70

Levier 3 : Implémenter un outil de planification visuel tel que le Program Board

Le Program Board (outil emprunté à SAFe) est un outil visuel où les dépendances identifiées pour les prochains sprints sont matérialisées par des ficelles reliant les différents éléments ou sujets potentiellement bloquants. Ce tableau peut être créé par exemple chaque début de trimestre lors du PI Planning, mis à jour à chaque sprint et les ficelles coupées au fur et à mesure que les dépendances sont traitées.

Squad 1

Jalons généraux

Sprint 1

Étape importante / Événement

Fonctionnalité

Dépendance / Adhérence

Sprint 2 Sprint 3 Sprint 4

Squad 2

Squad 3

Squad 4

Un événement aura lieu lors du Sprint 3 tel qu’un

salon par exemple

Cette fonctionnalité ne pourra être livrée qu’à

condition que plusieurs équipes aient résolu leurs dépendances.

Une fonctionnalité placée dans le backlog d’une équipe sans lien avec

d’autres cartes signifie qu’elle peut être réalisée

indépendamment des autres équipes

Levier 4 : Constituer un design kit

Le design kit permet aux squads de fixer les bonnes pratiques UX et UI au niveau du Produit et de créer une bibliothèque de composants mutualisés, le tout en déclinant la charte graphique et la plateforme de marque. Le design kit garantit la cohérence du Produit et fait gagner du temps à toutes les squads en encourageant la réutili-sation et la mutualisation des composants ; si votre framework de développement front-end est lui aussi orienté composant, le design kit peut même inclure du code source réutilisable directement par n’importe quel développeur.

Exemple de Program Board


Levier 5 : Mettre en place un management visuel axé sur l’expérience utilisateur (Experience Board)

Chaque squad peut afficher sur un tableau les écrans sur lesquels elle compte tra-vailler dans les prochains sprints, regroupés par persona. En consultant ce tableau, les membres des squads peuvent anticiper les potentiels écarts d’expérience utilisa-teur liés à leurs travaux respectifs, et s’assurer de la cohérence des parcours pour un même utilisateur.

Levier 6 : Mettre en place des communautés de pratique

Comme expliqué dans le chapitre 3 sur le découpage des équipes Produit, le chapter est une communauté de pratiques autour d’un domaine d’expertise ou d’un métier commun (Design, Product Ownership, iOS, back-end, etc.), alors que la guild est une communauté de personnes partageant un intérêt pour un sujet en particulier (auto-matisation des tests, monitoring, sécurité, etc...). La mise en place de ces commu-nautés permet de partager les bonnes pratiques, d’identifier les adhérences et de les traiter avant qu’elles n’impactent démesurément le Produit. Le chapter “Design” peut par exemple construire et faire vivre le design kit, tandis que le chapter “Product Ownership” ou “back-end” peut garantir l’homogénéité des choix techniques effectués au sein des squads.

En plus des chapters et des guilds, Airbnb a par exemple mis en place des Experience Groups transverses. Les membres des squads ont un double rattachement : d’une part à leur squad (Growth, Booking, et Reviews), et d’autre part à un groupe d’expérience en charge d’assurer la cohérence de l’expérience des utilisateurs en se réunissant autour des deux principaux personae du Produit : les hôtes et les visiteurs.

72

Levier 7 : Créer un poste de Program Manager

Le rôle du Program Manager consiste à mettre de l’huile dans les rouages de l’organisation et porter des projets transverses en synchronisant les différents Product Owners / Product Managers des squads, tout en assurant une cohérence sur ce qui est mis en production.

Levier 8 : Mettre en place un processus d’open source interne

Voici une pratique qui a été expérimentée au sein des équipes OUI.sncf que nous recommandons : chaque équipe est propriétaire d’une portion de la base de code (celle correspondant à son périmètre). D’autres équipes peuvent effectuer des com-mits (demandes de modification du code source), mais seule la squad propriétaire peut valider l’intégration de ces modifications en production. Cette technique permet à chaque squad de travailler sur n’importe quelle partie du code, tout en maintenant un contrôle de cohérence et de qualité incarné par l’équipe la plus appropriée.

Organisation Produit de Airbnb

Growth Booking ReviewsSquad

PRODUCT TEAMS & EXPERIENCE GROUPS

Groupe d’exérience

Hot Experience Group

Guest Experience Group

Sally Billy Jenny

Bobby Claire Steve


Levier 9 : Implémenter des OKR

Les OKR, expliqués en détail dans le chapitre 2, sont un vecteur important d’aligne-ment entre les squads : en rendant les priorités transparentes et en alignant les objectifs des différents acteurs, ils permettent de simplifier les instances évoquées précédemment (kermesse, PI Planning) et de s’assurer que tout ce qui sera proposé par les squads sera conforme à la stratégie globale de l’entreprise.

Gestion des dépendances entre une squad et une équipe trans-verse (RH, achats…)

Les dépendances avec les équipes transverses sont nombreuses et il s’agit claire-ment de services et de rôles qui ne peuvent être intégrés à chaque squad. Il serait en effet absurde de préconiser l’intégration permanente d’un responsable RH ou juri-dique dans chacune des squads.

Les dépendances que nous avons observées lors de nos différentes missions sont liées à des besoins de recrutement ou de renforcement des équipes avec une forte dépendance vis-à-vis des services RH et achats (recrutement en interne ou en ex-terne), ou à des besoins d’expertise juridique ou ad’hoc. Le prix à payer est le même que pour les autres dépendances : le time to market s’allonge et la prédictibilité de livraison diminue lorsqu’une squad manque de res-sources et qu’elle n’est pas maître de ce paramètre. Une équipe à qui il manque un développeur ou un Product Designer verra un goulot d’étranglement se créer.

Nous proposons différentes solutions pour gérer au mieux ces dépendances inhé-rentes à toute organisation.

Levier 1 : Être délégataire de certaines activités réalisées par les services RH ou achats

Lorsque le recrutement de nouvelles ressources devient de plus en plus long et pro-blématique pour les squads, nous conseillons de réaliser un atelier conjoint entre les équipes RH et les squads, de décomposer les activités clés du processus de recrutement et de s’accorder sur un niveau de délégation pour chacune d’entre elles. Les équipes peuvent ainsi faire recruter les profils manquants au sein de leur squad plus rapidement.

Groupe d’exérience

74

Un processus classique se décomposerait par exemple de la manière suivante : rédaction des offres d’emploi > publication des offres d’emploi > sourcing des can-didats > qualification et tri des CV > contact des candidats > organisation des entre-tiens > réalisation des entretiens > proposition d’offre d’emploi > négociation des conditions de l’offre > remise du contrat de travail

Le service RH peut, par exemple, déléguer les premières étapes du processus à cha-cune des squads afin de fluidifier et d’accélérer le recrutement. Cette technique peut également être appliquée au service Achats pour le recours à une prestation externe.

Levier 2 : Négocier un budget de prestation à gérer en toute autonomie

Les squads font souvent appel à des prestataires externes afin de compléter les équipes avec les compétences et profils manquants. Ainsi, négocier un budget de prestation à l’année ou au semestre que chaque squad puisse gérer de façon auto-nome permettrait de fluidifier le recrutement des ressources externes.

Le processus et les exigences de recrutement des profils externes peut également être décomposé tel que décrit auparavant.

Levier 3 : Intégrer ponctuellement des expertises spécialisées au sein des squads concernées

Imaginons qu’une équipe ait un focus juridique ou réglementaire important lors de 4-5 sprints ou lors d’un trimestre ; dans ce cas, nous conseillons d’intégrer ponctuel-lement cette expertise à la squad. Nous préconisons que cette personne rejoigne physiquement l’équipe afin d’y être intégrée pleinement, et d’éviter la perte d’informa-tion et les allers-retours.

Si cette expertise concerne l’ensemble des squads, par exemple un expert RGPD (le sujet de l’année 2018 pour plusieurs organisations), nous préconisons d’utiliser le PI Planning tel que décrit précédemment pour y convier des spécialistes du sujet et d’aligner toute l’organisation autour de cet enjeu majeur.


Gestion des dépendances dans les organisations hybrides

Il n’est pas toujours possible d’intégrer dans chaque squad l’ensemble des compétences nécessaires pour lui donner une autonomie totale. Dans certaines organisations, pour des raisons pratiques ou budgétaires, des compétences sont main-tenues en transverse, que ce soit au niveau de la tribu ou au niveau de l’organisation Produit elle-même : Product Designers, Data Analysts, testeurs, Data Scientists, développeurs mobiles…

Nous rencontrons souvent lors de nos missions des organisations hybrides présen-tant tout ou partie des caractéristiques, adhérences et dépendances présentées ci-dessous :

Tribu

Adhérences ou dépendances

Équipe back-end

Component Team (mobile par exemple)

Équipe Ops

Squad 1 Squad 2 Squad 3Équipes Produit

transverses

Product Design

Data Analysis

Data Science

Tests

4

1 2

3

Dépendances et adhérences dans une organisation hybride

76

Cette situation crée automatiquement une forte dépendance entre les squads et ces entités transverses, allongeant le time to market dès que toutes les squads sollicitent en même temps la même équipe transverse. Les leviers présentés plus haut restent bien sûr applicables pour la plupart, et vous permettront de résoudre une partie des dépendances que vous allez rencontrer ; néanmoins nous avons des recommandations spécifiques à ces situations, en fonction de la typologie de votre organisation.

Gestion des dépendances avec une équipe back-end transverse

Il est fréquent - même s’il s’agit selon nous d’un anti-pattern - de voir des équipes back-end indépendantes ayant comme mission de servir des squads Produit très orientées “front-end”.

L’équipe back-end devra créer des API servant plusieurs squads et ne pourra s’adap-ter pleinement aux demandes de chacune et au rythme de développement néces-saire côté front-end. Ne sachant pas quand la fonctionnalité servie par le back-end sera prête, les squads développent souvent une certaine frustration de dépendre d’autres équipes pour accomplir leurs objectifs, tandis que les équipes back-end se retrouvent à jongler entre des priorités externes qu’elles ne maîtrisent pas ; ce type d’organisation peut générer à terme un turnover important.

Tout n’est pas perdu, cependant. Au-delà des solutions déjà mises en avant plus haut, vous pouvez essayer différents palliatifs pour remédier à ces problèmes.

Palliatif 1 : Intégrer ponctuellement des développeurs back-end aux squads

Dans le cadre de la coexistence de 2 back-ends, situation fréquemment rencontrée lors de la refonte d’un back-end vieillissant (legacy), nous préconisons, d’une part, d’intégrer les ressources dédiées au nouveau back-end dans chacune des squads afin d’amorcer la transition vers une organisation plus verticale ; et d’autre part, de conserver une équipe back-end dédiée assurant la maintenance des API existantes et la disponibilité des données le temps que la transition soit complète.


Les squads vont construire petit à petit un nouveau back-end, chacune créant ses nouveaux services sur une architecture neuve, tout en continuant de dépendre du legacy pour tous les services pas encore redéveloppés. Mais en intégrant les déve-loppeurs back au sein des squads, votre organisation gagnera fortement en vélocité pour tous les développements n’impactant pas le legacy.

Palliatif 2 : Définir des contrats d’interface entre les équipes back-end et front-end

Une API n’étant autre qu’une interface qui permet à deux systèmes complètement indépendants de se parler de façon automatisée, les contrats d’interface permettent à des équipes travaillant en mode “fournisseur-client” (ce qui est le cas d’une équipe back-end vis-à-vis de squads Produit) de paralléliser les développements. Ainsi une équipe front-end travaillant sur une fonctionnalité va se mettre d’accord et définir conjointement avec l’équipe back-end les données dont elle aura besoin, la façon dont elle les requêtera et le format sous lequel elle les recevra. Ce contrat d’interface permet à l’équipe front-end de développer la partie émergée de l’iceberg en “bouchonnant” les données reçues par le back-end, puis converger le plus rapidement possible vers un livrable commun.

Palliatif 3 : Mettre en place une architecture de microservices

Si vous intégrez des ressources back-end au sein des squads comme recommandé précédemment, il serait logique de mettre également en place une architecture en microservices. Cette architecture permet de découper le back-end “monolithique” en différents petits services indépendants qui servent des domaines fonctionnels différents. Ainsi, chaque Feature Team comme son nom l’indique maîtrisera de bout en bout son domaine fonctionnel, sera chargée de développer ses propres microser-vices et de les rendre interopérables avec les autres squads.

Notez qu’avec une architecture de ce type, vous créerez de facto de nouvelles adhé-rences entre chacune des Feature Teams (puisque chacune sera responsable de ses propres services) ; mais ces adhérences sont plus faciles à traiter que la rela-tion client-fournisseur entre une équipe back-end unique et de nombreuses équipes front-end.

78

Gestion des dépendances avec une équipe Ops

Tout comme le dispositif décrit auparavant, il est fréquent de voir l’équipe “Ops” tra-vailler indépendamment des squads et ne pas y être intégrée directement.

Cette dépendance concerne en grande partie la mise en place des outils de dévelop-pement mais surtout la mise en production de nouvelles fonctionnalités. Ainsi, après avoir développé un ensemble de fonctionnalités, les squads doivent envoyer leur livrable afin qu’il soit déployé sur les différents environnements appropriés par une équipe “Ops” qui reçoit les demandes de mise en production des différentes équipes et qui les priorise. Autant la dépendance précédente avec les équipes back-end peut facilement être contournée, autant la dépendance avec les équipes Ops peut mener à des situations de bloquage assez graves et être fatale aux équipes.

En plus des effets précédemment cités, que sont l’allongement du time to market, la baisse de prédictibilité et la lassitude des membres des squads, s’ajoute la mise en danger des livraisons. Bien des équipes travaillant dans un tel modèle ont vu des fonctionnalités nécessiter 3 à 6 mois avant de partir en production, devenant caduques en perdant toute leur valeur pour l’utilisateur ; voire ne jamais partir en production, le lot de fonctionnalités revenant en arrière pour la correction d’une ano-malie ou l’intégration d’une nouvelle contrainte d’exploitation.

Nous ne prétendons pas être des experts techniques ni des experts du DevOps, c’est pour cela que nous nous contenterons de récapituler des solutions Ops et DevOps rencontrées lors de nos différentes interventions.

Solution 1 : Mettre en place un management visuel (ex : kanban) représentant le pipeline des livraisons et les règles de priorisation de ces mises en production.

Solution 2 : Intégrer les exigences de l’équipe “Ops” dans le travail quotidien des squads en faisant des user stories “Ops ready”. Les équipes intègrent les contraintes imposées par les équipes Ops et Sécurité (machines disponibles, routage correct, firewall bien configuré, etc.) à la Definition of Ready des users stories.

Solution 3 : Proposer aux squads et notamment aux développeurs qui les com-


posent des usines logicielles as a Service, par exemple : aider les équipes de déve-loppement à mettre en place un outil d’intégration continue tel que Jenkins.

Nous restons néanmoins convaincus que la meilleure solution pour promouvoir l’agi-lité et faciliter le processus de Product Development reste la mise en place d’une vraie culture DevOps au sein de l’organisation, en intégrant un Ops directement dans chacune des squads afin de rendre les équipes réellement indépendantes de la conception à la mise en production.

Gestion des dépendances avec une équipe composant indé-pendante (souvent mobile)

Nous avons constaté dans de nombreuses organisations la présence d’une équipe mobile indépendante des squads. En effet, les spécificités techniques des outils et plateformes de développement mobile poussent souvent à regrouper les déve-loppeurs disposant de ces compétences dans la même équipe. De même, les Pro-duct Managers et Product Designers mobiles doivent bien maîtriser les guidelines de Google (Android) et Apple (iOS) qui changent très souvent, et connaître les spéci-ficités de la conception de Produits mobiles.

Enfin, la plupart des Produits étant déclinés à la fois sur iOS et sur Android, il n’est pas toujours pertinent ou possible en terme de coûts d’intégrer à chaque squad un développeur mobile spécialiste de chaque OS.

Les leviers que nous proposons pour gérer cette situation :

Levier 1 : Conserver les équipes mobiles (ou autres composants) et adopter une logique d’équipe “éclaireuse” vis-à-vis des squads

Si vous avez dans votre organisation des équipes orientées fonctionnalités d’un côté et plusieurs équipes composants orientées plateformes (iOS, android, objet connec-té...), un bon moyen de traiter les inévitables adhérences entre ces squads consiste à adopter une logique d’équipe “éclaireuse”. Concrètement, les squads verticales développeront leur fonctionnalité en partenariat avec une seule des équipes com-posants pour commencer, ce qui permettra de structurer le travail de conception, d’aplanir les difficultés et d’obtenir rapidement des retours utilisateurs. Une fois la

80

fonctionnalité déployée sur l’un des supports, les autres équipes composants décli-neront la fonctionnalité sur leur propre plateforme, en bénéficiant directement du travail déjà réalisé.

Cette approche est par exemple celle adoptée chez Evernote, un Produit qui est conçu dès le départ pour fonctionner sur un maximum de plateformes différentes. Ce rôle d’équipe “éclaireuse” peut bien entendu tourner, en fonction du contexte et des fonctionnalités.

Levier 2 : Dissoudre l’équipe mobile une fois le périmètre fonctionnel de l’applica-tion équivalent à la version web

Le développement des applications mobiles intervient souvent après le lancement d’un Produit web à succès, une fois le Product Market Fit atteint et un usage récur-rent créé. Dans ce cas, les entreprises créent en général une équipe mobile dédiée, même si elles sont par ailleurs organisées verticalement.Sauf si l’application propose un jeu de fonctionnalités complètement différent de la version web, cette équipe doit “rattraper” dans la version mobile le périmètre fonc-tionnel existant sur le site. Dans ce cadre là, avoir une équipe dédiée à ce sujet peut permettre d’avancer plus vite en minimisant les adhérences (le Product Owner de cette squad mobile bénéficiant du travail de conception déjà effectué au sein des autres squads web).Une fois la parité atteinte entre les fonctionnalités de l’application mobile et celles du web, on peut envisager de dissoudre la squad mobile et répartir ses membres dans diverses squads verticales, où ils pourront continuer de développer les fonctionnali-tés existantes et créer de nouvelles fonctionnalités.

Présence d’équipes regroupant des compétences transverses au sein de la tribu : Product Designers, Data Scientists, testeurs, etc.

Pour les mêmes raisons exposées ci-dessus à propos des équipes mobiles, il n’est pas toujours possible de disséminer dans chaque squad l’ensemble des compé-tences nécessaires : faute de talents disponibles, le Product Design, la Data Science


ou encore la QA sont parfois regroupés au niveau de la tribu voire de l’organisation Produit, et travaillent pour le compte de l’ensemble des squads. Bien que parfois inévitable, ce schéma génère de nombreuses adhérences souvent extrêmement pré-judiciables à l’efficience des squads. Nous préconisons les solutions suivantes afin de limiter les frictions et les goulots d’étranglement :

Solution 1 : “Agiliser” les équipes transverses

Etant donné que ces équipes travaillent en forte proximité avec des squads fonction-nant souvent en mode sprint, nous préconisons qu’elles s’organisent selon le même rythme afin de pouvoir :• se synchroniser sur les moments forts de la vie des squads• ménager du temps pour l’itération• promouvoir une logique MVP en travaillant sur des sujets livrables dans un sprint

plutôt que des projets de grande taille dont on ne voit pas le bout• éviter l’effet tunnel et faire en sorte que l’équipe transverse ne se concentre pas sur

la production de livrables pour une seule squad tout en ignorant les autres• faire prendre conscience aux squads de la charge de travail au sein des équipes

transverses, et que leurs demandes ne constituent qu’une partie du backlog de ces équipes

Nous proposons également de transposer les cérémonies agiles à ces équipes de la sorte :

• Sprint plannings : organiser des sprint plannings en compagnie d’un représentant de chaque squad, le Product Manager par exemple, afin de s’engager sur un objectif et un périmètre de sprint viables et atteignables. Chacune des tâches composant le sprint de l’équipe transverse ne doit pas obligatoirement être chiffré (en fonction de la nature du travail produit par l’équipe, ce n’est pas forcément possible), mais au moins priorisé par rapport au reste des tâches. La présence du CPO peut être nécessaire lors de ce sprint planning afin d’aider à la priorisation commune.

• Daily meetings : les équipes transverses peuvent se présenter aux daily des équipes concernées par leur travail de la veille ou leur travail du jour afin de les tenir au cou-rant des avancements.

• Points de synchronisation : afin de tenir le Product Manager au courant de l’avance-ment de ses sujets, des points de synchronisation informels peuvent être organisés.

82

• Démo : une démo par équipe transverse peut être organisée afin de tenir au cou-rant les squads de ce qui a été réalisé. Cette démo permettra de présenter les ma-quettes ou les résultats d’une recherche utilisateur par l’équipe de Product Design, présenter un nouvel outil de test automatisé par l’équipe QA, ou résumer une ana-lyse réalisée par l’équipe de Data Science.

Solution 2 : Rendre les squads de plus en plus autonomes

Cette autonomisation des squads passe d’abord par la formation des Product Ma-nagers aux compétences transverses nécessaires pour gérer un Produit de A à Z. Ainsi un Product Manager peut se former au Product Design, aux analytics, voire aux outils et processus de qualité (voir chapitre 5 “Quels profils Produit recruter lorsque mon organisation passe à l’échelle ?”).

Cette autonomie des squads passe également par le choix d’outils qui facilitent leur travail : la mise en place d’un design kit tel que décrit précédemment ou des outils d’analytics tels que Segment permettent de simplifier et de standardiser la collecte et l’analyse des données utilisateur au sein des squads, en minimisant la dépen-dance vis à vis des équipes transverses qui peuvent se concentrer sur du travail de fond ou de long terme.

Conclusion

Les adhérences et dépendances sont inhérentes à tout modèle d’organisation, que ce soit entre squads de type Feature Teams ou entre des équipes transverses dans des organisations hybrides.

Pour nous, l’essentiel reste de trouver les leviers à mettre en place afin de limiter les effets des dépendances en terme d’allongement du time to market, de baisse de la prédictibilité et de démotivation des équipes. Néanmoins, nous restons per-suadés que les organisations verticales avec des équipes pluridisciplinaires et autonomes sont non seulement plus compatibles avec la vision que nous portons sur le Product Management, mais conduisent également à de meilleurs arbitrages et à une gestion des relations entre équipes plus aisée : les adhérences sont certes


multipliées, mais les dépendances minimisées, et ce sont bien ces dernières qui posent le plus de problème.

Nous pensons qu’il est important pour une organisation de se rapprocher progressi-vement de ce modèle en investissant dans un maximum de profils pluridisciplinaires, en recrutant des Product Managers et des développeurs full-stack, en les formant constamment pour maintenir ou créer cette pluridisciplinarité et en insistant sur la né-cessité d’un état d’esprit ouvert au changement et à l’itération organisationnelle. Plus vous valoriserez la pluridisciplinarité, et plus la gestion des dépendances sera aisée.


How to Organize a Team that Designs End-to-End Experiences : Katie Dill, Head of Experience Design chez Airbnb, explique comment maintenir une expérience utilisateur cohérente de bout en bout avec une organisation en Feature Teams.

PI Planning - Scaled Agile Framework : le site officiel de SAFe détaille les prérequis et le fonctionne-ment précis d’un PI Planning.


QUELS PROFILS PRODUIT RECRUTER LORSQUE MON ORGANISATION PASSE À L’ÉCHELLE ?

CHAPITRE 5

86

Je suis CPO ou Lead Product Manager et mon Produit ou mon portefeuille de Produits grossit. Pour accompagner cette croissance, je ne sais pas qui recruter, quelles compétences chercher, comment répartir les rôles entre les membres de mon équipe mais aussi comment assurer la motivation et la progression de chacun sans créer de sentiment de frustration ou de perte de périmètre.

Nous préconisons d’adapter les profils recrutés au cycle de vie du Produit. Nous vous présentons les instants charnières qui nécessitent un passage à l’échelle, ainsi qu’une liste de compétences relationnelles et techniques que vous devez rechercher dans les profils Produit que vous allez recruter.Pour les passages à l’échelle de grande envergure, nous proposons également un framework de formation, des parcours de carrière ainsi que des techniques RH pour gérer au mieux l’onboarding des nouveaux et la frustration des anciens.

Solution

Problème


Passer une organisation Produit à l’échelle consiste à accroître le nombre d’équipes Produit pour répondre aux nouvelles problématiques qui apparaissent lorsque celui-ci s’enrichit.Cette augmentation de la taille des équipes amène logiquement à revoir l’organisa-tion, les rôles de chacun ainsi que les processus afin d’accompagner la croissance et les objectifs de votre société.

Un passage à l’échelle implique inéluctablement des recrutements et donc du bud-get. Votre comité de direction aura plusieurs options pour atteindre les objectifs de l’entreprise telles qu’investir dans plus de Marketing ou doubler les effectifs de vente, par exemple. Il vous incombe de les convaincre avec pédagogie et chiffres à l’appui que l’investissement Produit est stratégique pour l’entreprise de par la valeur qu’il générera pour l’entreprise dans son ensemble.

Dis-moi à quelle étape se trouve ton Produit, je te dirai comment passer à l’échelle

La ou les personnes s’occupant du Produit au sein d’une organisation jouent des rôles différents selon la maturité du Produit et de l’entreprise. Une jeune start-up n’aura pas besoin des mêmes compétences ni des mêmes processus qu’une orga-nisation ayant un portefeuille de Produits matures.

Lors de nos différentes interventions, nous avons identifié 4 phases du cycle de vie du Produit qui permettent de structurer la mise à l’échelle d’une équipe Produit :• La création du Produit • La phase de croissance pré - Product Market Fit• La phase de croissance post - Product Market Fit• La maturité du Produit

Votre premier exercice sera d’identifier l’étape du cycle dans lequel se trouve votre Produit, ce qui vous permettra de vous concentrer sur la mise en place des actions les plus impactantes au vu de votre contexte.

88

Pour chacune de ces phases, nous analyserons les évènements déclencheurs d’un passage à l’échelle ainsi que les types de profils à recruter. Nous vous proposerons également des solutions pour mener la conduite du changement au sein de vos équipes ainsi que des parcours de carrière et de formation pour gérer au mieux les envies de progression de chacun.

Création du Produit : fondation d’une start-up ou création d’un nouveau Produit dans une entreprise existante

Il est vrai que nous avons tendance à nous adresser dans ce livre aux personnes qui tiennent le rôle de CPO, mais n’oublions pas que les premiers concernés dans le cycle de vie d’un Produit sont les fondateurs mêmes de l’entreprise dans le cas d’une start-up ou tout porteur d’une initiative Produit dans une entreprise existante.

Lors de cette première étape du cycle de vie, cette personne est souvent très proche de son Produit car y investissant à la fois son temps, ses espoirs, et parfois son argent (s’il en est le fondateur). Ce premier « Product Manager » testera des hypo-

Evolution de l'organisation suivant les phases du cycle de vie du Produit

temps

SuccèsProduct Market Fit

CEO ouPorteur d’initiative

PM/PO PM/PO PM/PO PM/PO PM/PO PM PO

Périmètre #1 Périmètre #2 Périmètre #3

#utilisateurs


thèses, recrutera les bêta-testeurs, réalisera le design des premières interfaces, su-pervisera les premiers recrutements de développeurs (au moins 2 pour commencer), voire écrira une partie du code de son Produit s’il a des compétences techniques.

Croissance préalable au Product Market Fit

Un Produit minimum viable (MVP) a été développé et mis sur le marché, et les pre-miers résultats sont prometteurs : les utilisateurs ont démontré une certaine appé-tence vis-à-vis du Produit, il a une bonne base d’ « early adopters » et l’usage est grandissant. Néanmoins, il manque la ou les fonctionnalités pour le faire décoller.Suite à un travail sur la stratégie Produit, nourri de recherche utilisateur (quantita-tive ou qualitative), les fondateurs peuvent découvrir que le Produit nécessite d’être lancé sur un nouveau marché, qu’ils ont besoin d’affiner leur cible ou de développer un lot de fonctionnalités plébiscitées par les utilisateurs, qui créeraient plus de réten-tion et généreraient du chiffre d’affaires additionnel.Les pistes d’évolution possibles pour le Produit sont nombreuses, mais les fonda-teurs seuls, ou leur équipe réduite, ne peuvent pas toujours toutes les absorber.

Afin d’accompagner cette phase et d’atteindre le Product Market Fit, il sera proba-blement nécessaire de recruter un Product Manager / Product Owner pour travailler avec les 2 ou 3 développeurs que compte l’entreprise à ce stade, et - si ce n’est pas déjà le cas - au moins un Product Designer. Cette « petite » équipe déchargera les fondateurs des tâches opérationnelles liées au développement Produit et leur per-mettra de se concentrer sur le développement commercial et la recherche de finan-cements qui se conclura dans le meilleur des cas par une levée de fonds.

Quel est le bon moment pour recruter le premier Product Manager / Product Owner ?

La réponse est simple : lorsque le Product Management devient le goulot d’étrangle-ment dans l’entreprise.

90

Un processus de Product Management qui fonctionne bien est un processus dans lequel les développeurs ont en permanence un backlog priorisé et bien fourni de spécifications Produit qui découlent d’un réel travail de recherche utilisateur à la fois quantitatif et qualitatif (voir chapitre n°6 : Comment industrialiser le Product Discovery ?).

Quel profil Produit recruter ?

Il est important pour les Product Managers dans les entreprises en phase de démar-rage de se concentrer sur la compréhension des problèmes utilisateurs et l’atteinte du Product Market Fit, afin de prioriser dans leur backlog les fonctionnalités maximi-sant le retour sur investissement. Le contraire serait vraisemblablement fatal pour le Produit à ce stade...

Mais il est également essentiel que le Product Manager soit proche des équipes de développement afin de veiller à la bonne réalisation et au bon time to market des fonctionnalités.

Pour ce qui est des compétences à rechercher chez un Product Manager, nous vous conseillons de vous orienter vers des profils de Product Manager full stack gérant à la fois les aspects stratégiques et tactiques du Produit. Un bon Product Manager full stack devra à la fois maîtriser la dimension “business” (connaissance du marché, création de business plan / modèle économique, suivi et analyse chiffrée des don-nées client), la dimension UX (connaissance des différents patterns de design, des principes de la recherche utilisateur, maîtrise minimale des outils de prototypage), sans oublier la dimension technique (connaissance des technologies utilisées, de l’architecture, du modèle de données, des API…).

Donc, en plus de son rôle de Product Manager, il remplira souvent le rôle de Product Owner voire de Product Designer. Il jonglera ainsi entre la connaissance sectorielle, la validation de fonctionnalités Produit, la réalisation de maquettes, le découpage, la priorisation et le suivi du backlog. Néanmoins, nous sommes conscients que le mouton à 5 pattes n’existe pas et qu’il faudra se focaliser davantage sur l’un des 3 aspects selon les caractéristiques et le modèle économique du Produit.


Afin d’accompagner le recrutement de profils tout au long du cycle de vie du Produit, nous nous appuyons souvent sur la théorie de Robert X. Cringley (Pioneers, Sett-lers, Town Planners) que nous détaillerons tout au long de ce chapitre. Ce concept a notamment été mis en place par Airbnb.

Lors de cette étape préalable au Product Market Fit, nous parlons de Product Mana-gers de type « Pioneers » car ils devront explorer de nouvelles pistes, être touche-à-tout, aimer prototyper, réaliser des solutions rapides et à moindre coût, et prendre des risques. Ces profils devront également être très adaptables et ne devront pas avoir peur du changement, car ils seront la pierre angulaire des passages à l’échelle futurs.

COMMENT REPÉRER UN PRODUCT MANAGER “PIONEER” ?

Quelques questions à poser en entretien de recrutement • Quelle est votre méthodologie pour découvrir les besoins des

utilisateurs ?• Citez un exemple de fonctionnalité non “scalable” pour lancer un Pro-

duit le plus rapidement possible• Comment mesurez-vous l’atteinte du Product Market Fit ?• Je veux sortir la fonctionnalité X dans 15 jours, comment faites-vous

pour la penser et la construire ?

Comment gérer la frustration des fondateurs liée à la perte de contrôle sur le Produit ?

Le recrutement mais surtout l’intégration du premier Product Manager peut s’avérer difficile. Le ou les fondateurs auront souvent du mal à lâcher les rênes de leur Pro-duit et à faire confiance à une nouvelle personne, aussi expérimentée soit-elle. Cela peut être très frustrant pour le Product Manager qui aura l’impression de n’être qu’un passe-plat entre l’équipe dirigeante et la squad.

92

Il sera essentiel pour les fondateurs de l’entreprise de faire un travail de délégation et de laisser la main à ce Product Manager afin de se ménager du temps pour d’autres activités : commerce, lancement du Produit dans un autre pays, etc. Le Product Ma-nager n’est pas uniquement un chef de projet qui exécutera leurs desiderata auprès des équipes de développement, c’est un élément clé dans la compréhension des utilisateurs et de leurs problèmes. Qui plus est, il leur permettra sûrement d’éviter de s’enfermer dans leurs idées initiales de Produit et de forcer des solutions même si le marché ne s’y prête pas.

Ainsi le rôle des fondateurs sera de donner la vision long terme qui servira de cap à l’équipe Produit. Il s’agira de regarder au-delà des fonctionnalités et de penser à leur modèle d’entreprise dans son ensemble.

DELEGATION POKER (MANAGEMENT 3.0) PAR JURGEN APPELO

1

AnnoncerJe leur donne ůĞƐ�ŝŶƐƚƌƵĐƟŽŶƐ

2

VendreJ’essaie de leur

vendre ma décision

3

ConsulterJe les consulte puis je décide

4

AccordNous nous

ŵĞƩŽŶƐ�Ě͛ĂĐĐŽƌĚ

5

ConseillerJe conseille,

mais ce sont eux qui décident

6

S’informerJe m’informe

de leur décision

7

DéléguerJe délègue

complètement

www.management30.com/delegation-poker

www.management30.com/delegation-poker


L’objectif est de permettre aux membres d’une équipe ou à des équipes différentes de discuter et de s’entendre sur le niveau de délégation pour chacune des activités qui les lient. Les niveaux de délégation vont du commandement “je leur dis quoi faire” à la délégation totale “je délègue complètement”. L’exercice peut convenir également aux équipes de plus grande taille.Pour en savoir plus sur le déroulé, vous pouvez vous référer aux “res-sources - pour aller plus loin” du chapitre.

Croissance post - Product Market Fit

Le Produit a atteint son Product Market Fit et l’entreprise rencontre de nouvelles problématiques liées à la croissance.

Quel est le bon moment pour étoffer l’équipe Produit ?

Les éléments déclencheurs d’un passage à l’échelle après atteinte du Product Mar-ket Fit sont souvent liés à une levée de fonds récemment réalisée mais également à un succès grandissant du Produit qui nécessite plus de développements afin de répondre aux nouvelles problématiques des utilisateurs, d’innover et de garder de l’avance fonctionnelle par rapport à la concurrence.

Quels profils Produit recruter ?

Afin d’accompagner cette phase de forte croissance, la taille de l’équipe de dévelop-pement est alors amenée à croître et l’équipe Produit doit grossir inévitablement. Une seule personne ne peut être responsable du Produit à ce stade, à moins d’être surchargée et de finir à bout de forces. Qui plus est, le Produit change maintenant moins fréquemment et de façon moins radicale que lors de la phase d’expérimenta-tion pré - Product Market Fit, ce qui facilite le partage des responsabilités entre un groupe de personnes.

94

Ainsi, lors de cette phase, il est souvent d’usage de constituer un ou plusieurs bi-nômes composés d’un Product Manager et d’un Product Owner travaillant chacun avec une équipe de développement. Le premier est tourné vers les clients, le marché et les parties prenantes, l’autre, plus technique, est tourné vers l’équipe de dévelop-pement. Il faut néanmoins se prémunir du risque de parasiter la transmission entre stratégie et opérationnel et reproduire ainsi un modèle client/fournisseur : Business / MOA / MOE.

Notre recommandation est d’avoir :• Deux rôles séparés lorsque le marché est mouvant car il sera difficile pour une

seule personne de faire à la fois de la recherche utilisateur, de l’analyse de statis-tiques utilisateurs, de tester les fonctionnalités livrées par les développeurs et de spécifier les user stories des sprints à venir.

• Un seul rôle lorsque le marché est mature, que le rythme de développement devient moins soutenu et que le Produit est en phase d’amélioration incrémentale.

Contrairement à la période précédente où le Product Manager était un couteau suisse, cette phase du cycle de vie du Produit nécessite des profils que l’on nomme souvent des « Settlers ». Ce sont des profils qui aideront l’entreprise à croître. Ce sont des passionnés d’optimisation, d’analytics et de Growth Marketing.

COMMENT REPÉRER UN PRODUCT MANAGER DE TYPE “SETTLER” ?

Quelques questions à poser en entretien de recrutement :• Comment décomposeriez-vous notre entonnoir de conversion ?• Comment mettez-vous en place un test A/B ? • Parlons de la fonctionnalité «X» - à votre avis quel est le cas d’usage

principal de cette fonctionnalité et comment la mesureriez-vous ?• Parlez-moi d’une fois où vous avez influencé le comportement des uti-

lisateurs à travers le Produit?


LE GUIDE D’ENTRETIEN DE THIGA

Le recrutement des meilleurs profils de Product Managers / Product Owners est l’un des piliers de l’activité de Thiga. C’est pourquoi nous avons développé un processus de recrutement qui évalue au cours de plusieurs entretiens les différentes facettes essentielles du bon Pro-duct Manager et d’un bon Product Owner incluant les soft skills qui touchent au savoir-être jusqu’aux compétences plus verticales qui couvrent l’intégralité du spectre du Produit.

Soft Skills Ces compétences sont les fondements d’un bon profil de Product Mana-ger car c’est sur elles que repose sa capacité à être un décisionnaire et un communiquant de qualité.

Quelques questions à poser : • Un manager estime que la fonctionnalité A est la plus importante tan-

dis qu’un autre dit que c’est la B, comment choisissez-vous laquelle implémenter ?

• Comment pensez-vous que le Product Manager doit interagir avec les développeurs ? Quelle est la relation idéale à entretenir avec eux ?

• Racontez-moi comment vous avez surmonté un échec Produit ou de mauvais retours concernant votre Produit.

Compétences BusinessUn bon Product Manager est également celui ou celle qui sait évaluer le potentiel d’un marché ou les opportunités de monétisation d’une fonc-tionnalité ou d’un Produit.

Quelques questions à poser • Quelle distinction faites-vous entre modèle économique, business

plan, roadmap Produit ?• Selon vous, comment en est-on venu à fixer un prix de XX€ pour tel

Produit ?• Quels indicateurs business suivez-vous dans votre projet actuel ?

96

Compétences UXParce que nous construisons nos Produits dans une dynamique centrée utilisateur, l’UX est au cœur de notre réflexion. Identifier des besoins avérés et construire des fonctionnalités qui y répondent efficacement est la clef de voûte de la mission du Product Manager.

Quelques questions à poser :• Qu’est ce qu’un Product Designer ? Quelle différence faites-vous entre

UX et UI ?• Comment travaillez-vous avec des UX designers ? Peut-on travailler

en agile avec des UX ?• Quelle place réservez-vous à ce travail dans votre méthodologie globale ?• Quels outils utilisez-vous pour collecter des retours utilisateurs ?

Compétences de Product OwnershipLa construction d’un bon Produit nécessite une bonne maîtrise de la méthodologie. Il est donc essentiel d’évaluer la compréhension qu’un candidat a de la méthodologie du Product Owner, de ses enjeux, de ses limites, et de la nécessité de l’adapter à ses besoins.

Quelques questions à poser : • Quelle différence faites-vous entre user story, fonctionnalité et epic ?• Connaissez-vous les différents environnements de développements /

outils utilisés par votre équipe de développement ? Sauriez-vous ex-pliquer l’usage de chacun d’entre eux ?

• Qu’est-ce qu’une API ? Quel en est le fonctionnement dans les grandes lignes ?

Compétences AnalyticsL’analyse quantitative est un pilier du Produit, car si la démarche du Product Management est rarement totalement data driven, elle se doit d’être au minimum data informed. Les chiffres sont le carnet de santé du Produit.

Quelques questions à poser :• Comment choisissez-vous vos KPIs ? Comment les utilisez-vous dans

le suivi de performance de votre Produit ?• Comment mesureriez-vous le succès d’un site qui vend des cactus en ligne ?• Selon vous, que serait-il important de suivre sur un Produit (prenez

un exemple) pour en mesurer la performance ? Comment vous y pren-driez-vous ?


Compétences de Growth MarketingEnfin, il est important de ne pas oublier l’aspect “croissance” de votre Produit. En effet, la maîtrise des principes d’acquisition, d’activation, de rétention, de revenu et de referral font également partie de la palette de compétences Produit du Product Owner.

Quelques questions à poser :

• Pourriez-vous expliquer l’intérêt du framework AARRR ?• Racontez-nous une situation où vous avez dû optimiser votre enton-

noir d’usage. Comment avez-vous procédé ? Quelles métriques avez-vous choisi de suivre ?

• Quels leviers connaissez-vous pour améliorer l’acquisition ? La réten-tion ? La recommandation ?

En plus des Product Managers et Product Owners, il est également possible de re-cruter d’autres profils Produit permettant d’étendre le champ de compétences de l’équipe et aux Product Managers de se focaliser sur leur cœur de métier.

Il s’agit du moment idéal pour commencer à constituer une équipe de Growth Pro-duct Managers spécialisés qui assureront la croissance du Produit via des tech-niques d’acquisition et de rétention.

Une équipe de Data Scientists, indépendante ou intégrée au sein des squads, peut travailler en support des Product Managers. Elle leur fournira des analyses et des recommandations, ou travaillera sur l’amélioration des algorithmes du Produit ou la création de nouvelles fonctionnalités.

Il est à noter que lors de phases de passage à l’échelle, le recrutement est très chro-nophage pour les fondateurs ou le CEO et représentera plus de 25% de leur temps. Il est également important d’impliquer des profils de différents domaines dans le recrutement de vos Product Managers et de vos Product Owners car ils auront à interagir avec l’ensemble de la société.

98

Passage à l’échelle sur un Produit à succès (plusieurs équipes)

Lorsque le Produit connaît un réel succès, que les levées de fonds s’enchaînent et que les visiteurs se comptent en millions, l’équipe qui le gère grossit, les profils se multiplient et se spécialisent et tout ce monde a besoin de se structurer.

Il est dorénavant important d’assembler une combinaison diversifiée de compé-tences opérationnelles et d’expériences sectorielles, mais également de permettre aux membres de l’équipe de travailler dans un cadre clair tout en gérant les envies de progression et les parcours de carrière de chacun.

Quel profils recruter ?

La question qui nous est fréquemment posée est la suivante : dois-je recruter ou faire progresser mes équipes et m’appuyer sur la promotion interne ? La question est judicieuse car il y a clairement un équilibre à trouver entre des personnes qui connaissent bien votre Produit et la nécessité d’avoir un regard neuf avec des nou-velles pratiques et des nouvelles façons de concevoir.


Stratégie du “Evolve” (faire progresser) Stratégie du “Hire” (recruter)

Faire monter en compétences les membres de l’équipe Produit actuelle (Product Owner, Product Manager, Product Designer, Scrum Master ou en-core développeur) présente l’avantage évident qu’ils connaissent déjà très bien le Produit. N’oubliez pas cepen-dant que vous devrez probablement les remplacer à leur ancien poste...

• Transformer un développeur en Product Manager : intéressant si le Produit est technique, par exemple Product Manager d’une API.

• Faire évoluer un Product Designer en Product Manager peut être intéres-sant si le Produit est B2C et très orien-té utilisateur.

• Il est également pertinent d’étudier si les autres départements de l’entre-prise, au sein de l’équipe Marketing notamment, ne présentent pas des profils intéressants.

Le recrutement de profils expérimentés permet d’apporter un regard externe cri-tique et des bonnes pratiques en matière de Product Management

• Recruter des personnes venant d’un métier différent pour apporter une ap-proche différente qui peut enrichir les pratiques déjà en place.

• Recruter à l’extérieur de son organisa-tion afin d’acquérir un nouveau réseau.

• Compléter les compétences man-quantes en recrutant par exemple des Product Managers avec une sensibi-lité Product Design si les profils déjà en place ont des compétences plutôt techniques.

• Recruter en rachetant une start-up (acqui-hire) afin d’intégrer d’un seul coup une équipe efficace et spéciali-sée, mais aussi de tirer bénéfice d’un Produit ou une technologie potentiel-lement utile.

La bonne approche est probablement une synthèse des 2 approches : faire progres-ser les personnes clés en interne et les fidéliser mais aussi capitaliser sur l’apport de quelques personnes externes. Les 2 types de profils seront complémentaires et cela limitera la résistance au changement. Il faudra également privilégier les per-sonnes en accord avec les valeurs de votre entreprise, de votre Produit, qui sauront s’adapter et s’intégrer facilement, plutôt que des rock stars ayant des compétences très pointues sur un domaine précis qu’il sera souvent plus difficile d’intégrer et faire progresser.

100

Pour ce qui est des profils à recruter, nous conseillons dans cette phase de recruter des Product Managers de type “Town Planners” tout en gardant les “Settlers” de la phase précédente.

Qu’est-ce qu’un Product Manager “Town Planner” ? Le “Town Planner” est chargé de créer des fonctionnalités couvrant plusieurs lignes de Produit. Ces Product Mana-gers doivent bien comprendre la vision stratégique pour faire des compromis à court et à long terme entre différents Produits.

Il s’agit de Product Managers avec une vision “plateforme” qui vont planifier et imagi-ner l’“usine” qui permettra de supporter la charge et les cas d’usage futurs. Ainsi, ils doivent être capables de synthétiser de grandes quantités d’informations disparates pour construire une technologie qui servira les cas d’usage existants mais égale-ment les initiatives futures que la “plateforme” devra supporter.

COMMENT REPÉRER UN PRODUCT MANAGER DE TYPE “TOWN PLANNER” ?

Quelques questions à poser en entretien de recrutement :• Quelle métrique mesurez-vous pour déterminer le succès d’un Produit

de type plateforme?• Parlez-moi d’une fois où vous avez construit un système qui prend en

charge une variété de cas d’usage.• Comment conciliez-vous la construction de cas d’usage connus et

d’initiatives futures inconnues ?

En plus des Product Managers “Town Planners”, les équipes Produit à ce stade peuvent être complétées par un Program Manager qui porte les projets transverses, assure la synchronisation des équipes et limite les adhérences.

En fonction de vos besoins, vous pouvez également recruter des profils de Data Ana-lysts permettant de décharger les équipes Marketing, les Product Managers ou les Product Owners de la mise en place de tableaux de bord et du pilotage des analytics.


Comment agrandir les équipes ?

Différentes approches existent : la première consiste à créer de nouvelles équipes pour prendre en charge de nouveaux Produits en plus des équipes existantes ; la deuxième consiste à étoffer les équipes existantes en y ajoutant de nouvelles com-pétences telles qu’un Product Designer ou un Data Analyst par exemple, tout en conservant une taille acceptable.

En plus des problématiques de recrutement, la conduite du changement et la fidéli-sation des collaborateurs sera la préoccupation principale du CPO, au risque d’avoir un turn-over conséquent.

Si nous avions un conseil à donner au CPO, ce serait celui-ci : ne créez pas des clones de vous-mêmes ! Le CPO a souvent été Product Manager dans le passé, son rôle n’étant clairement pas de se dédoubler en autant de Product Managers que compte l’organisation. Il s’agit de construire une équipe efficace dont le cadre de prise de décision, les interactions et les processus d’organisation sont clairs (voir chapitre 2 “Comment piloter les objectifs d’une équipe Produit ?“).

Comment donner du sens et créer un sentiment d’apparte-nance ?

Comme pour tout projet, il est important de définir pour chacune des équipes un “mission statement” qui détermine la mission de chacune des équipes Produit. Nous conseillons d’utiliser le modèle suivant dans lequel chaque équipe retrouvera le pourquoi de son Produit, les personnes qui travailleront à accomplir cette mission et le comment.

102

Il est également essentiel de créer un sentiment d’unité et d’appartenance au sein d’une même équipe. Parmi les techniques pour créer de l’unité et de la cohésion au sein des équipes, nous conseillons dans un premier temps et comme élément primordial la co-construction de la roadmap et de la vision Produit. Ainsi, une équipe impliquée dans le processus d’élaboration d’une stratégie et d’une roadmap Produit se sentira toujours plus concernée et aura une idée claire de la direction que prend l’entreprise. Les membres de l’équipe devront participer et être partie prenante des différents ateliers de vision Produit, des tests utilisateurs, des story maps et autres ateliers de priorisation.

Le sentiment d’unité et de cohésion peut également être créé par l’organisation d’événements autour de projets innovants impliquant l’ensemble de l’équipe tels des hackathons et des “team buildings”.

WHY WHAT HOW

La vision Produit de votre équipe Produit

S’agit-il d’une mission pour asseoir une place de leader du marché ? pour gagner des parts de marché ? pour disrupter un marché ?

Exemple du mission sta-tement de l’équipe “Care” de l’application SNCF :

“Nous réduisons le stress des utilisateurs lors des déplacements du quoti-dien et occasionnels en fournissant une infor-mation fiable et au bon moment”

Les ressources

Ayez en tête les principes de base concernant la constitution d’une équipe : Elle doit être à taille humaine pour faciliter les échanges et la discussion (Jeff Bezos recommande des “pizza teams”, soit 8 personnes environ), et pluridisciplinaire afin d’être autonome pour mener à bien la mission qui lui a été confiée.

Les objectifs

Quels sont les objectifs de votre équipe Produit sur les 3 ou 6 mois à venir ?

Quels sont les KPI qui permettront de mesurer l’atteinte de ces objectifs ?

Quelles sont les princi-pales fonctionnalités dans votre roadmap qui y contribueront ?

Exemple pour la même équipe «Care» de l’appli-cation SNCF

« Objectifs : améliorer la fiabilité de l’information voyageurs et accompa-gner les utilisateurs en situation perturbée »


Onboarding

Afin d’intégrer au mieux l’ensemble des nouveaux profils, qu’ils soient arrivés par recrutement ou par acquisition d’une autre entreprise, il ne faudra pas hésiter à rap-peler fréquemment la mission de l’équipe et la vision Produit dans laquelle ils vont s’inscrire. Une fois qu’ils auront intégré le pourquoi de l’équipe et les compétences qui la composent, ils pourront ainsi être responsabilisés et habilités à décider de comment faire grandir leur Produit : fixer leurs propres objectifs, décider des mé-triques à suivre et de leur stratégie Produit au niveau de leur périmètre.

Dans les organisations en Feature Teams (voir chapitre 3 « Comment découper les équipes ?), les guilds et les chapters sont un excellent moyen pour intégrer les nou-veaux membres d’une équipe. Les anciens membres des chapters ou guilds mis en place contribueront à la formation et à la montée en compétence des nouveaux arrivés.

Comment former l’ensemble des équipes Produit ?

Le Product Management est une discipline nouvelle et les niveaux des profils Produit sont assez disparates. Certains ont besoin d’appréhender cette discipline, d’autres de confirmer leurs connaissances et les plus experts de maîtriser les aspects straté-giques, organisationnels et managériaux.

Le framework de formation en Product Management de Thiga repose sur 4 piliers.

Framework de formation de Thiga

PRODUCT MINDSET& SOFT SKILLS

PRODUCT OWNERHARD SKILLS

PRODUCT MANAGERHARD SKILLS

PRODUCT PROCESS & ORGANISATION

104

Soft skillsTech

Design

Data

Growth

Marketing

Strategy

Process & orga

Pilier essentiel, le Product Ownership est le rôle de base du Product Manager. Sa maîtrise sera considérée comme un prérequis pour embrasser le métier de Product Manager.

Reposant sur des fondations solides du Product Ownership, les 3 autres piliers sont constitués de 9 domaines :• la posture et le comportement du Product Manager (soft skills)• les domaines de compétence d’un Product Manager dit «full stack» : Product De-

sign, Data, Growth et / ou Marketing, Strategy• la connaissance des processus et organisations Produit.

Toute initiative de formation des équipes devra : • Soit comporter des éléments relevant de l’ensemble de ces domaines pour ainsi

former des profils transverses.

Soft skillsTech

Design

Data

GrowthMarketing

Strategy

Process & orga

Programme / 2 jours Théorie PM : Design Thinking et Lean StartupMarketing 01: Pitch et UVP Strategy 01: VisionProcess 01 : Storymap, MVP et roadmapDesign 01: Personas & rapid sketchingData 01: L’obsession de la mesureGrowth 01: Smoke tests et introduction au funnelTech 01: EnvironnementsSoft 01 : La posture Produit

Programme / 2 jours Strategy 02 : Business modelsProcess 02 : Advanced roadmapping (RICE), Dual track (Discovery + delivery)Design 02 : Basic wireframing,User testingMarketing 02 : User engagement & messagingData 02 : Product Analytics « cohort analysis »Growth 02 : AB testing efficaceTech 02 : APIsSoft skills 02 : Savoir écouter / Prendre une bonne décision Produit

LEVEL PRODUCT MANAGER

01

LEVEL LEAD PRODUCT MANAGER

02

Lead PM

PM

02

01


Ici, un exemple d’une formation Thiga pour Product Manager et une autre pour Lead Product Manager• Soit venir creuser l’un de ces domaines en particulier pour former des profils de

spécialistes.

Ici, un exemple de formation Thiga pour devenir un Growth Product Manager expert.

Comment gérer les parcours de carrière ?

Le passage à l’échelle d’une organisation Produit a un impact majeur sur la moti-vation des collaborateurs, et sur leur volonté de continuer leur carrière au sein de l’entreprise. Une mise à l’échelle peut donner l’impression aux équipes d’une dilution de leur ownership et de leur responsabilisation. Il n’est, par exemple, pas rare qu’un Product Manager au sein des GAFA s’occupe uniquement d’un bouton like, ce qui peut créer une certaine frustration.

Il faut, dans ces cas-là, réussir à présenter les opportunités de progression en Pro-duct Management que représente une mise à l’échelle. La qualité d’un Product Ma-nager ne se mesure pas à la taille de son périmètre mais plutôt à ses compétences diverses dans le domaine.

PM Growth

PM

Advanced PO

Programme / 2 jours Growth Hacking vs. Growth Marketing vs Growth PMLe mindset GrowthLe processus GrowthAcquisition et promotionOn-boarding et activationConversion et chumViralité et communauté

PRODUCT MANAGERExpert Track

GROWTH

106

Ainsi les mises à l’échelle permettent aux Product Managers de progresser selon 3 axes :• Le premier étant celui de se former aux pratiques du Product Management de bout

en bout, c’est donc l’occasion pour les Product Managers de devenir des Product Managers full stack et de maîtriser l’ensemble du spectre allant de la conception Produit aux techniques de Growth Marketing.

• Le second donne aux Product Managers l’opportunité de changer d’univers Produit régulièrement et de maîtriser ainsi différents sujets fonctionnels. Pour une applica-tion de média, les Product Managers peuvent dans un premier temps progresser sur les problématiques de moteur de recherche, ensuite sur les parcours d’onboar-ding et en dernier lieu sur les problématiques liées aux algorithmes de recomman-dation.

• Il peut être utile dans certains cas, notamment dans les cas de mise à l’échelle conséquentes, de mettre en place du middle management afin de conserver une vraie qualité de management. De notre expérience, un CPO ne peut gérer plus de 5 personnes en direct et est donc obligé de passer à une organisation en râteau avec des Lead Product Managers encadrant des Product Managers. Un des signes avant-coureur de cette nécessité de management intermédiaire est si le CPO passe plus de 40% de son temps à faire des recrutements.

Nous vous recommandons de ne laisser personne de côté lors de la mise à l’échelle de votre organisation mais aussi d’impliquer le plus possible les équipes dans cette refonte organisationnelle. Nous insistons dessus lourdement, ne négligez surtout pas les aspects humains.

Veillez également à avoir des sujets attractifs dans chacune des équipes, afin que tout le monde ne se batte pas pour être dans la squad qui traitera tous les sujets innovants, tandis que personne ne souhaitera être dans la squad qui travaillera sur le pan du Produit qui a la plus grosse dette technique.

Aussi, comme vous planifiez certainement plusieurs recrutements pour ce passage à l’échelle, assurez-vous d’avoir tout de même quelques “historiques” dans chacune des équipes, afin de faciliter l’onboarding des nouvelles recrues.


Conclusion

Passer une organisation à l’échelle peut paraître simple de prime abord, certains CPOs pensant qu’il s’agit uniquement d’une question de budget (“Si le budget est là, le reste suivra”). Pourtant, il est essentiel de recruter les bonnes personnes, d’adap-ter ses recrutements au cycle de vie de son Produit et surtout de penser à un sys-tème cohérent permettant à la fois aux équipes de progresser, de trouver du sens dans ce qu’elles font tout en gérant le parcours de carrière de chacun.

Il est également essentiel de prendre du recul sur votre passage à l’échelle. Si votre organisation passe un temps démesuré à “onboarder” les nouveaux, si votre turno-ver augmente et si les conflits de périmètre se multiplient, il est temps de ralentir la cadence et de penser à réorganiser ou à découper vos équipes différemment.

Aussi, il est fréquent de voir les équipes grossir, les recrutements se multiplier et les Product Managers se faire happer par le quotidien en oubliant de régler les vrais problèmes des utilisateurs et d’alimenter leur roadmap long terme. Il s’agit souvent d’une situation symptomatique d’un mauvais passage à l’échelle du processus de Product Discovery.


The Power of the Elastic Product Team — Airbnb’s First PM on How to Build Your Own : Jonathan Gol-den, premier Product Manager d’Airbnb, décrit comment construire des équipes modulaires, centrées autour d’un besoin, et ayant un fort impact sur le Produit.

Scaling your Product Team: When and How to Start et Scaling Your Product Management Team: When to Go from Lone Wolf to Pack : 2 articles de Uservoice sur quand et comment passer d’une équipe avec un seul Product Manager à une véritable organisation Produit.

Lessons learned from scaling a product team : un retour d’expérience d’Intercom sur le processus qui a été mis en place pour faire passer leur organisation Produit à l’échelle (définir une ligne de conduite et des responsabilités claires, avoir une roadmap simple et transparente et une culture orientée objectifs).

remplacer par : How do you decide who does what - Management 3.0 : une explication détaillée de l’atelier de Delegation Poker évoqué dans ce chapitre.

108

Comment scaler une team technique dans une startup en hyper croissance : Florian Jourda fut le premier ingénieur recruté par Box.com et a vu grandir l’entreprise de 8 employés jusqu’à plus de 1300. Dans ce talk, il expose les meilleures pratiques en matière de scaling technique et organisationnel dans la Silicon Valley.


COMMENT INDUSTRIALISER LE PRODUCT DISCOVERY ?

CHAPITRE 6

110

Les activités de Product Discovery consistent à identifier des besoins utilisateurs, étudier des opportunités de solution Produit et s’assurer que celles-ci soient perti-nentes tant pour l’utilisateur que pour l’entreprise. En tant que CPO ou Lead Product Manager, j’ai le sentiment que ces activités sont réalisées de manière trop spora-dique et peu structurée. Mes équipes mènent des tests utilisateurs de temps en temps et nous avons fait un premier exercice de constitution de personae. Pourtant, les activités de Product Discovery sont cruciales pour la réussite d’un Pro-duit, car elles permettent de limiter les risques pris et de concevoir au plus près des besoins utilisateurs. J’aimerais pouvoir les industrialiser, c’est-à-dire les accom-plir de manière récurrente et à l’échelle dans l’entreprise, pour alimenter plusieurs squads en parallèle.

Nous proposons la création d’une équipe dédiée aux activités de Product Discovery, qui s’appuie sur les différentes squads Produit pour les aider à dérisquer les sujets de long terme.Cette équipe s’appuie sur un certain nombre de méthodes inspirées des mouvances Design Thinking ou Lean Startup, et doit dans l’idéal permettre de limiter au maxi-mum les risques en un minimum de temps sans empiéter sur l’autonomie des diffé-rentes squads.

Solution

Problème


Le domaine du Product Management peut globalement être découpé en 3 grandes activités :• Discover : identifier une opportunité et définir la vision du Produit ou de la fonction-

nalité y répondant• Build : construire et développer le Produit et l’expérience utilisateur associée• Grow : préparer l’organisation à commercialiser le Produit et faire croître la base

utilisateurs via des mécanismes d’acquisition et de rétention

Ces 3 activités sont toutes cruciales à la réussite d’un Produit numérique. Elles sont également cycliques et s’appliquent à tous les niveaux du Produit, c’est-à-dire que chaque fonctionnalité ou release passe normalement par ces 3 phases successives.Pourtant, nous observons que la plupart des organisations sont extrêmement foca-lisées sur le Build, aux dépens parfois des activités Grow et surtout Discover. Le Product Discovery est en effet moins couvert par la littérature existante et complexe à passer à l’échelle, comme on le verra plus loin dans ce chapitre.

Une boîte à outils inspirée du Design Thinking et du Lean Startup

Le Product Discovery est un ensemble d’activités qui consiste à identifier des be-soins utilisateurs ou des opportunités de marché, définir des hypothèses portant soit sur le besoin, soit sur la solution, puis les tester, en amont du développement.

Processus de Product Discovery

Définir le problème et réfléchir aux

solutions

Prioriser les hypothèses

les plus risquées (problème &

solution)

Construire une expérimentation pour tester les

hypothèsesValider ou invalider les hypothèses

Décider entre GO, STOP ou

PIVOT

112

Par exemple, pour le cas d’un Produit de site de rencontre dédié aux sportifs :• Hypothèse Besoin 1 : la pratique d’un sport est un critère important dans les rela-

tions amicales ou amoureuses• Hypothèse Besoin 2 : les solutions existantes sur le marché sont insuffisantes par

rapport à ce cas d’usage donné• Hypothèse Besoin 3 : les sportifs sont spécialement friands de solutions digitales• Hypothèse Solution 1 : les sports pratiqués doivent être mis en avant sur les fiches

personnelles de chaque utilisateur• Hypothèse Solution 2 : le MVP peut se focaliser sur la course à pied car il s’agit du

sport le plus communément pratiqué• etc...

En général, il faut commencer par définir un cas d’usage, une idée exprimée sous forme de besoin utilisateur. Parfois l’idée porte directement sur une solution, auquel cas il est important de se poser la question du “pourquoi ce Produit a-t-il du sens” : quel est le besoin qui se trouve derrière la solution proposée ?Pour matérialiser ce cas d’usage, et toujours dans l’optique d’industrialiser la dé-marche Discover, nous vous suggérons de créer un canevas à remplir. Tout comme un Lean Canvas, ce brief évoluera tout au long de votre processus de conception, et sera progressivement enrichi et amendé pour aboutir au résultat final. Il s’agit égale-ment d’un outil de communication très intéressant en interne pour savoir sur quels sujets chacun travaille et pour avoir rapidement une vue synthétique des projets de moyen-terme de l’entreprise.


NOM dd/mm/yyyy V.0.0

Illustration concept

Entité

Cible utilisateurs Problèmes rencontrés Retours utilisateurs

‣ Nom persona ‣ Critères discriminants ‣ …

‣ Pb 1 ‣ Pb 2 ‣ …

‣ Verbatims ‣ Métriques ‣ …

Hypothèses à tester Valeur attendue

‣ Hp 1 ‣ Hp 2 ‣ …

Pour l’entreprise ‣ ROI ‣ Fidélisation ‣ Acquisition ‣ Cross-sell ‣ …

Avantage compétitif Time-to-market Effort de dérisquage

‣ Produit existant ‣ Partenaire ‣ …

‣ Pertinence lancement ‣ Concurrence ‣ Adhérences /

Dépendances

‣ Estimation coût ‣ Compétences nécessaires ‣ …

Pour les utilisateurs ‣ Bénéfices ‣ Satisfaction ‣ Récurrence d’usage ‣ …

⃞ GO

⃞ NO-GO

Explications : ………………………………………………………………………………………………………………………………………………………………………………………

DÉCISION

Equipe

Le canevas que nous proposons se compose de plusieurs parties, mais n’hésitez pas à ajuster cette fiche en fonction de vos besoins et des spécificités de votre Pro-duit et de votre organisation.

• Cible utilisateurs : en général, le ou les personae concernés par le cas d’usage, ou les critères discriminants qui permettent d’identifier les utilisateurs impactés par ce cas d’usage.

• Problèmes rencontrés : la description du problème utilisateur. Dans un premier temps, vous pouvez remplir cette partie en vous mettant dans la peau de l’utilisa-teur final, de manière théorique ; vous pourrez ensuite challenger et compléter cette description après avoir rencontré de vrais utilisateurs.

• Retours utilisateurs : des verbatims (qualitatifs) ou métriques (quantitatives) qui justifient et prouvent le problème utilisateur.

Canevas associé au cas d’usage

114

• Hypothèses à tester : une liste des principales suppositions que vous avez faites en remplissant le canevas. Cette liste définira les tâches à effectuer pour le pro-cessus de Discover. Il vous faudra les prioriser, en choisissant les plus risquées d’abord (celles qui peuvent faire s’effondrer votre idée si elles se révèlent fausses).

• Valeur attendue : pour l’entreprise comme pour le client. Remplissez-la le plus ob-jectivement possible, cela permettra de prioriser les sujets les uns par rapport aux autres, et de mettre de côté rapidement les sujets à faible valeur ajoutée.

• Avantage compétitif : pourquoi c’est VOUS et vous seul qui pouvez réussir à ré-soudre ce problème utilisateur (matérialiser ce cas d’usage).

• Adhérences & dépendances : d’autres projets en interne qui peuvent impacter ce cas d’usage, ou des équipes qui travaillent sur des sujets similaires.

• Concurrence : qui sont vos principaux concurrents sur ce besoin utilisateur.• Effort de dérisquage : l’effort consenti pour dérisquer ce sujet (temps alloué, res-

sources affectées…).

Maintenant que vous avez un cas d’usage formalisé, l’étape suivante consiste à vali-der ou invalider chacune des hypothèses établies. La première action (et souvent la plus importante) consiste à vérifier que les utilisateurs sont bien conformes à l’idée que vous vous en faites, et que le besoin que vous estimez comme avéré l’est vraiment.

Pour cela, vous devrez probablement mêler recherche qualitative et quantitative. Aller rencontrer des utilisateurs, voire vous immerger dans leur milieu ; éplucher les retours utilisateurs, étudier les analytics.Vous devrez vous appuyer sur cette matière pour creuser le besoin utilisateur, et ainsi mettre à jour vos personae et vos Jobs to Be Done, suivant l’approche que vous préférez.

Une fois que vous aurez validé (et sans doute au passage considérablement appro-fondi) le besoin utilisateur, il est temps de se pencher sur la partie Solutions. Organi-sez un brainstorming en conviant un maximum de profils différents : experts du mar-ché, forces de vente, Product Owners ou Product Managers, développeurs. Si vous aviez déjà en tête des solutions dès le départ, faites l’effort de les mettre de côté pour repartir d’une page blanche ; cela permet d’être plus libéré dans la réflexion, mais il est également probable qu’après avoir travaillé le besoin, la solution initiale s’avère ne plus y répondre tout à fait.


Les solutions proposées peuvent être rédigées sous forme d’epic (par exemple si vous êtes organisés en SAFe, ou en Feature Teams). Toutes ces epics ne seront pas développées au final : dans une logique de MVP, vous allez devoir prioriser les idées qui permettent d’apporter le plus de valeur tout en restant réalisables dans un temps réduit.

Après avoir priorisé une idée répondant au besoin utilisateur, ambitieuse mais fai-sable, et s’appuyant sur les forces de votre entreprise ou votre organisation, nous vous conseillons de prendre un peu de temps pour réfléchir au modèle économique de ce Produit ou cette fonctionnalité. Beaucoup d’entreprises et notamment de start-ups reportent ce moment à plus tard et préfèrent se lancer au plus vite ; cependant, nous considérons qu’il n’y a pas besoin d’investir des semaines d’effort dans un bu-siness plan détaillé pour se faire une première idée. Une rapide étude d’opportunité (à commencer par vérifier que le marché cible est suffisamment important pour que le Produit puisse survivre) peut souvent suffire, et aidera à emporter l’adhésion du management. Anticiper les problématiques de modèle économique permet aussi de faire les bons choix de conception dès le début.

La dernière étape consiste à tester cette idée de solution auprès des utilisateurs. Construisez un prototype, si possible interactif, et testez-le. Si les résultats sont ex-cellents, félicitations, il y a de grandes chances pour que le Produit donne de bons résultats. S’ils sont moyens, prenez en compte les différents retours utilisateurs et revoyez votre copie : affinez la solution, le cas échéant creusez de nouveau le besoin pour voir si vous n’êtes pas passé à côté de quelque chose.Si les tests du prototype sont mauvais, ou que vous n’arrivez pas à emporter l’adhé-sion après plusieurs essais, laissez tomber et passez à une autre idée. Archivez le prototype, qui pourra peut-être resservir plus tard (si le marché se développe ou les besoins utilisateur évoluent).

116

Vous pouvez également découper ce board en 2 parties distinctes, l’une concernant les cas d’usages (et s’arrêtant au stade du brainstorm des solutions), l’autre traitant les epics (et embarquant toutes les phases jusqu’au développement).

Les exemples sont nombreux sur les différents app stores, dans les colonnes des magasines technos ou sur StartupGraveyard : trop de Produits se révèlent des solu-tions à des problèmes qui n’existent pas (rappelez-vous les Google Glass), ou ciblent les mauvais utilisateurs, ou encore ne trouvent jamais leur modèle économique. Bien sûr, aucune méthodologie, aussi sophistiquée soit-elle, ne vous prémunira à 100% contre l’échec ; mais de nombreux problèmes peuvent souvent être anticipés et résolus en quelques semaines de travail bien structuré.

Qui prend en charge la démarche Discover ?

En général, la plupart des entreprises pratiquent le Product Discovery, dans une certaine mesure. La difficulté consiste à industrialiser cette approche au niveau de l’entreprise. Appliquer les méthodologies décrites ci-dessus est à la portée de n’im-porte quelle organisation ; arriver à le faire systématiquement, à bon escient, au bon niveau, et sur l’ensemble des sujets Produit est une tâche plus complexe.

Cas d’usage Epic Solution

Rédaction du canevas

Tests hypothèses problème

Tests hypothèses solution

Brainstorm solutions

Prototypage et tests

Documen-tation solution

Priorisation relative des cas d’usage et des epics

Exemple de kanban pour le processus Product Discovery (un cas d’usage pouvant donner lieu à plusieurs epics / solutions distinctes à tester)


En pratique, les entreprises adoptent souvent 2 options organisationnelles qui sont, à notre sens, tout aussi contre-productives l’une que l’autre.

Le non-choix Dans certains cas, personne ne se saisit réellement du sujet au sein de l’organisa-tion, par peur de l’échec ou résistante culturelle ; en général, on se retrouve dans une logique top down où quelques personnes (souvent le fondateur, ou le CPO) imposent leur loi et se contentent de suivre leur intuition. Certains prennent l’initiative de faire des tests utilisateurs, des prototypes, mais cette démarche se heurte aux urgences et priorités fixées d’en haut. Le résultat est souvent incohérent et ne permet pas de construire un vrai flux tiré de dérisquage.

Le Product Owner multitâche

D’autres entreprises sont conscientes de l’importance de dérisquer un sujet avant de le lancer en conception, et confient cette tâche au Product Owner d’une équipe Scrum. Cela peut fonctionner dans une certaine mesure, surtout si le Product Owner a une appétence pour l’expérience utilisateur et le “Design Thinking”. Mais cela n’est pas optimal et conduit souvent les activités Discover à passer à la trappe. En effet, le Product Owner d’une équipe Scrum jongle entre les urgences et les demandes contradictoires, et il peut avoir tendance à se retrouver le nez dans le guidon, avec la contrainte de préparer ses prochains sprints et de délivrer régulièrement de la valeur pour l’utilisateur ; il n’est pas rare qu’il ait du mal à concilier les 2 temporalités, celle de court terme et celle de long terme. Du coup, le flux de cas d’usage dérisqués ne suffit plus à alimenter les équipes Scrum.

Par ailleurs, le Product Owner et son équipe sont par nature très focalisés sur le Build, avec une orientation “solution” et une propension à construire puis tester après coup.

Quand une démarche de conception ou de Product Discovery est bien mise en place, c’est généralement un coup d’essai en début de projet, pour construire le Minimum Viable Product, après quoi on repasse souvent à un pilotage mélangeant intuition et gestion des urgences.

118

La solution : une équipe dédiée

La solution la plus pertinente, si l’on souhaite que ces activités de “conception Pro-duit” et de Product Discovery soient exécutées de façon appropriée, à l’échelle, et pérenne dans le temps, est selon nous de construire une équipe dédiée.

Cette équipe est constituée de Product Managers, souvent organisés en différents domaines fonctionnels (tribus, dans le cas de Feature Teams). L’idée est de s’ap-puyer sur l’expertise des Product Owners, développeurs ou Product Designers pré-sente dans chaque squad : l’équipe Product Discovery n’impose pas aux équipes de développement des idées “venues d’en haut”, mais les aide en travaillant sur des sujets de long terme qui arriveront in fine dans leur backlog. Elle sollicitera donc volontiers les membres des squads concernées par le sujet étudié, que ce soit pour un brainstorm, une étude de faisabilité, ou un atelier de sketching.

Domaine fonctionnel ou Tribu 1

Domaine fonctionnel ou Tribu 2

Squad

- Product Owner- Devs

- Product Designers

Product Manager+ Product Designer

Product Manager+ Product Designer

Squads

Product Discovery

Squad


- Product Designers

Squad


- Product Designers

Squad


- Product Designers

Mobilisation du Product Owners, des Designers, voire du Lead Dev des équipes concernées

au cours du processus Discover

Exemple d'organisation en Product Discovery


Elle apporte également une couche de transversalité dans l’organisation, en se sai-sissant de sujets impactant potentiellement plusieurs Feature Teams (et encore plus dans le cas d’équipe components).

L’équipe Product Discovery n’a pas non plus le monopole de la méthodologie Disco-ver, et ne coupe pas les différentes squads de leur relation avec les utilisateurs. Tous piochent dans une boîte à outils commune, utilisée par les Product Owners et les Product Designers dans leur squad pour tester et concevoir leurs fonctionnalités ou évolutions de court terme (horizon : quelques sprints), et par l’équipe Product Disco-very pour préparer ce qui arrivera dans le futur.

Aussi, ce qui se met en place ressemble à une double logique de sprint, avec un pro-cessus de Product Discovery (sur un temps plus long) et des squads travaillant sur un temps plus court ; mais les 2 cycles doivent être interconnectés et participatifs, pour éviter de retomber dans du cycle en V déguisé.

Nous suggérons toutefois d’inclure des profils de Product Designers directement au sein de l’équipe Product Discovery ; l’aspect recherche utilisateur et prototypage sont en effet des activités très importantes, et les Product Designers des différentes squads sont souvent trop peu disponibles pour être sollicités sur des sujets de long terme. Par ailleurs, il peut arriver que l’équipe Product Discovery travaille sur des sujets qui ne rentrent (pour l’instant) dans le périmètre d’aucune squad : avoir un Product Designer directement dédié permet de préparer le terrain.

Exemple de processus de Product Discovery en mode sprint

DISC

OVER

YDE

LIVE

RY

>> >

>

> >

>

> >

>

> >

>> >

> > > > > > > >

> > > >>

120

On peut ajouter à ce schéma un troisième cycle : celui de la démarche Growth (voir le Product Academy volume 2 pour en savoir plus), qui vise à expérimenter à haute fré-quence pour améliorer petit à petit le Produit. Cette démarche peut être portée par la squad et son Product Owner, dans le cadre du cycle de delivery ; mais on peut aussi créer un troisième cycle d’expérimentations à haute fréquence, encore plus rapide que le cycle Scrum et porté par un Growth Marketer ou une équipe Growth dédiée.

Combien de temps dure le processus de Product Discovery ?

Par nature, les activités que nous avons décrites ci-dessus peuvent être assez chro-nophages et ne sont jamais techniquement “terminées” : on peut toujours creuser un peu plus le besoin, faire une itération supplémentaire sur un prototype ou relancer une session de tests utilisateurs.

Exemple de processus Discovery, Delivery et Growth imbriqués

DISC

OVER

YDE

LIVE

RY

>

> >

>

> >

>

> >>

> >>

> >

> > > > > > > >

> > > >>

Epics

Expérimentations

Fonction-nalités & User Stories

>

> >

>

> >

>

> >

>

> >

>

> >

>

> >

GROW

TH

>


Pour autant une équipe de Product Discovery ne peut pas se permettre de s’appe-santir pendant des mois sur un ou deux cas d’usage. S’il est difficile de déterminer à l’avance le temps à investir sur un sujet donné, nous vous suggérons tout de même de doser l’effort. Pour cela, 3 critères peuvent être envisagés :

• Le niveau de risque : le risque est essentiellement lié à l’impact de ce sujet sur votre business. Une expérimentation assez facile à développer, sur un sujet annexe à votre business mais potentiellement intéressant présentera peu de risque. La re-fonte de votre parcours de souscription ou le lancement d’un tout nouveau Produit sur lequel vous fondez de grands espoirs sera un projet plus risqué.

• Le niveau d’urgence : quand espérez-vous pouvoir commencer à développer le cas d’usage envisagé ? 1 mois ? 3 ? 6 ?

• Le niveau de connaissance existant sur le sujet : si vous êtes raisonnablement certain de vos hypothèses, que vous disposez de plusieurs études de marché ou de grandes quantités de retours utilisateurs facilement accessibles, vous pouvez vous permettre d’aller plus vite vers les conclusions et les solutions.

Nous vous suggérons de définir 3 “typologies” de cas d’usage, et de dimensionner l’effort en fonction :• les cas d’usage très risqués et exploratoires : vous aurez tendance à investir du

temps et de l’énergie en Product Discover sur ces projets-là• les cas d’usage modérément risqués, sur lesquels vous avez des doutes : fixez une

deadline dans un futur proche pour faire un premier bilan de la phase de discover• les cas d’usage urgents ou très peu risqués : prévoyez un processus plus rapide

(quelques semaines)

Le plus simple consiste à cadencer votre équipe Product Discovery en sprints, comme une équipe Scrum, et d’allouer un certain nombre de sprints de conception à chaque type de projet. Il est parfois difficile d’évaluer en amont le niveau de risque, aussi n’hésitez pas à prévoir pour chaque projet une première semaine d’exploration et d’affiner ensuite éventuellement le niveau d’urgence ou de priorité.

Il peut d’ailleurs être intéressant de mener en parallèle des sujets assez simples à dérisquer mais à fort impact et des sujets stratégiques plus long-termistes.

122

Dans tous les cas, le Product Discovery ne doit pas rentrer dans un niveau de détail trop élevé, au risque de limiter l’efficacité et l’implication des squads qui prendront la suite ; l’idée consiste à dérisquer quelques hypothèses importantes, si besoin au moyen de prototypes, pas de dicter une solution prêt-à-développer à des équipes centrées sur le delivery.

N’oubliez pas que construire soi-même la solution n’est qu’une possibilité parmi d’autres, et pas toujours la meilleure : si le sujet est risqué, complexe, ou potentiel-lement coûteux en développement, la phase de Product Discovery peut aussi ser-vir à identifier des potentiels partenaires techniques voire des cibles de rachat. S’il s’avère qu’un acteur tiers répond parfaitement bien au besoin que vous avez identi-fié, ou qu’un acteur propose une solution en SaaS appropriée, le partenariat peut être une solution économique, au moins le temps de valider l’appétence de votre marché.

Evolution du risque au fil du processus de Product Management (inspiré de Spotify)

Discovery Build it Ship it Tweak itDelivery

Temps

Risque


Do’s and Don’ts

Si ce n’est pas déjà fait, nous vous encourageons à recruter des Product Managers et créer une équipe Product Discovery au sein de votre entreprise. Votre Produit ne pourra s’en porter que mieux. Voici quelques éléments pour vous aider à implémen-ter ce processus dans votre organisation.

Do’s Don’ts

• Procédez par étape : si vous partez de loin, commencez par capitaliser sur les Product Owners et les Product Desi-gners présents dans votre organisa-tion en leur dégageant du temps pour des activités de Product Discovery, en attendant de recruter des Product Ma-nagers qui pourront les aider / suppléer

• Pensez bien les périmètres respectifs de vos Product Managers, afin de mini-miser au maximum les dépendances entre les personnes et les équipes

• Mettez rapidement en place des com-munautés de pratique et des proces-sus communs pour mutualiser l’infor-mation, notamment en matière de recherche utilisateur

• Matérialisez le processus discover et les cas d’usage sous forme d’un kan-ban, en reprenant les principales acti-vités

• Impliquez systématiquement les squads dans les étapes clés de la conception, pour éviter l’effet court-cir-cuitage

• Essayez de donner une cadence à l’ef-fort de conception, via des Sprint Plan-nings et démos par exemple

• N’allez pas trop loin dans la concep-tion au niveau de l’équipe Discovery : une story map suffit ; le reste sera effectué au sein des squads

• Ne coupez pas les squads des utilisa-teurs ; l’équipe Product Discovery n’a pas le monopole de la relation avec l’utilisateur et du feedback

• Ne créez pas une hiérarchie marquée entre Product Manager et Product Owner : les deux se partagent un même périmètre fonctionnel, mais selon des temporalités différentes.

• Ne dépossédez pas le Product Owner de la capacité à identifier, prioriser et développer des sujets d’amélioration continue

• N’oubliez pas la dimension écono-mique dans votre pilotage des sujets Discovery

Evolution du risque au fil du processus de Product Management (inspiré de Spotify)

124


The Rise of Modern Product Discovery : un article de Teresa Torres daté de 2016 sur les activités de Product Discovery.

How to Stop UX Research being a Blocker : un article sur la meilleure façon de concilier recherche UX (un aspect fondamental des activités de Product Discovery) et cycles de développement.

Dual-Track Agile : un article de SVPG (Silicon Valley Product Group) de 2012 introduisant la nécessité d’un double cycle Discovery / Delivery, en mettant en avant la dimension collaborative afin d’éviter la reconstruction de mini-waterfalls.

How Spotify builds products : une illustration du processus de construction Produit chez Spotify et des modes de dérisquage des sujets à moindre coût.

Portfolio Kanban - Scaled Agile Framework : un exemple de kanban dédié aux epics permettant de dérisquer les gros sujets avant de les découper en fonctionnalités.


COMMENT GÉRER LES RETOURS UTILISATEURS À L’ÉCHELLE ?

CHAPITRE 7

126

Je suis CPO d’une organisation Produit qui vient de croître significativement. Je me rends compte qu’il est maintenant beaucoup plus difficile de déterminer qui est res-ponsable de la collecte et de l’analyse des retours utilisateurs. Quand bien même les bonnes personnes sont identifiées, je dois encore m’assurer que l’ensemble des équipes a accès à ces informations afin de valider ou invalider leurs hypothèses Produit ou tout simplement résoudre les principaux bugs.

Nous proposons ici différentes pratiques qu’il est possible de mettre en œuvre pour instaurer une culture orientée satisfaction utilisateur, et garantir une répartition co-hérente des responsabilités en ce qui concerne la collecte, le traitement et la diffu-sion des retours utilisateurs.

Solution

Problème


Commençons par une anecdote que l’on évoque souvent concernant l’importance des retours utilisateurs. Il se raconte dans les couloirs d’Amazon à Seattle que lorsque Jeff Bezos, l’homme le plus riche du monde, assiste à une réunion, une chaise vide est placée parmi les directeurs et autres membres du conseil d’adminis-tration pour représenter le client. L’idée étant de rappeler aux décideurs que le client, bien qu’il ne puisse pas prendre la parole lors de la réunion, reste essentiel et sa voix prioritaire.

Les retours utilisateurs, vous en êtes conscient, sont une source indispensable d’in-formations pour votre Produit. Vous avez certainement de nombreux moyens pour les collecter, mais avouez-le, savez-vous vraiment qui les lit ? Qui les traite ? Sont-ils accessibles à l’ensemble des équipes qui travaillent sur le Produit ? Sont-ils réel-lement intégrés à toutes les étapes de la construction du Produit ? Alimentent-ils régulièrement votre roadmap? N’ayez crainte, les retours utilisateurs sont un peu l’arlésienne des équipes Produit. Tout le monde en parle, chacun est conscient de leur importance, mais bien peu d’équipes les exploitent à leur juste valeur.

Nous vous proposons ici différents dispositifs et méthodes pour remettre réelle-ment les retours utilisateurs au centre de votre démarche Produit, tout en évitant de vous disperser ou d’y perdre énormément d’énergie.

Les différents types de retour utilisateur

Qu’entend-on exactement par retour utilisateur ?

Nous classons habituellement les retours utilisateurs en 2 catégories : les retours quantitatifs et qualitatifs. Chacun de ces types de retours pouvant être sollicité ou non sollicité.

128

Retours quantitatifs

Les retours utilisateurs quantitatifs sont un élément important du développement et de l’amélioration des Produits numériques. Les données quantitatives font appel à notre côté logique, à notre rationalité et au besoin d’avoir des chiffres concrets pour construire des plans d’action. Les retours utilisateurs quantitatifs sont souvent utili-sés pour essayer de découvrir des patterns d’usage ou tout simplement pour étudier ce que les utilisateurs font réellement sur un Produit ou une application de façon objective. Vous saurez par exemple exactement combien de personnes ne scrollent pas sur votre page d’accueil ou à quelle étape ils quittent le processus de souscrip-tion. Toutefois, sans retour qualitatif complémentaire, vous ne pourrez sans doute pas identifier la raison de leur désengagement à ce moment précis.

Les retours quantitatifs peuvent être sollicités, tels que les questionnaires envoyés en masse aux utilisateurs allant de l’étude de marché complète au simple NPS (Net Promoter Score) ; ou non sollicités comme les métriques collectées sur un outil d’analytics ou d’enregistrement de session.

Les retours quantitatifs ayant déjà été largement traités dans “Product Academy 2 - le Guide du Growth” où était évoquée la mise en place d’une équipe Growth dédiée, nous ne nous attarderons pas plus sur ce sujet ici.

Non Sollicité

Sollicité

Remontées spontanées d’utilisateurs (commentaires sur les stores d’applications)

Entretiens, tests utilisateurs

Qualitatif Quantitatif

Entretiens avec collaborateurs

Enquêtes de satisfaction, NPS

Enregis-trement de session, eyetracking

Analytics Produit

Cartographie des retours utilisateurs (non exhaustif)


Retours qualitatifs

A l’inverse, les retours qualitatifs sont utilisés pour mieux comprendre les raisons sous-jacentes au comportement des utilisateurs, leurs opinions et leurs motiva-tions. Ces retours donnent un aperçu des problèmes ou aident à développer des idées ou des hypothèses pour lancer une recherche quantitative ultérieure.

Les retours qualitatifs permettent de comprendre ce qui a incité un utilisateur à choi-sir votre Produit plutôt qu’un autre, les fonctionnalités qu’il trouve essentielles pour l’achat du Produit ou encore les instants de blocage et les points de douleur qu’il rencontre en utilisant votre Produit.

Les retours utilisateurs qualitatifs peuvent être également sollicités ou non sollicités :

• Exemples de retours qualitatifs sollicités :

• Entretiens utilisateurs orientés problème ou solution • Interviews des abandonnistes : entretiens ciblant des utilisateurs partis

à la concurrence ou ayant arrêté l’utilisation du produit, avec pour objec-tif de mieux comprendre la perception de l’écosystème concurrentiel, les promesses des concurrents, les raisons pour lesquelles ces utilisateurs vous ont quitté, et enfin déterminer s’ils étaient dans votre cible ou non

• Dogfooding : utilisation des Produits de l’entreprise par ses propres em-ployés afin qu’ils soient confrontés directement à leurs qualités et leurs défauts. Pour que le dogfooding soit consciencieusement réalisé, il est fréquent de récompenser financièrement les collaborateurs

• Interviews des collaborateurs internes qui ont des contacts fréquents avec l’utilisateur

• Immersion et observation in situ : technique consistant à observer dans son environnement habituel l’utilisation du Produit par de vrais utilisateurs

• Exemples de retours qualitatifs non sollicités : • Retours sur les stores d’applications mobiles (App Store et Play Store) • Commentaires sur les réseaux sociaux • Messages sur des forums ou des chats collectés grâce à des outils tels

qu’Intercom ou User Voice

130

• Remontées des utilisateurs lors de leur navigation sur le Produit avec des outils tels que Usabilla

• Remontées au support client via un outil de support tel que Zendesk • Remontées ou idées des équipes commerciales et Marketing

Ces 2 typologies de retours utilisateurs sont indispensables et s’enrichissent mutuel-lement. Nous utilisons ainsi des outils qualitatifs pour découvrir des problèmes et des outils quantitatifs pour les confirmer ou les infirmer. Mais l’inverse est également vrai, il est fréquent d’avoir recours aux outils quantitatifs pour découvrir des patterns ou des opportunités et de les corroborer ou les creuser avec des outils quantitatifs. Cette bascule de l’un à l’autre est inhérente à la boucle du retour utilisateur. Par exemple, les outils quantitatifs vous aideront à analyser votre entonnoir de conversion, à voir les pages qui convertissent le mieux ainsi que les fonctionnalités qui sont sur ou sous-uti-lisées, alors que les retours qualitatifs vous permettront de creuser les raisons d’aban-don, les problèmes ou les moments d’enchantement vécus par vos utilisateurs sur ce parcours.

LE “DOGFOODING” CHEZ DRIVY

Chez Drivy, les employés sont encouragés à utiliser le service en rece-vant des coupons de réduction de manière récurrente. A chaque utilisa-tion, ils doivent faire un compte-rendu détaillé sous forme de storytel-ling décrivant leur expérience et détaillant chaque étape du parcours client : les moments d’enchantement, points de douleur associés, etc. Cette pratique est également de mise chez Sarenza et Chauffeur Privé.

Attention cependant au biais inhérent à la démarche, car vos salariés ne sont pas forcément représentatifs de la cible de votre Produit et peuvent également manquer d’objectivité.


Pourquoi organiser la collecte, le traitement et la diffusion des retours utilisateurs ?

Vous avez certainement tous en tête la fameuse boucle de feedback Produit théo-risée par Eric Ries dans “The Lean Startup”, qui commence par la découverte des problèmes des utilisateurs et qui se termine par un cycle de livraison, de mesure et d’apprentissage.

Pour construire un bon Produit, il est donc nécessaire de réaliser cette boucle de “Continuous Product discovery” qui alimentera la stratégie de l’ensemble des squads Produit (quel que soit le mode de découpage choisi).

Pour cela, il est nécessaire d’avoir des points de contact réguliers, a minima bi-men-suels, avec les utilisateurs ou clients, pendant lesquels l’équipe Produit va réaliser dif-férentes tâches de recherche utilisateur en lien avec l’un des objectifs du Produit. Le Product Discovery ne doit plus être vu comme une phase, mais comme une activité (au même titre que le Product Delivery) : ces 2 activités se nourrissant l’une de l’autre continuellement (voir chapitre 6 “Comment industrialiser le Product Discovery ?”).

Une autre raison qui plaide pour une organisation de la collecte et l’analyse des retours utilisateurs est le fait qu’en plus de l’équipe Produit, nombreuses sont les équipes en interne, telles que le Marketing ou les Ventes, qui ont besoin d’avoir ac-cès à cette “voix de l’utilisateur” afin de prendre des décisions éclairées pour rédiger leur propositions commerciales, créer du contenu pour alimenter le matériel Marke-ting ou encore pour rédiger les scripts de SAV. Sans analyse et diffusion des retours utilisateurs, ces équipes prennent souvent les mauvaises décisions. Il est fréquent que dans ces cas-là, ce soit l’avis de la personne la mieux payée de l’organisation qui prévale. On parle de HIPPO : Highest Paid Person Opinion.

132

Quelle répartition des rôles et des responsabilités autour des retours utilisateurs ?

L’organisation autour du traitement, de l’analyse puis de la diffusion des retours est donc essentielle pour construire un Produit au plus proche des utilisateurs. Nous avons souvent remarqué que lorsqu’aucune équipe ou personne n’est clairement en charge de ce travail, l’organisation connaît des dysfonctionnements et des tensions. Ainsi, ces organisations peuvent être touchées par :• Un immobilisme au sujet des retours utilisateurs car personne ne se sent respon-

sable de cette mission• Des conflits entre Product Designers et Product Managers car tous 2 se sentent

légitimes pour porter et analyser la voix de l’utilisateur• Des luttes de pouvoir entre commerciaux et Product Managers, surtout dans le cas

des éditeurs de logiciels B2B où la relation client est souvent portée par les équipes commerciales

Comment organiser son équipe afin que ces retours ne s’entassent pas dans un outil de support client tel que Zendesk ou ne restent lettre morte sous forme de comptes-rendus d’interviews abandonnés dans une boîte mail ?

Différentes options organisationnelles existent, nous avons fait le choix de vous pré-senter les exemples les plus inspirants collectés auprès des CPO rencontrés dans le cadre de ce livre. Toutefois, nous pouvons regrouper ces différentes approches en 2 grandes catégories, la première consistant à centraliser l’analyse des retours utilisateurs au sein d’une équipe et la deuxième optant pour des rôles et des respon-sabilités éclatés au sein de toute l’organisation.

Approche 1 : centraliser les retours utilisateurs dans une seule équipe

Cette démarche concerne avant tout les retours non sollicités, qui représentent en gé-néral un volume de données conséquent, surtout dans les entreprises B2C ou B2B2C où l’utilisateur a une forte propension à prendre la parole à propos du Produit. Les


retours sollicités, eux, continuent souvent d’être externalisés à des agences d’études marketing, des cabinets d’études ethnographiques ou encore à des spécialistes des panels.

L’approche centralisée est par exemple mise en place chez la plupart des grands e-commerçants. Chez OUI.sncf (anciennement voyages-sncf.com), la collecte et l’ana-lyse des retours se fait par le biais de la “Love Team” (voir encart). Chez BlaBlaCar, une équipe entière nommée “member voice” est en charge de collecter puis d’aiguiller les retours des utilisateurs vers le bon interlocuteur au sein des équipes Produit.

Ce type d’approche permet une proximité avec les utilisateurs en leur apportant rapide-ment un premier niveau de réponse sans avoir besoin d’attendre une analyse détaillée du problème de la part de l’équipe Produit. L’utilisateur se sent entendu et rassuré sur la prise en compte de son problème. En revanche, ce type d’équipe centralisée autour de la problématique Produit, si elle n’est pas correctement dimensionnée, peut être un réel goulot d’étranglement. Elle ins-taure également une certaine distance entre l’équipe Produit et les utilisateurs, ce qui peut l’empêcher d’aller directement sur le terrain et limiter la capacité de ses membres à comprendre par eux-mêmes les problèmes à résoudre.

LE TRAITEMENT DES RETOURS UTILISATEURS CHEZ OUI.SNCF (EX VOYAGES-SNCF.COM)

Depuis plusieurs années, des équipes sont dédiées au traitement des retours utilisateurs.

• L’équipe “Culture Client” fait le lien entre les différentes équipes qui détectent, analysent et résolvent les anomalies : relation client, sup-port, Feature Teams. L’équipe a également en charge la remontée d’un indicateur de satisfaction global, communiqué tous les mois.

• Les anomalies sont scorées de manière collégiale avec les différentes équipes lors d’une instance hebdomadaire, sur la base de différents indicateurs (business impacté, récurrence / volume d’exposition, impact sur l’image de marque, …). Le score final permettra de définir un niveau de criticité, pour aider à la priorisation dans le backlog des Feature Teams impactées.

134

• L’équipe “excellence opérationnelle” a défini un KPI (le time to resolve, mesurant le temps nécessaire à la résolution d’une anomalie) permet-tant de sensibiliser l’ensemble de l’entreprise à la gestion des anoma-lies grâce à la mise en place de nouveaux processus. Notamment, un reporting hebdomadaire est envoyé aux Feature Teams par l’excel-lence opérationnelle. Ce dernier permet de visualiser les anomalies résolues, les nouvelles, celles en cours et les KPI appropriés.

• La relation client a également lancé “OUI Talk”, un espace d’échange entre les clients et la marque, pour comprendre les besoins des utili-sateurs portant sur les Produits et les services. OUI Talk propose aussi des contenus pour accompagner les clients au mieux dans la compré-hension des outils et des décisions de OUI.sncf.

• Mensuellement, une instance réunit différents interlocuteurs pour partager les indicateurs de satisfaction (calculés par l’équipe “Culture Client”), les anomalies majeures ou irritants clients qui sont ressortis dans l’analyse du mois.

Approche 2 : créer des rôles et des responsabilités diffus au sein de l’organisation

Vous l’aurez deviné, cette approche se situe à l’opposé de la précédente, l’idée étant de diffuser et de distiller les responsabilités liées aux retours utilisateurs dans toute l’organisation.

Celles-ci peuvent être réparties auprès de plusieurs personnes. Par exemple, le Pro-duct Designer peut endosser la responsabilité du traitement des retours liés à des tests d’ergonomie ou des besoins utilisateurs - cette idée permet-elle de résoudre le problème ? -, tandis que le Product Manager va se concentrer sur les retours per-mettant de prioriser la roadmap - le problème adressé est-il suffisamment important pour que cette idée soit priorisée ?

Voici un exemple de répartition des rôles au sein d’une organisation, sous forme de RACI.


LE “SERIAL BUG KILLER” DE CHAUFFEUR PRIVÉ

Chez Chauffeur Privé, un “Serial Bug Killer” à temps plein aiguille les retours utilisateurs en les envoyant à la bonne équipe et en assurant un premier niveau de qualification.

L’application Instabug est utilisée par les salariés sur la version bêta de l’application. Si un bug est détecté, il suffit de secouer son mobile, et d’écrire quelques lignes de contexte. S’il s’agit d’un nouveau bug incon-nu de l’équipe, le salarié gagne un crédit de 5€.

Objectif de la récolte

Product Manager / Product Owner

Product Designer Support client Commerce

Découvrir des problèmes liés à l’utilisabilité

Contributeur Responsable Contributeur Informé

Découvrir des problèmes liés à l’offre com-merciale

Contributeur Informé Contributeur Responsable

Mesurer l’importance du problème

Responsable Contributeur Contributeur Contributeur

Tester des solutions Contributeur Responsable Contributeur Informé

Prioriser la roadmap Responsable Contributeur Contributeur Contributeur

136

Quelle méthodologie pour récolter plus efficacement les retours utilisateurs ?

Organisez le recrutement des utilisateurs

Le recrutement de profils pertinents pour la recherche utilisateur est souvent chro-nophage et complexe. La valeur ajoutée de vos équipes se trouve dans leur capacité à détecter des opportunités et à construire des solutions, non pas à recruter des profils.

Pour collecter des retours utilisateurs à l’échelle sans que vos équipes ne s’es-souflent, plusieurs options sont envisageables :• construire une communauté de “beta-testeurs”, recrutés au sein de votre base utili-

sateurs ou sur des réseaux sociaux que vous pourrez solliciter à la fois pour collec-ter des retours mais aussi pour tester de nouvelles idées. Recruter et animer cette communauté représente un effort, mais évite de repartir à zéro à chaque étude ad hoc.

• utiliser des outils de questionnaires directement intégrés à votre Produit, permet-tant de cibler certains profils qui vous intéressent particulièrement

• travailler avec des solutions SaaS comme Ferpection ou WhatUsersDo, pour réali-ser des tests utilisateurs sur votre site web sur des propositions de maquettes ou des parcours utilisateur

• passer par des agences externes qui vous aideront à recruter ou construire des panels

Quelle que soit l’approche retenue, soyez conscient des biais de la méthode de re-crutement. La technique la moins biaisée consiste sans doute à passer par un spé-cialiste des panels qui vous fournira des échantillons de personnes correspondant aux critères qui vous intéressent ; mais cette approche est coûteuse, et difficile à passer à l’échelle. Réservez-la pour une grande étude annuelle par exemple.

Néanmoins, il vaut mieux aller chercher des retours rapides, même légèrement biaisés, que se passer complètement de retours utilisateurs : si vous travaillez par


exemple pour une banque, et que vous avez un besoin urgent de retours utilisateurs, vous pouvez faire le choix de vous rendre en agence et d’interroger des clients. Gar-dez cependant en tête que cette méthode de collecte privilégiera dans votre échan-tillon un type de client bien particulier (ici : ceux qui se rendent en agence bancaire).

Centralisez les retours utilisateurs

Vous avez collecté une grande quantité de retours et vous vous demandez comment les agréger ? Pour cela, une bonne solution est de résumer chaque retour en une description courte, et d’identifier la ou les fonctionnalités concernées ainsi que le volume d’utilisateurs ayant fait cette demande ou rencontré ce problème. Vous pourrez centraliser ces données dans un tableur partagé (Google Sheets ou autre), la solution la plus simple fera l’affaire. Votre outil de gestion de projet (Trello, Jira,...) ou encore un outil de gestion de roadmap peuvent vous permettre de garder une trace “agrégée” des tendances qui sont remontées.

Si vos problématiques de volumétrie sont très importantes, des outils tels que Via-voo sont spécialisés dans le traitement de retours utilisateurs et peuvent faire cette qualification automatiquement grâce à une analyse sémantique des retours.

Chez SeLoger.com, le sentiment sur l’application mobile est, par exemple, analysé grâce à AppBot. Le Play Store propose depuis peu une analyse sémantique des re-tours et fait ressortir les thématiques les plus récurrentes dans les commentaires.

Avant toute chose, il est important de stocker les différents retours reçus sur diffé-rentes plateformes dans une base documentaire unique, accessible à tous, et utili-sable par tous. Comme évoqué auparavant, différents rôles dans l’entreprise devront accéder à ces éléments pour mener à bien leur mission, il est donc essentiel que l’en-semble des rôles y ait accès et soient formés aux outils. Des outils comme Zendesk, Freshdesk, HelpScout ou Viavoo permettent de mettre en place rapidement des ca-naux de contact entre vous et vos utilisateurs : formulaires, chat, e-mails… La plupart donnent ensuite la possibilité de collaborer sur la qualification et le traitement de ces demandes, afin de déterminer la fonctionnalité impactée et de l’assigner au respon-sable de l’équipe concernée.

138

LA FORMATION DES PRODUCT MANAGERS DE MANOMANO

Les Product Managers de ManoMano doivent maîtriser les outils d’ana-lytics et les requêtes SQL simples leur permettant d’extraire les infor-mations dont ils ont besoin pour analyser les retours utilisateurs. Ils disposent même d’un cursus de formation global comprenant des mo-dules sur le sujet.

Comment diffuser les retours utilisateurs dans l’entreprise ?

La diffusion des retours utilisateurs est un élément clé pour permettre à l’ensemble de l’entreprise une prise de décision éclairée à toutes les étapes du cycle de vie du Produit.

Mais avant de diffuser les retours utilisateurs au reste de l’entreprise, il est néces-saire de les contextualiser en fonction de la cible afin de les rendre digestes. Sinon, votre organisation risque rapidement de crouler sous les notifications automatiques sur Slack ou des centaines de comptes-rendus d’interviews dont on ne sait quoi faire ni comment les actionner.

Restituez vos retours utilisateurs en continu

ll est nécessaire de mettre en place des outils et d’instaurer une gouvernance avec des points de rendez-vous réguliers pour s’assurer que cette activité de restitution est bien menée. Voici quelques outils qui peuvent vous aider à mettre en place cette démarche :

Gouvernance• Intervention de l’équipe Relation Client pour présenter un bilan des retours de la

veille à l’ensemble des Feature Teams avant le Daily Scrum de chaque squad (réu-


nion quotidienne des équipes Scrum). Cette pratique est mise en place au sein des équipes de l’application SNCF par exemple.

• Restitution des bilans des entretiens utilisateurs aux autres membres de l’équipe.

Outils• Envoi des résultats d’enquêtes NPS à toute l’équipe Produit• Mise en place d’une “Feedback river” - fleuve du retour utilisateur - : un channel

slack ou une mailing list proposant un résumé des retours utilisateurs récoltés et analysés au cours de la période (jour, semaine, mois). Il est possible d’automatiser cette récolte à l’aide d’outils dédiés (Zendesk, Appbot, Appfigures, Zapier...). Drivy a, par exemple, créé un channel Slack dans lequel les anomalies remontées par les clients sont automatiquement publiées, ainsi que les avis des utilisateurs sur les stores d’applications.

• Utilisation d’outils d’analyse de sentiment qui font une synthèse automatique des retours utilisateurs. Seloger.com utilise par exemple Hipchat avec un écran pour diffuser en permanence la synthèse des retours à l’ensemble de l’équipe.

• Diffusion d’une synthèse par e-mail avec les éléments saillants des retours utilisa-teurs sollicités et non sollicités, de façon hebdomadaire pour l’équipe Produit et mensuelle pour le reste de l’organisation.

L’ÉQUIPE RELATION CLIENT DE SNCF

L’équipe Relation Client participe au Daily Scrum et fait une synthèse de la journée précédente :

• Nombre de retours clients• Principaux problèmes rencontrés• Suggestions des utilisateurs• Retours positifs des utilisateurs pour motiver l’équipe dès le matin

140

Documentez et réutilisez vos retours utilisateurs pour brainstormer

Afin que les retours utilisateurs ne restent pas lettre morte et qu’ils soient mis à profit de façon régulière dans la conception du Produit, il est nécessaire de les docu-menter et de s’y référer régulièrement.

Les FAQ sont des listes faisant la synthèse des questions posées de manière récur-rente sur un sujet donné, accompagnées des réponses correspondantes, que l’on rédige afin d’éviter que les mêmes questions soient toujours reposées, et d’avoir à y répondre constamment.

Les personae sont vos alliés. Ils sont un bon moyen de documenter grossièrement le profil de vos clients et les problèmes auxquels ils sont confrontés. Il ne faut surtout pas hésiter à les mettre à jour régulièrement et les remettre en question en s’ap-puyant sur les nouveaux retours terrain reçus.

Il est également crucial de bien organiser les retours utilisateurs par thématique, et donc de définir des catégories pertinentes pour votre business et vos équipes. Ainsi, il sera beaucoup plus aisé pour n’importe quelle personne ayant accès à l’outil de centralisation des retours de retrouver l’historique sur un thème précis. Cette caté-gorisation doit être automatisée si les retours sont nombreux, sous peine de forcer vos équipes à passer des journées à “taguer” des tickets Zendesk.

Conclusion

Lorsque l’équipe Produit grandit vite, il est crucial pour vous de maintenir le niveau de proximité que vous aviez avec vos utilisateurs avant ce passage à l’échelle. En fonction de la dimension de votre équipe et du volume de retours à traiter, il convient d’opter pour un dispositif qui permettra de bien qualifier les remontées sans pour autant submerger les équipes.Il vous faudra, ensuite, vous assurer que les retours utilisateurs collectés soient bien diffusés à l’ensemble des personnes interagissant avec le Produit : Product Mana-gers, Product Owners, développeurs, Product Designers, Marketing, commerciaux,


etc. De nombreux outils peuvent vous aider à automatiser ou standardiser cette dif-fusion.

Il est nécessaire de ne pas perdre de vue que les retours utilisateurs sont un moyen d’inspiration parmi d’autres pour les équipes Produit et nullement le seul. Concen-trez vos équipes sur les principaux problèmes rencontrés, maximisez la satisfac-tion utilisateur sans pour autant sanctifier les demandes : les utilisateurs, même internes, ne sont pas forcément les mieux placés pour trouver la meilleure solution !

Une roadmap Produit ne doit en aucun cas être uniquement dictée par les utilisa-teurs, notamment par ceux qui crient le plus fort. N’oublions pas qu’il est impor-tant de croiser ces retours avec des données quantitatives afin de déterminer, par exemple, l’importance d’un problème et le nombre d’utilisateurs impactés. Les sources d’inspiration qui permettent de détecter des opportunités Produit sont nom-breuses, ne se limitent pas aux retours utilisateurs, et doivent toutes être analysées afin de tendre vers l’objectif d’une équipe Produit qui est celui de créer le meilleur Produit possible pour les utilisateurs et pour l’entreprise.


• Designing Your Product’s Continuous Feedback Loop : Sachin Rekhi, CEO de Notejoy, détaille comment identifier les différentes sources de feedback, les synthétiser, les diffuser et les intégrer au processus de création de votre roadmap.

• What Product Managers Forget About User Feedback : Ty Magnin, directeur Marketing chez Appcues, donne quelques bonnes pratiques pour recueillir et analyser les retours utilisateurs.

• Conversations on Customer Feedback : une collection d’anecdotes et conseils de la part de 14 Product Managers sur la mise en place d’une stratégie efficace de gestion des retours utilisateurs.

142

CONCLUSION


En guise de conclusion, nous avons listé les bonnes et mauvaises pratiques recen-sées dans cet ouvrage sous une forme inspirée des célèbres articles de Ben Horowitz (“Good Product Manager / Bad Product Manager”) et Marty Cagan (“Good Product Team / Bad Product Team”). Nous avons classé ces pratiques en 4 catégories : • Les bases d’une bonne organisation Produit• S’approprier la stratégie et fixer des objectifs• Faire du Product Management selon l’état de l’art• Bien recruter et diffuser une culture Produit

Les bases d’une bonne organisation Produit

Les bonnes équipes Produit ont à leur tête un CPO, rapportant directement au CEO et sont en charge de l’ensemble des activités du Product Management : Discover, Build, Grow. Les mauvaises équipes Produit ne sont pas structurées en tant que telles et la res-ponsabilité du Produit et de ses performances est partagée entre plusieurs départe-ments, en fonction des projets en cours.

Les bonnes équipes Produit favorisent la collaboration entre les membres chargés du développement du Produit (développeurs, Product Designers, ...), et rendent possibles des négociations permanentes et constructives. Les mauvaises équipes Produit fonctionnent en silo avec le design et la technique, entretenant une relation client-fournisseur.

Les bonnes équipes Produit sont divisées en pizza teams de 5 à 12 membres. Les mauvaises équipes Produit sont composées de plus de 12 membres et manquent d’efficacité dans leur collaboration.

Les bonnes équipes Produit ont un périmètre pérenne et améliorent en continu ce qu’elles ont développé. Les mauvaises équipes Produit s’assurent de la bonne livrai-son d’un projet, sans suivre l’impact de ce dernier sur les utilisateurs.

144

Les bonnes équipes Produit savent se coordonner entre elles et sont capables de maintenir un parcours utilisateur cohérent de bout en bout. Les mauvaises équipes Produit se considèrent comme des start-ups complètement autonomes et livrent des fonctionnalités sans se soucier des activités de leurs pairs.

S’approprier la stratégie et fixer des objectifs

Les bonnes équipes Produit comprennent la stratégie de l’entreprise et maintiennent une vision Produit fédératrice, en se fixant des objectifs précis et partagés au sein de l’organisation. Les mauvaises équipes Produit sont composées de mercenaires détachés de la mission de l’entreprise, n’ont pas de vision inspirante à partager et se contentent de livrer les projets qui leurs sont demandés.

Les bonnes équipes Produit ont le mandat pour tuer ou transformer en profondeur un Produit si ce dernier ne fonctionne pas. Les mauvaises équipes Produit n’osent pas modifier le Produit de peur de contrarier les parties prenantes.

Les bonnes équipes Produit participent à la construction de leurs objectifs trimes-triels, et sont autonomes sur la manière dont elles souhaitent les atteindre. Les mau-vaises équipes Produit se font micro-manager et font office de passe-plat avec la direction, les parties prenantes ou les clients.

Les bonnes équipes Produit débouchent une bouteille de champagne à la sortie d’un MVP mais se réservent le magnum pour l’atteinte des objectifs business. Les mauvaises équipes Produit se félicitent une fois la release faite, puis passent à autre chose.

Faire du Product Management dans l’état de l’art

Les bonnes équipes Produit échafaudent leur propre stratégie sur la base d’infor-mations hétérogènes synthétisées dans une Product scorecard : indicateurs stra-tégiques, indicateurs d’usage, analyse comportementale des utilisateurs, etc. Les


mauvaises équipes Produit n’ont pas de stratégie ni de scorecard et valident leur roadmap en chambre au cours de réunions avec les parties prenantes.

Les bonnes équipes Produit maintiennent un flux de travail continu et transparent entre Product Discovery et Product Development. Les mauvaises équipes Produit fonctionnent en “boîte noire” et par à-coups en fonction des demandes des parties prenantes.

Les bonnes équipes Produit cherchent à valider leur stratégie via des expérimen-tations fréquentes : leur objectif est d’apprendre autant que possible et le plus vite possible. Les mauvaises équipes Produit exécutent une roadmap validée en amont sans chercher à confronter les certitudes des parties prenantes avec des données provenant du terrain.

Les bonnes équipes Produit sont en contact permanent avec leurs utilisateurs, ce qui leur permet de collecter et diffuser au plus grand nombre des retours qualifiés. Les mauvaises équipes Produit ne parlent pas à leurs utilisateurs et externalisent quelques études par an pour les projets stratégiques.

Bien recruter et diffuser une culture Produit

Les bonnes équipes Produit recrutent leurs membres en premier lieu pour leur capacité à maîtriser plusieurs aspects du Product Management et pour leur adaptabilité. Les mau-vaises équipes Produit basent leurs recrutements sur l’expertise sectorielle uniquement.

Les bonnes équipes Produit sont capables d’adapter leur mode de fonctionnement et leur recrutement en fonction du cycle de vie du Produit. Les mauvaises équipes Produit utilisent un cadre méthodologique défini dans la littérature des organisa-tions sans prendre de recul.

Les bonnes équipes Produit animent des communautés de pratique et se poussent mutuellement à l’excellence par le biais notamment de sessions de partage et de démonstrations. Les mauvaises équipes Produit ne partagent pas leur savoir-faire ni les problématiques auxquelles elles sont confrontées avec leurs pairs.

146

GLOSSAIREAdhérence : Une adhérence est un lien entre deux équipes de nature non bloquante mais conduisant à des incohérences (UX/UI, techniques...) si les deux équipes ne se mettent pas d’accord sur quelques principes communs.

Chapter : Un chapter regroupe des membres de différentes équipes travaillant dans un même domaine ou sur une même technologie (ex : iOS, les APIs, les bases de données…). Comme les guilds, les chapters sont des vecteurs de collaboration, har-monisation et innovation au sein d’une entreprise organisée en Feature Teams.

Component Team : Une Component Team est une équipe structurée selon une logique épousant le découpage technologique du Produit (ex : équipe back-end, équipe web, équipe mobile, équipe sécurité...).

CPO : A la tête du département Produit, le Chief Product Officer (CPO) dirige et struc-ture l’activité de Product Management de l’entreprise. Le CPO est aussi appelé VP Product dans certaines organisations.

Definition of Done : La Definition of Done est un ensemble de critères définis par l’équipe Scrum déterminant si une user story ou par extension tout autre item d'un kanban est considéré comme traité.

Definition of Ready : La Definition of Ready est un ensemble de critères définis par l’équipe Scrum déterminant si une user story est prête à être embarquée dans un sprint.

Delegation Poker : Le Delegation Poker est un jeu créé par Jurgen Appelo ayant pour but de faire appréhender à un groupe que déléguer est un processus progressif, non binaire et dépendant du contexte. Il introduit notamment 7 niveaux de délégation (dire, vendre, consulter, s’entendre, conseiller, enquêter, déléguer).


Dépendance : Une dépendance est un lien entre deux équipes, conduisant l’une des équipes à ne pas pouvoir avancer et livrer de la valeur au client sans que l’autre n’ait terminé son travail (exemple : un développement front-end nécessitant l’enrichisse-ment préalable d’une API).

Dérisquer : Dans le cadre des activités de Product Discovery, dérisquer consiste à identifier les hypothèses les plus risquées liées à une idée Produit et lancer des ex-périmentations rapides et peu coûteuses pour les valider ou les invalider.

Design kit : Un design kit est un ensemble d’éléments de design et directives permet-tant d’assurer une homogénéité de l’expérience utilisateur d’un Produit, particulière-ment utile dans les cas où celui-ci est réalisé par un nombre élevé de développeurs et designers.

Design Thinking : Le Design Thinking est un état d’esprit et une méthodologie per-mettant de faire émerger de idées innovantes résolvant des problèmes complexes. En opposition aux méthodes analytiques “traditionnelles”, le Design Thinking prône l’empathie, l’itération et le prototypage basse fidélité.

Dette Produit : La dette Produit représente le résultat de décisions à visées court-ter-mistes qui se révèlent extrêmement coûteuses à long terme pour votre Produit (en perturbant l’expérience utilisateur, en créant des fonctionnalités difficiles à maintenir ou faire évoluer…).

DevOps : Le DevOps est un état d’esprit et des pratiques visant à améliorer la colla-boration entre les développeurs et les équipes Ops (opérations). Le DevOps renforce la capacité d'une entreprise à livrer des améliorations Produit à un rythme soutenu.

Epic : Une epic (ou « épopée » en français) est un ensemble fonctionnel de grande taille, pouvant être découpé en fonctionnalités elles-mêmes décomposables en user stories. Par exemple :Epic : gérer son panierFonctionnalité : ajouter des articles au panierUser-Story : cliquer sur un bouton sur chaque fiche produit pour l’ajouter au panier

148

Feature Team : Une Feature Team est une équipe pluridisciplinaire et autonome dé-diée à la réalisation d'un ensemble fonctionnel cohérent (une fonctionnalité).

Guild : Une guild est une communauté de membres ayant des intérêts communs et souhaitant partager des bonnes pratiques, outils ou connaissances en lien avec ses intérêts. Elle est en principe constituée de personnes issues de squads différentes et permet de faire le lien entre les équipes et de favoriser leur collaboration.

Impact Team : Une Impact Team est une équipe pluridisciplinaire et autonome dont le but est d’améliorer un indicateur clé du Produit (satisfaction utilisateur, taux de rétention…).

KPI : Un KPI (Key Performance Indicator) est un indicateur permettant de déterminer la performance d’un Produit ou d’une fonctionnalité, dans le but d’aider à la prise de décision et de mesurer le succès.

Jobs to be done : Théorisé par Clayton Christensen (professeur à Harvard), le concept de “jobs to be done” (souvent abrégé JTBD) fait référence à l'objectif pour lequel un client achète ou utilise un Produit, en se focalisant sur une approche “mé-canique” du besoin des utilisateurs (ex : un utilisateur ne veut pas acheter une per-ceuse, il veut avant tout percer un trou).

Lead time : Le lead time définit généralement le temps qui s’écoule entre le début et la fin d’un processus. Dans le cadre de développements, on l’emploie pour désigner le temps nécessaire à une squad pour passer de la collecte d’un besoin à la livraison d’une solution.

Lean Startup : Le Lean Startup est une approche de création de Produits innovants conceptualisée par Eric Ries en 2008, se fondant sur la capacité à répondre de la manière la plus frugale et pertinente possible aux besoins des clients.

Legacy : Le legacy désigne une application ou une portion de code généralement ancienne, ne répondant pas à des pratiques d'ingénierie modernes et difficile à main-tenir ou faire évoluer.


LeSS : Le framework LeSS (Large Scale Scrum) propose un ensemble de pratiques et leviers pour appliquer la méthodologie Scrum à plusieurs équipes travaillant en-semble sur un même Produit.

Microservices : Les microservices caractérisent une architecture logicielle décou-pée en un ensemble de processus unitaires, indépendants et faiblement couplés. Contrairement à une architecture orientée service (acronyme anglais : SOA), l’ap-proche décentralisée des microservices permet de fluidifier les évolutions du Produit et d’améliorer sa résilience et sa maintenabilité.

Minimum Viable Product : Le Minimum Viable Product, aussi appelé MVP, désigne l’ensemble minimal de fonctionnalités répondant aux principaux problèmes de la cible visée.

NPS (Net Promoter Score) : Le NPS est un indicateur permettant de connaître la satisfaction des utilisateurs vis-à-vis d'un Produit en mesurant leur propension à le recommander.

Objectives and Key Results : La méthodologie OKR (Objectives and Key Results) consiste à fixer des objectifs ambitieux et transparents à tous les niveaux de l’entre-prise et pour toutes les équipes, et à opérer leur suivi quotidien grâce aux résultats clés.

Persona : Un persona est une personne fictive représentant un groupe de clients ou d’utilisateurs. Le persona permet de générer de l’empathie avec ses utilisateurs. L’utilisation des personae est une tendance désormais bien établie dans le domaine du développement de Produits numériques afin d’en améliorer notamment l’ergono-mie.

PI Planning : Dans le framework SAFe, le Program Increment (PI) Planning est la cérémonie ayant pour objet de préparer et lancer un PI. Cet événement majeur de l’organisation SAFe dure généralement 2 jours pendant lesquels l’intégralité des par-ties prenantes sont présentes et participent activement.

150

Pizza team : Le concept de pizza team a été théorisé par Amazon pour décrire la taille optimale d’une squad. Pour que celle-ci soit à la fois productive et créative, elle doit idéalement compter entre 5 et 12 membres, soit le nombre de personnes que l'on peut nourrir avec 2 grandes pizzas.

Product Designer : Le Product Designer conçoit le design d'un Produit en intégrant au coeur de sa réflexion les besoins utilisateurs et les enjeux business. Son spectre d'intervention va de la recherche utilisateur jusqu'à la réalisation de maquettes et prototypes détaillés, en passant par de l'animation d'ateliers d'idéation et co-concep-tion.

Product Discovery : Les activités de Product Discovery consistent à identifier des besoins utilisateurs, étudier des opportunités de solution Produit et s’assurer que celles-ci sont pertinentes pour l’utilisateur comme pour l’entreprise. L’objectif est de dérisquer de la manière la moins coûteuse possible les futures epics en s’appuyant sur des méthodologies inspirées du Design Thinking et du Lean Startup.

Product Marketing : Le Product Marketing consiste à construire l’image de marque du Produit, à le faire connaître, en piloter le lancement et fournir au reste de la socié-té les armes pour le commercialiser.

Product Owner : Dans Scrum, le Product Owner désigne un rôle consistant à repré-senter les utilisateurs du Produit auprès de l’équipe de développement. Son objectif est de maximiser la valeur du Produit et de garantir sa qualité. A ce titre, il pilote le backlog et guide la squad dans la réalisation des user stories.

Product Manager : Le Product Manager porte la vision Produit, en déclinant à un niveau plus opérationnel et granulaire les objectifs et la stratégie définis par le CPO. Il pratique la veille Produit, marché ou technologique, pilote une roadmap à moyen-terme et dérisque les futures innovations (Product Discovery).. Il est capable de construire un modèle économique, d’évaluer et prioriser des opportunités business. Enfin, il est souvent chargé de définir et de suivre les principaux KPIs des Produits et fonctionnalités : taux d’utilisation, activation, rétention…Sous certaines conditions, le Product Manager peut endosser le rôle de Product Owner.


Program Board : Le Program Board désigne un outil SAFe de management visuel permettant le suivi et la synchronisation des travaux entre les différentes squads au cours du Program Increment. Il prend la forme d’un tableau matérialisant les items développés par chaque squad ainsi que les dépendances entre ces derniers.

Program Increment : Le Program Increment ou PI est une notion issue du framework SAFe qui désigne une période définie durant laquelle les équipes délivrent un incré-ment Produit. Un PI est classiquement une période de 10 semaines découpées en 4 itérations de développement (qui peuvent s’apparenter à des sprints), suivies d’une itération d’innovation et planification.

SAFe : Le framework SAFe (Scaled Agile Framework) est un ensemble de principes d’organisation facilitant la mise à l'échelle de l'agilité.

Squad : La squad désigne l’équipe de réalisation qui a pour responsabilité le dévelop-pement et l’amélioration continue du Produit ou d’une fonctionnalité de celui-ci. Elle inclut a minima des développeurs et un Product Owner.

User Experience : L’expérience utilisateur (UX) correspond au ressenti de l'utilisa-teur lorsqu’il utilise un Produit. Elle peut être améliorée via de nombreux leviers : optimisation de l'enchaînement des écrans, clarification des principes d'interaction, réduction du temps d'attente...

152 / Parlons des user stories

Remerciement : Marie Aumont, de l’agence Michel & Michel, pour avoir travaillé d’arrache-pied jusqu’à la dernière minute !

153

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

154

Vous souhaitez en savoir plus ?

Nous serons ravis d’échanger autour des organisations Produit avec vous lors d’un Brown Bag Lunch (BBL), n’hésitez pas à nous contacter : [email protected]

table des matiÈres - thiga.fr · par des missions de conseil en stratégie et en organisation...

Documents