ÉTAT DES PRATIQUES PRODUITÉTUDE SUR LES PRATIQUES DU PRODUCT MANAGEMENT EN FRANCEJOSSELIN PERRUS (@MEANINGFOOL.NET)SEPTEMBRE 2016

PARTICIPANTS

JOSSELIN PERRUSJ’ai plus de 5 ans de pratique du Product Management, dans le B2B et B2C. J’ai publié en 2016 une Introduction au Product Management disponible gratuitement sur mon blog ou par email.

http://meaningfool.net :: josselin@meaningfool.net :: 06.15.87.43.99

Pour recevoir l'Introduction au Product Management ou être notifié de mes nouvelles publications, inscrivez-vous à la liste de diffusion :

S'INSCRIRE

3Étude sur les pratiques ProduitJosselin Perrus (@meaningfool.net)

Consulter le site web et les publications

INTRODUCTIONLe Product Management est une discipline encore jeune apparue dans le sillage des méthodes Agile. Le premier article du SVPG (Silicon Valley Product Group), certainement un des pionniers du sujet, date ainsi de janvier 2005.

Cette étude fait suite à la publication d’une Introduction au Product Management, et a pour but de faire un état des lieux des pratiques Produit en France, en espérant que chacun puisse y trouver de l’inspiration pour tester de nouvelles manières de faire.

STRUCTURE DE L'ÉTUDE • Organisation Produit

• Comment sont organisés les pôles Produit ? • Quelle est la différence entre Product Manager et Product Owner ?

• Pilotage Produit • Backlog ? Roadmap ? Comment s’arbitrent les évolutions du Produit ? • Quelles sont les pratiques en termes de Product Discovery ?

• Gouvernance Produit • Comment aligner l’organisation sur les objectifs business ? • Comment mettre en place une véritable culture client ?

MÉTHODELes résultats publiés ont été obtenus à partir d’échanges fondés essentiellement sur des questions ouvertes. Les réponses ont fait l'objet d'un encodage a posteriori.

Les données chiffrées fournies sont à considérer avec les précautions suivantes :

• Elles reposent sur les déclarations des répondants, et sur leur interprétation par l’auteur, ce qui a pu causer des problèmes de classifications.

• L’échantillon interrogé de 34 sociétés n'est pas représentatif du secteur digital ou même des "startup". Les observations faites ici n'ont pas prétention à pouvoir être généralisées. Pour cette raison, les résultats ne sont jamais présentés sous forme de pourcentage mais en valeur absolue.

4Étude sur les pratiques ProduitJosselin Perrus (@meaningfool.net)

S'inscrire à la liste de diffusion

APPARITION DE LA FONCTION PRODUIT

FONCTION PRODUIT OU PAS ?

• 28 des 34 sociétés interrogées ont une fonction Produit, soit sous la forme d'une département Produit dépendant directement de la direction (25 sociétés), soit sous la forme de Product Owner ou Product Manager dépendant d'un autre pôle (pôle technique ou R&D - 3 sociétés).

• Le Produit pré-existe à la création d'une fonction dédiée, et le Product Management n'apparait pas à l'arrivée d'un PM/PO. Il existe toujours une forme de Product Management, dont les responsabilités sont éclatées entre différents pôles (direction, direction technique, autres directions...)

• A l'exception notable d'Algolia (voir encadré en fin d'étude), les sociétés qui n’ont pas de fonction Produit l’expliquent par la taille de l’entreprise qui n'a pas atteint le seuil critique le permettant.

DETTE PRODUIT

• La conséquence possible, mais non nécessaire, de l'absence d'une fonction Produit est l'accumulation d'une "dette produit" qui se révèle à l'apparition de la fonction. 8 des sociétés interrogées se sont trouvées dans cette situation (éventuellement il y a plusieurs mois / années et dont la dette est donc depuis repayée... en totalité ou en partie).

PARTIE 1ORGANISATION PRODUIT

5Étude sur les pratiques ProduitJosselin Perrus (@meaningfool.net)

Obtenir l'Introduction au Product Management

• Cette dette se manifeste par un ou plusieurs des symptômes suivants : des fonctionnalités peu ou pas utilisées, des parcours utilisateurs dysfonctionnels, un modèle de données inadapté, plus généralement une difficulté à accroitre et à délivrer la proposition de valeur, ou encore un déficit méthodologique. (voir à ce sujet l'article Vladimir Oane dans la section Ressources).

• L'apparition de cette dette produit semble liée en partie au profil de l'équipe fondatrice : l'absence d'un cofondateur ayant une forte culture / sensibilité Produit (à distinguer d'une connaissance métier et du secteur d'activité), ou a minima d'un cofondateur technique représente un risque d'un point de vue Produit.

RESSOURCES

• Understanding Product Debt: How To Avoid The Mistake All Product People Make : prenant appui sur la métaphore de Ward Cunningham de dette technique, Vladimir Oane décrit les différents types de dettes Produit et les compromis qu'on peut être amené à faire (car l'absence de dette n'est ni possible, ni souhaitable).

6Étude sur les pratiques ProduitJosselin Perrus (@meaningfool.net)

Recevoir les futures annonces et études

STRUCTURE DE LA FONCTION PRODUITLes réponses des sociétés interrogées font apparaitre 4 grands types de structure pour l'organisation de la fonction Produit. Il s'agit cependant de modèles-types : la réalité des organisations correspond parfois à une forme hybride.

STRUCTURE ORGANIQUE

• L'organisation Produit compte un ou plusieurs Product Manager / Product Owner, et un pool de développeurs. Il n'y a pas de périmètre d'intervention défini.

• Ce type d'organisation correspond à des sociétés qui n'ont pas encore atteint une taille critique justifiant de la création d'équipes.

STRUCTURE ORTHOGONALE

• Les développeurs sont organisés sous forme d'équipes.

• Les périmètres des équipes techniques ne sont pas alignés sur ceux des PM/PO, de sorte que chaque PM/PO est amené à travailler avec plusieurs équipes de développement.

• Par exemple dans une société qui a une équipe Web et un équipe iOS, un PM travaillant sur une fonctionnalité de paiement doit se coordonner avec les deux équipes.

• Ce type de structure se rencontre particulièrement lorsqu'il y a un challenge qui nécessite des compétences difficilement distribuables au sein de plusieurs

7Étude sur les pratiques ProduitJosselin Perrus (@meaningfool.net)

équipes. Par exemple : • Un challenge lié à la Data (récupération, traitement ou intelligence

artificielle). • Un challenge lié à une plateforme comme les plateformes mobiles (voir à ce

sujet l'exemple de La Fourchette).

STRUCTURE ALIGNÉE (EN ÉQUIPES AGILES / FEATURE TEAMS)

• Le Produit est découpé en plusieurs périmètres (par exemple en périmètres fonctionnels), voire en sous-périmètres pour les plus grosses sociétés.

• Chaque périmètre est pris en charge par une équipe qui rassemble toutes les compétences utiles (en particulier PM/PO et développeurs).

• Les PM/PO et les développeurs faisant partie d'une même équipe, leurs périmètres sont nécessairement alignés.

STRUCTURE PAR PROJET

• Des équipes sont formées le temps d'un projet.

• Les équipes de développeurs peuvent être formées de manière permanente, mais être associées à des PM/PO différents au fil des projets.

Gestion des ressources transverses chez LaFourchette

• La Fourchette est organisé selon un modèle hybride : des Feature Team divisées par périmètres fonctionnels, et une équipe en charge de la plateforme Mobile, qui comprend comme les autres un PM et les développeurs mobiles.

• Lorsqu'une Feature Team souhaite passer une évolution sur l'ensemble des plateformes, il lui faut se coordonner avec la Team Mobile, ce qui crée des dépendances entre les backlogs de ces deux équipes.

• Bien que ce soit l'objectif à terme de rendre chaque équipe complètement autonome, les développeurs mobiles ne sont pas encore assez nombreux pour que chaque feature team ait ses propres développeurs mobiles.

• La solution intermédiaire envisagée est de rendre ces développeurs mobiles “volant”, rejoignant chaque équipe au gré des besoins.

• Cette approche par ressources volantes est par ailleurs la solution standard pour les designer dans la plupart des sociétés.

Consulter le site web et les publications

8Étude sur les pratiques ProduitJosselin Perrus (@meaningfool.net)

QUELLES SONT LES LOGIQUES DE DÉCOUPAGE DES PÉRIMÈTRES PRODUIT ?

• La croissance d'une société impose un découpage croissant des équipes et donc des périmètres d'intervention.

• Au sein d'un Produit, de nombreuses logiques se croisent et peuvent chacune constituer un axe de découpage des périmètres :

• Technologie / Compétence : iOS, Android, javascript, ruby,... voire Data • Plateforme : web, mobile, desktop... • Fonctionnel : découpage par grandes fonction de la solution : Recherche,

Réservation, Paiement, Partage,... • Expérience utilisateur : une place de marché a par exemple plusieurs types

d'utilisateurs : buyers / sellers / backoffice. • Mission : chaque lettre des Pirate Metrics AARRR (Acquisition - Activation

- Retention - Revenue - Referral) peut par exemple être identifié à une mission. De son côté Blablacar a organisé ses Tribes autour de missions intitulées Grow, Monetize, Satisfy, Care, Engage.

• Chaque logique de découpage est structurante, car elle s'accompagne d'une logique de "propriété" (ownership), qu'il s'agisse d'une base de code, d'un périmètre fonctionnel, d'une expérience, d'une métrique,...

• Toute logique de découpage, et donc de "propriété" est à double tranchant : • Elle permet d'un côté de clarifier les responsabilités et de favoriser

l'autonomie des équipes.

Réduire les couplages liés à la propriété du code - Voyages-sncf.com

• Voyages-sncf.com est organisé selon un modèle Aligné. Chaque Feature Team est en charge d'un périmètre fonctionnel. Elle est aussi propriétaire de la base de code associée.

• Le problème : certaines évolutions peuvent nécessiter des modifications de code appartenant à une autre équipe (même si cela n'a pas d'impact fonctionnel sur son périmètre), ce qui nécessite de synchroniser les backlogs.

• Voyages-sncf.com expérimente actuellement une logique d'open source interne : chaque module de code a un propriétaire. Tout le monde peut modifier ce code mais seul le propriétaire peut valider l'intégration de ces modifications à la branche principale qui est en production.

S'inscrire à la liste de diffusion

9Étude sur les pratiques ProduitJosselin Perrus (@meaningfool.net)

• De l'autre elle crée des "coutures" entre périmètres et donc des zones d'incertitude pour les initiatives qui se situent à l'interface de deux périmètres ou qui les traversent.

Garantir la cohérence de l'expérience utilisateur - LaFourchette

• La Fourchette sera organisée à terme en Feature Team totalement cross-plateformes.

• Alors, des modifications non coordonnées apportées par différentes équipes pourraient impacter la cohérence de l'expérience utilisateur sur une plateforme particulière.

• Pour faire face à cette difficulté, LaFourchette a fait le choix d'ajouter des “Platform Owner”, propriétaires de l'expérience client chacun sur leur plateforme.

Gérer les superpositions de périmètres - Blablacar

• BlaBlaCar est organisé en Tribes, chacune responsable d'une mission : Trust (en charge de la création de confiance entre les membres), Grow (croissance de la communauté), Monetize, Satisfy, Care et Engage.

• Chaque Tribe a le pouvoir d'agir sur toute la base de code, sur toutes les fonctionnalités, à condition que les projets contribuent à faire avancer sa mission...

• Problème : la fonctionnalité permettant à 2 membres de converser en amont d'une réservation présente un enjeu pour 3 Tribes (Care, Satisfy, Monetize). Les 3 équipes mènent chacune de leur côté des travaux sur ce module en rapport avec leurs missions respectives.

• Pour résoudre d'éventuelles redondances ou incohérences, l'approche choisie a été de se synchroniser plus régulièrement que d'habitude sur ce sujet, sans pour autant regrouper tous ces efforts sous le lead d'une des Tribes.

• Cette solution est à l'essai et sera reconduite suivant qu'elle donne satisfaction ou non. BlaBlaCar assume ouvertement une culture de l'expérimentation, y compris au niveau organisationnel.

Obtenir l'Introduction au Product Management

10Étude sur les pratiques ProduitJosselin Perrus (@meaningfool.net)

RESSOURCES

• How to Organize a Team that Designs End-to-End Experiences : Katie Dill, Head of Experience Design chez Airbnb expose les problèmes rencontrés avec le découpage des équipes.

• Product Manager Zero, Don't Ship the Org Chart - Part 1, Don't Ship the Org Chart - Part 2, 3 articles par Ken Norton, explorant les choix à effectuer avec le recrutement du premier PM et des suivants, les risques potentiels liés à certaines formes de découpage et d'ownership, et le besoin d'innover au niveau de l'organisation pour conserver une capacité à innover au niveau du Produit.

• How Do You Choose the Best Growth Team Model ? : Andrew McInnes présente les résultat d'une étude réalisée avec Daisuke Miyoshi auprès de 20 responsables "Growth", identifiant 2 modèles d'organisation : "Indépendant" et "Fonctionnel".

Recevoir les futures annonces et études

11Étude sur les pratiques ProduitJosselin Perrus (@meaningfool.net)

RESPONSABILITÉS DE LA FONCTION PRODUIT

PRÉPONDÉRANCE DU DELIVERY ET AVÈNEMENT DU DISCOVERY

• Au-delà de leur rôle dans l'arbitrage des évolutions la quasi-totalité des fonctions Produit interrogées sont chargées de piloter les activités de Product Delivery, c'est-à-dire la spécification et l'implémentation des évolutions arbitrées.

• Les activités de Product Discovery (découverte du besoin, et exploration des solutions) sont encore relativement peu présentes, et structurée (voir la section dédiée au Discovery pour plus de détails).

• Cette faiblesse relative du Discovery par rapport au Delivery se traduit notamment dans les profils recrutés en terme de design :

• Essentiellement des designer d'interface (UI designer). • Ou des UX designer orientés vers la création de wireframe et de parcours

utilisateurs. • Mais très peu de designers centrés sur l'exploration du problème.

• Cette situation s'explique : • Par le manque de bande passante chez les PM/PO qui n'ont pas la capacité

à monter sur les activités de Discovery tout en continuant d'assumer le pilotage quotidien des sprints.

• Et probablement par un biais culturel orienté vers la production. L'allocation de ressources aux activités de Discovery demande une évangélisation

Consulter le site web et les publications

12Étude sur les pratiques ProduitJosselin Perrus (@meaningfool.net)

préalable au sein de l'organisation.

• Une proportion importante des organisations interrogées évoque cependant une volonté de monter en puissance sur la dimension Product Discovery.

DISTRIBUTION ET CUSTOMER SUCCESS : QUEL RÔLE POUR LE PRODUIT ?

• La fonction Produit a, par nature, un rôle à jouer dans la Distribution (acquisition de clients) et le Customer Success (satisfaction client).

• Mais la fonction Produit n'a de responsabilité sur ces aspects, éventuellement partagée avec le pôle concerné (Commercial et Marketing pour la Distribution, et Support et Account Management pour le Customer Success), que dans quelques cas (respectivement 8 et 5 sociétés).

• L'interface avec ces autres pôles se fait de l'une des 3 manières suivantes : • Séquentiel : les pôles en charge de la Distribution et du Customer Success

formulent leurs demandes Produit en amont. Ils sont notifiés et formés en aval par le Produit sur les évolutions qui les concernent.

• Association : ces pôles sont aussi associés de manière plus ou moins

Lucca : une logique Produit complètement intégrée

• Chaque Produit Lucca est géré par une équipe Produit dédiée menée par un Product Manager.

• L'équipe Produit est responsable de l'ensemble du cycle de vie du client : acquisition client, onboarding, rétention.

• Des pôles spécialisés (pôle Commercial, Customer Success, et Marketing) existent mais historiquement ce sont des émanations de l'organisation Produit.

• Ces pôles permettent de mutualiser certaines compétences et collaborent étroitement avec les direction Produit dans l'opérationnalisation de leur stratégie.

• Par ailleurs, contrairement à la grande majorité des autres sociétés interrogées, les développeurs travaillant sur les Produits sont hiérarchiquement rattachés à la direction Produit.

• La direction technique a ses propres développeurs, et son rôle est de fournir les briques transverses aux différents produits (login, gestion des rôles,...)

S'inscrire à la liste de diffusion

13Étude sur les pratiques ProduitJosselin Perrus (@meaningfool.net)

étroite lors de la définition et de l'implémentation des évolutions qui les concernent.

• Intégré : le Produit est responsable de la stratégie sur ces problématiques, et s'appuie sur des pôles dédiés pour son opérationnalisation.

Obtenir l'Introduction au Product Management

14Étude sur les pratiques ProduitJosselin Perrus (@meaningfool.net)

PRODUCT MANAGER VS PRODUCT OWNER

QUELLE DIFFERENCE FAITES-VOUS ENTRE LES TERMES PRODUCT OWNER ET PRODUCT MANAGER ?

Aucune différence 8

Le PO s’occupe de la gestion des sprint au quotidien, le PM a une vision plus stratégique (suivant les réponses cela intègre les dimensions business, marché, pilotage,...)

14

Même définition avec les termes PO et PM inversés 2

Le terme PO est associé aux méthodes Agile 12

Product Owner est un rôle, pas un poste 6

Le terme PM est un terme générique 3

Un PO correspond à une organisation à plat alors que le PM a une relation hiérarchique avec l’équipe

2

Le PO est en charge de la livraison de la solution (Delivery), alors que le PM est propriétaire du problème que l’on cherche à résoudre

2

Recevoir les futures annonces et études