Retour à la page d'accueil de meaningfool.net

ETUDE SUR LES PRATIQUES PRODUIT

Télécharger l'étude

Pour recevoir l'étude au format PDF par email, entrez votre adresse ci-dessous :

Vous allez recevoir un email dans quelques instants.
Il semble y avoir un problème avec votre adresse email.

INTRODUCTION

Le 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. Elle a été menée sous forme d'interview auprès de 34 sociétés françaises, dont la liste est consultable en annexe.

STRUCTURE DE L'ÉTUDE

PARTIE 1

ORGANISATION PRODUIT

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).
  • 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

STRUCTURE DE LA FONCTION PRODUIT

Les 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 é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.

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.
  • 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.
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. 
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.
Ressources

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 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.
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,...)

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 é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.

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
Partie 2

PILOTAGE PRODUIT

LES FORMES DE PILOTAGE

FEATURE-CENTRIC

  • L'unité d'arbitrage est la fonctionnalité. Exemples : Ajouter une nouvelle option de paiement, Modifier les filtres dans la recherche.
  • La liste des fonctionnalités à arbitrer est construite à partir des demandes exprimées par les clients, les utilisateurs, les équipes ou la direction.
  • Les arbitrages sont fréquents, renouvelés à chaque sprint. Les features sont priorisées en fonction des objectifs stratégiques.
  • Les items arbitrés sont de granularité relativement faible et l'arbitrage peut amener à en considérer de quelques dizaines à quelques centaines.
  • Le document de pilotage est le backlog qui sert à la fois à la priorisation et au suivi des développements.
  • Ce mode de pilotage est utilisé essentiellement dans des sociétés ayant une fonction Produit jeune ou réduite.

OPPORTUNITY-CENTRIC

  • Les feedbacks et inputs (clients, utilisateurs, marché, concurrents,...) permettent d'identifier des circonstances (marché, partenariats,...) ou des problèmes dont le traitement sont autant d'opportunités.
  • Exemples : "Refonte de l'expérience utilisateur du module de réservation", "Mise en place d'un reporting spécifique pour les utilisateurs de type W", "Automatisation de la tâche X en back-office", "Intégration avec la solution Y".
  • Les Opportunités sont priorisées en fonction de leur contribution aux objectifs de la société et alimentent une roadmap qui planifie sur les 2 à 12 prochains mois (suivant les sociétés) les actions à mettre en oeuvre.
  • Lors des arbitrages, tous les 2 à 3 mois, la roadmap est mise à jour pour intégrer les nouvelles opportunités et l'avancement des actions programmées.
  • Les items arbitrés sont de granularité relativement importante et l'arbitrage peut amener à en considérer d'une dizaine à une cinquantaine
  • Ce mode de pilotage est particulièrement adapté lorsqu'il est nécessaire de pouvoir donner de la visibilité, et prendre des engagements sur les évolutions à venir du Produit.
La Roadmap 3-6-9
  • Certaines sociétés adoptent une roadmap au format 3-6-9 fixe un horizon à 9 mois, remis à jours tous les 3 mois. 
  • Sur les 3 mois à venir le contenu des sprints est défini de manière détaillée. 
  • A 6 mois, le contenu des sprints est connu mais n'est pas encore spécifié. De plus, de nouvelles opportunités sont susceptibles d'apparaitre sur les 3 mois à venir.
  • A 9 mois, ce sont plutôt des orientations qui seront précisées 3 mois plus tard.

OBJECTIVE-CENTRIC

  • Les approches Feature-centric et Opportunity-centric ont une logique bottom-up : une liste d'options est constituée à partir des retours collectés, et passée au filtre des objectifs de la société.
  • L'approche Objective-centric est au contraire top-down et générative : à partir d'un objectif on recherche tous les problèmes qui s'opposent à sa réalisation, et on génère des propositions de solutions - les Initiatives. 
  • Ces Initiatives sont inspirées par la compréhension des utilisateurs et des clients (Insights) issue des feedbacks mais aussi d'actions de recherche (Product Discovery).
  • Les Initiatives sont potentiellement transverses à plusieurs départements. Elles ne sont donc pas centrées exclusivement sur la solution technique, et englobent aussi bien des actions de qualification du problème (Discovery) que de production de solutions (Delivery).
  • Les arbitrages ont lieu tous les 1 à 3 mois. Ils permettent de constater l'atteinte ou non des Objectifs sur la période écoulée, et de prolonger ou renouveller les objectifs sur la période suivante.
  • Exemples d'Objectifs : Augmenter la rétention, Réduire les ressources nécessaires à l'onboarding.
  • En se concentrant sur les objectifs plutôt que sur les moyens, ce mode de pilotage parie sur l'autonomie des équipes qui ont la charge de déterminer les actions à mener pour atteindre leurs objectifs.
  • Un framework formalise cette approche : OKR, pour Objective and Key Results. Les OKR sont utilisés par un grand nombre de sociétés digitales (Google, LinkedIn, Spotify,...) et 2 sociétés du panel ont spontanément déclaré s'en servir. 
Le pilotage par objectifs chez MeilleursAgents
  • Le pilotage chez MeilleursAgents s'articule autour de réunions mensuelles “Point Impact” avec le comité exécutif. 
  • Les Points Impact permettent de fixer quelles sont les métriques à “faire bouger” pour le mois suivant. Il s'agit soit d'une reconduction des objectifs de la période précédente, soit d'un changement de métriques de références.
  • A partir de cette priorisation est construit un “plan Produit” qui priorise les projets à réaliser fonction de leur contribution à l'atteinte des objectifs.
  • Ce Plan produits est complété des projets de fond et d'ordre stratégique.
  • Pour MeilleursAgents, ce mode de pilotage permet d'avoir une visibilité très précise pour 3/4 mois.
Ressources

MATURITÉ DU PRODUCT DISCOVERY

Il n'y a pas aujourd'hui de framework unifié pour rendre compte des différentes pratiques impliquées en phase de Discovery (UX research, Customer Development, User Research,...). 2 dimensions sont ici prises en compte : 

  • Le Customer Discovery comme pratiques de collecte des feedback utilisateurs / clients (Voice of Customers - VoC). 
  • Le Validated Learning comme pratiques de Test & Learn des hypothèses auprès des utilisateurs et clients.
Des PM orientés Problem Discovery - La Ruche Qui Dit Oui
  • La Ruche Qui Dit Oui a une présence online mais des problématiques très offline : logistique, relation avec les producteurs, distribution,...
  • Quel que soit le sujet, le rôle du Product Manager est de s'emparer d'un problème et de le qualifier : du point de vue client (interne ou externe), utilisateur, marché, concurrence.  
  • Il travaille pour cela avec les designer pour mener les entretiens utilisateurs et plus généralement la recherche UX. 
  • Chaque problème est qualifié par des KPI mesurant autant la valeur potentielle pour l'utilisateur que pour l'entreprise et fait l'objet d'une analyse d'opportunité.
  • Le Product Manager progresse ensuite par prototypes successifs vers une solution, dont la réalisation est ensuite confiée à un Product Owner, qui fait le lien avec l'équipe technique, prenant en charge le découpage et le suivi des développements.
  • En aval le Product Manager prend en charge les aspects de roll-out en interne (formation, communication) et en externe.
  • A noter que le profil des Product Manager chez LRQDO est sensiblement différent de celui rencontré dans les autres sociétés, avec un background plus orienté vers les sciences sociales et connaissances agricoles ou logistiques.

CUSTOMER DISCOVERY

Le Customer Discovery désigne donc l'ensemble des pratiques de collecte d'information et d'observations permettant in fine de se construire une représentation des clients, de leurs problèmes, de leur contexte...

La récolte de la Voice of Customers est une étape nécessaire de la construction de ce modèle-client. L'étude permet d'identifier 3 modalités de collecte de la VoC par les PM/PO : 

  • Indirecte : la VoC est collectée au travers de proxy, c'est-à-dire au travers des personnes qui sont par leur fonction en contact avec le client / utilisateurs (les commerciaux, le support, les account manager,...)
  • Opportuniste : la VoC est collectée en direct par le PM/PO, mais de manière ad hoc, en fonction des opportunités. Par exemple via une participation à un rendez-vous commercial.
  • Systématique : la récolte de la VoC en direct est identifiée comme une action nécessaire et importante et des rendez-vous réguliers sont organisés entre PM/PO et clients et utilisateurs.

La collecte de feedback peut par ailleurs être orientée de 2 manières (les 2 approches ne sont pas mutuellement exclusives, mais requièrent des méthodes différentes) : 

  • Orientée Solution : 
  • Le feedback récolté permet de comprendre l'utilisation qui est faite par le client du Produit, ses difficultés, ses frustrations, et ses éventuelles propositions ou idées. 
  • Un mode de collecte Indirect est nécessairement orienté Solution. Ce n'est pas le cas pour le mode Opportuniste et Systématique mais cela représente la majorité des cas chez les sociétés interrogées.
  • Orientée Problème : 
  • Le feedback est récolté de sorte à permettre de comprendre le problème que le client cherche à résoudre, sans se contraindre au cadre fourni par la solution qu'on propose. 
  • Elles ne sont que 2 sociétés à mettre en oeuvre cette approche (dont Prestashop - voir encadré).
Entretiens "ethnographiques" avec les clients chez Prestashop
  • Prestashop propose une plateforme Open Source d'e-commerce, et se rémunère en vendant des modules et thèmes "premium". 
  • Prestashop a une communauté diversifiée : utilisateurs gratuits et clients de modules payants, individuels ayant un store, développeurs, agences,... Pour Prestashop, c'est un enjeu important de comprendre les problèmes de chacun des acteurs de son écosystème.
  • Les Product Manager reçoivent du feedback en interne au travers du Support. Ainsi que de manière opportuniste au travers de différents évènements (meetup, webinar, salons,...) qui rassemblent la communauté.
  • Mais Prestashop va plus loin en menant aussi des entretiens "ethnographiques" régulièrement avec ses clients. Ces entretiens permettent d'explorer les pratiques des clients, leurs problèmes (indépendamment de leur utilisation de Prestashop), leur contexte et les problèmes connexes qui se posent à eux au quotidien.
  • Prestashop y accorde une telle importance que les PM ont un objectif mensuel d'entretiens à effectuer. 
  • Ces entretiens font l'objet de compte-rendus écrits avec leurs principaux enseignements.

VALIDATED LEARNING

Le cycle conception-développement d'un Produit est une somme d'hypothèses faites sur le problème autant que sur la solution à lui donner. Hypothèses qui font l'objet ou non d'une vérification. 

Ces vérifications peuvent avoir lieu à différents stades de ce cycle. Il a été choisi dans l'étude de distinguer 3 phases, par ordre chronnologique inverse : Post-prod, Design, Research.

  • ‍Post-prod :
  • Les tests sont réalisés sur un produit déjà développé : soit en production, soit en version beta. Ces tests sont de 2 types : A/B Testing et User Tests.
  • Les A/B Tests permettent de vérifier qu'une nouvelle solution ne dégrade pas les métriques clés par rapport à l'existant et/ou d'optimiser la solution en testant plusieurs versions.
  • Les User Tests permettent d'identifier des problèmes d'utilisabilité de la solution (donc essentiellement des problèmes d'interface utilisateur - UI).
  • Design : 
  • En phase de Design, les tests sont réalisés sur des prototypes d'interface (mockup ou interface cliquable).
  • L'objet des tests est de valider la forme à donner à la solution avant de la développer. 
  • Les prototypes peuvent être de plus ou moins haute fidélité. Ils permettent d'identifier en amont des problèmes de conception d'interface, mais aussi potentiellement de problème d'expérience utilisateur.
  • Research : 
  • En phase de recherche, le but est de valider des hypothèses relatives au problème client plutôt qu'à la solution à formuler. 
  • Les tests sont réalisés sur des prototypes très early stage, à petite échelle avec un éventuel recours intensif à du travail manuel pour compenser l'absence d'automatisation.
Les pratiques de Research 
Méthode du Concierge MVE (Minimum Viable Experience) - Tinyclues
  • Tinyclues utilise la méthode du Concierge MVE pour tester la proposition de valeur d'un nouveau produit et affiner sa compréhension du problème. 
  • La méthode du Concierge MVE consiste à tester une expérience minimale en impliquant peu ou pas de ressources de développement, quitte à réaliser une partie du service manuellement.
  • L’objectif est de maximiser les enseignements pour le côut le plus faible possible, de quantifier l’opportunité sur une expérience concrète, et au final de minimiser le risque de développer une feature couteuse et inadaptée.
  • Tinyclues a ainsi pu tester l'extension à Facebook des campagnes CRM ciblées de ses clients pour valider ses hypothèses de performance, de coût et de fit client. Ces tests se sont basés sur leur produit existant de ciblage prédictif en créant manuellement des campagnes Facebook pour le compte de ses clients.
  • Une fois les hypothèses validées l'approche pourra être productisée pour offrir une solution d’automation, avec tous les insights nécessaires en terme de feature set, et de pricing.
MVP - Voyages-sncf.com
  • Voyages-sncf.com utilise la méthode du MVP pour valider rapidement ses hypothèses. Contrairement à la technique du Concierge, le MVP est un test qui se déroule “en production”.
  • Ainsi Voyages-sncf.com pour tester la distribution de services de bus dans sa page de réservation a commencé par limiter son MVP à l'affichage de prix dans les résultats de recherche, avec redirection des clients vers les sites des opérateurs de bus pour la réservation.
  • Et lors du chantier de refonte de sa page de réservation, Voyages-sncf.com a commencé par tester son MVP sur l'Aller Simple Paris-Lille uniquement, avec un passager n'ayant pas de carte de réduction, puis étendu le périmètre du MVP à mesure que les hypothèses étaient validées.
  • En gagnant sur le périmètre de développement, Voyages-sncf.com peut tester la pertinence de ses hypothèses business rapidement et à bas coût, avant d’engager des couts supplémentaires pour une intégration profonde.
Ressources

PILOTAGE PAR LES DONNÉES

LIMITES DE L'APPROCHE DATA-DRIVEN 

  • Pour les produits hardware ou on-premise, la collecte de données n'est pas toujours possible.
  • Dans le B2B, avec des utilisateurs/clients en nombres beaucoup plus restreints, le nombre de data points peut être insuffisant pour former des métriques signifiantes.

ÉVALUATION A POSTERIORI DU RÉSULTAT DES ÉVOLUTIONS

  • Les sociétés évaluent toujours de manière qualitative le résultat des évolutions mises en oeuvre. De manière passive (retours enregistrés au support, par les commerciaux,...) et/ou active en interrogeant les utilisateurs et clients.
  • 22 sociétés ajoutent à ce retour qualitatif l'observation des métriques d'usage du produit.
L'obsolescence programmée des évolutions chez OpenClassrooms
  • OpenClassrooms établit, avant l'arbitrage, quelles sont les métriques qui doivent être impactées par une évolution. A titre expérimental, OpenClassrooms fixe une "date de péremption" pour chaque évolution.
  • A cette date, l'évolution sera supprimée, sauf à pouvoir apporter la preuve de son bénéfice.
  • Inverser le comportement par défaut (supprimer plutôt que conserver) constitue une inversion de perspective propre à favoriser une forme de frugalité de la solution.

ESTIMATION A PRIORI DE L'IMPACT DES ÉVOLUTIONS

  • 14 sociétés évaluent en amont des développements l'impact des évolutions envisagées.
  • A minima elles identifient quelles(s) métrique(s) seront impactées par l'évolution.
  • Eventuellement elles estiment l'amplitude de l'amélioration (de manière qualitative - faible / moyenne / forte - ou quantitative, en fixant un chiffre).
  • Les sociétés qui estiment a priori l'impact des évolutions, vont naturellement évaluer le résultat de ces évolutions. Et pas uniquement sur les dimensions d'usage, mais également sur les dimensions business.
  • Ces sociétés vont aussi mettre en oeuvre plus fréquemment de l'A/B Testing : le KPI choisi permet de tester à la fois l'amélioration par rapport à l'existant et la différence entre plusieurs variations de la solution.
Paris sur les résultats d'une évolution chez Blablacar
  • Chez Blablacar, une équipe teste les paris : tous ses membres doivent prédire le résultat d'une évolution selon le KPI de référence.
  • Ces paris permettent en amont de stimuler la réflexion sur les causes de succès / échec d'une évolution.
  • Et a posteriori de questionner les hypothèses implicites qui ont pu conduire à se tromper. Et on imagine aisément que ceux qui se sont trompés auront à coeur de comprendre les causes véritables de leur erreur, et donc les attentes des utilisateurs / clients.

EXPRESSION DES PRIORITÉS

  • L'expression d'objectifs peut se faire de manière littérale, "Améliorer la satisfaction", ou de manière métrée, "Augmenter le taux de rétention à 3 mois de 4 points".
  • Certaines sociétés savent résumer leurs enjeux en une métrique unique de référence :
  • Exemples : Revenu généré pour la société, Economie réalisée pour le client, Revenu supplémentaire généré pour le client.
  • Cette métrique est alors le guide de toute décision : quels sont les choix qui permettent de maximiser cette métrique ?
  • Cependant tous les business et modèles économiques ne se prêtent pas à cette synthèse sous forme d'une métrique unique.
  • Et quand c'est possible, cela demande une grosse capacité de modélisation / analyse, ce qui n'est pas à portée de toutes les sociétés.
  • ‍A défaut d'une métrique unique, certaines sociétés optent pour un ensemble de métriques clés représentant les différents enjeux.
  • Exemples : un taux de conversion, un taux de churn, ou des métriques métier : un taux de documents en erreur, un temps moyen de traitement,...
  • La priorisation des métriques et donc des enjeux permet d'orienter un arbitrage entre plusieurs options même si cela ne fournit pas une relation d'ordre total comme une métrique de référence unique.
Mesurer la valeur créée pour le client chez Tinyclues
  • Le produit de Tinyclues permet d'augmenter le ROI des campagnes marketing de ses clients grâce à des ciblages prédictifs.
  • La proposition de valeur de Tinyclues porte donc sur le revenu incrémental généré pour les clients qui utilisent sa solution.
  • Tinyclues a su modéliser cette création de revenus, et faire du Revenu incrémental une métrique essentielle au pilotage et l'évaluation des actions menées.

COLLECTE D'INSIGHTS

  • Les métriques métiers et les métriques business peuvent être une source de questions fertiles que 8 sociétés les utilisent couramment pour identifier des problèmes et des opportunités.

DATA-DRIVEN CULTURE

  • Les pratiques précédentes participent évidemment à une culture de la décision par la donnée.
  • Mais traditionnellement, le Data Analytics (ou Business Intelligence) est coûteux en termes d'outils et de compétences ce qui en fait un outils réservé aux décisions stratégiques.
  • L'apparition de nouveaux outils sur la collecte, la modélisation et l'analyse de données permet cependant une démocratisation de la donnée et donc son utilisation à des niveaux plus opérationnels pour tester des hypothèses et étayer les micro-décisions quotidiennes.
  • Ainsi dans certaines sociétés le Data Analyst est devenu la 4e compétence clé d'une équipe Agile avec le Développement, le Design et le Product Management.
  • Et dans une société comme Captain Train l'acquisition des compétences d'analyse de données est encouragée pour tous ceux qui peuvent en avoir un usage régulier permettant de réduire le goulot d'étranglement que constitue une seule ressource dédiée.
L'accès direct aux données - Captain Train
  • Chez Captain Train, l'outil de Data Analysis, Dataiku, n'est pas réservé aux Data Analyst. Les employés qui en ont un besoin régulier y ont accès en direct. C'est déjà le cas des Product Manager, mais aussi des Country Manager.
  • Le premier bénéfice pour Captain Train est la réduction de la boucle de feedback. Une question en amène généralement une autre, et s'affranchir des aller-retours avec le Data Analyst ou le département BI permet d'accélérer l'apprentissage.
  • L'utilisation des données n'est cependant pas qu'une question d'accès : elle requiert des capacités d'analyse et une compréhension du modèle de données. 
  • Captain Train propose à ceux qui le souhaitent de devenir autonomes de se former au SQL ainsi qu'aux méthodes d'analyse.
  • Et si l'assimilation du modèle de données a un coût, il représente aussi un levier puissant de compréhension du Produit et de son fonctionnement.
  • Pour Captain Train, l'accès individuel aux données est un vrai facteur d'autonomie mais il reste complémentaire d'une fonction dédiée à l'analyse de données. Par exemple au lancement de l'offre B2B, c'est le Data Analyst qui a été en charge de modéliser le montant des différents abonnements proposés.
Ressources
Partie 3

GOUVERNANCE PRODUIT

Le terme de "gouvernance produit" n'est pas un terme consacré. Il est utilisé ici pour désigner le pilotage, non du produit, mais de l'organisation (humaine) qui fait le produit. 

L'hypothèse ici est que la rapidité, l'agilité et la créativité d'une organisation sont liées au degré de synchronisation, ou autrement dit, d'alignement de ses membres.

Cette 3e partie prend une approche purement descriptive en restituant des pratiques identifiées au cours de l'étude correspondant à 3 axes : 

  • Alignement sur les Objectifs de la société
  • Alignement sur la vision Client et leurs problèmes
  • Alignement sur l'état de la Solution proposée

ALIGNEMENT SUR LES OBJECTIFS

PRODUCT SCORECARD

En ramenant la stratégie à quelques métriques clés (voire une seule dans le cas de la North Star Metric), la Product Scorecard laisse un minimum de place à l'interprétation, et prémunit des objectifs flous ou contradictoires.

AFFICHAGE DES TABLEAUX DE BORD

MeilleursAgents affiche ses tableaux de bord  (sur des écrans dans l'open space). Les fluctuations de ses métriques clés deviennent sources de questions fertiles et de discussions spontanées : Pourquoi le taux de X augmente-t-il alors que la valeur de Y reste constante ? Tu as vu ce pic, qu'est-ce qui s'est passé ce jour-là ?

OKR

Les OKR permettent de décliner les objectifs d'entreprise au niveau des départements puis des individus. Cette filiation claire entre objectifs individuels et objectifs collectifs favorise l'alignement des salariés. 

Les OKR ont par ailleurs une dimension participative : 

  • La déclinaison du niveau collectif au niveau individuel peut se faire en association avec l'individu concerné.
  • Les OKR exprimant les objectifs sous forme de résultats attendus, chacun est amené à définir son propre plan d'action pour les atteindre.

PARTICIPATION AU CHOIX DES OBJECTIFS

Chez La Ruche Qui Dit Oui, les objectifs sont décidés collectivement. Tous les salariés de l'entreprise ont été amenés à se prononcer, lors d'un grand évènement collectif, sur les objectifs de l'année suivante.

La participation à la définition des objectifs permet à chacun en amont de s'approprier les enjeux de la société et, en aval, de mettre du sens dans les actions menées au quotidien.

ALIGNEMENT SUR LES CLIENTS

SESSION DE REPLAY DE USER TESTS

Algolia procède régulièrement à des tests utilisateurs filmés. Et organise des sessions de replay au cours desquelles l'équipe visionne les vidéos. 

Ces sessions, parfois douloureuses mais ludiques, mettent en lumière, de manière non filtrée, les difficultés rencontrées par les utilisateurs, et provoquent des échanges sur les problèmes et solutions à apporter.

ACCÈS DIRECT À LA VOICE OF CUSTOMERS

L'accès direct à la Voix du Client (Voice of Customer - VoC), non filtrée par un proxy, est utile au Product Management mais aux autres fonctions aussi (marketing, design,...). Chez Lucca toutes les fonctions participent occasionnellement à des rendez-vous commerciaux et assistent à des projets de déploiement des solutions. 

Algolia fait du All Hands Support (voir ci-dessous).

PARTICIPATION AUX ACTIONS DE USER RESEARCH

Prestashop mène des actions de User Research sous forme d'entretiens "ethnographiques" pour étudier le contexte des clients et leurs problèmes. 

Ces entretiens font systématiquement l'objet d'un Executive Summary partagé au sein de la société et reprenant les enseignements clés. 

Prestashop envisage par ailleurs d'impliquer d'autres fonctions, notamment les développeurs, dans ces actions de recherche de manière, là encore, à donner un accès non filtré aux insights clients.

ALL HANDS SUPPORT

Pour beaucoup de sociétés le Support est une source importante de feedback. Mais certaines revendiquent le Support comme un des piliers de leur proposition de valeur. 

Pour Algolia, cela se traduit concrètement par une pratique appelée par ailleurs "All Hands Support" qui est mise en oeuvre dans des sociétés telles que Slack, Basecamp, Stripe,...

Cette pratique qui consiste à impliquer l'ensemble des salariés dans l'activité de Support (y compris la direction) : chacun prend au moins un créneau de Support, par exemple 1 demi-journée par mois.

ALIGNEMENT SUR LA SOLUTION

ROADMAP / BACKLOG PUBLIQUE

La roadmap ou le backlog est parfois un document "propriétaire" du Produit et de la direction. Mais certaines sociétés le rendent accessible à tous en interne, en général sous forme d'un board Trello.

Si l'information est disponible il revient toutefois à chacun de faire l'effort de se renseigner. Et la présentation n'est pas contextualisée / personnalisée par rapport aux attentes de celui qui la consulte.

PROCESSUS DE ROLL-OUT INTERNE

La plupart des sociétés recourent aux Release Notes envoyées par email lors des mises en production. Mais elles arrivent tard voire en retard pour les commerciaux ou le support qui peuvent se retrouver pris en défaut face au client ou à l'utilisateur.

Chez Dataiku, le Product Manager a la responsabilité de s'assurer de la bonne compréhension des évolutions Produit par toutes les équipes en amont de leur livraison, au travers de réunions, présentations, démonstrations et sessions de tests au sein des différents pôles.

ÉQUIPES AGILES ÉLARGIES

Les ateliers sont le moyen standard d'associer les autres départements à la définition du besoin. Mais ils restent suspendus à l'initiative du Produit et très localisés dans le temps.

Certaines sociétés vont plus loin en intégrant de manière permanente dans les équipes Agile des membre des autres directions. Par exemple chez Dashlane, le Product Marketing participe à tout le process depuis la conception jusqu'à la livraison des évolutions.

Ressources
Des sociétés pas comme les autres
Algolia
  • Algolia se distingue des autres sociétés interrogées à plusieurs égards. Le premier étant un choix délibéré de ne pas avoir de fonction Produit.
  • La société est constituée en grande partie d'ingénieurs qui sont libres de proposer les projets sur lesquels ils souhaitent travailler, seuls ou à plusieurs. Le seul filtre imposé est celui des objectifs décidés par la direction.
  • La nature du Produit, à destination des développeurs, et l'organisation du Support selon le principe du All-Hands-Support permet aux ingénieurs d'être au contact de manière quotidienne avec leurs clients / utilisateurs.
  • Un UX designer intervient selon les besoins pour aider à définir en amont les KPI de performance de chaque projet et à construire les tableaux de bord. Il intervient aussi sur la réalisation de tests utilisateurs.
  • Ce mode d'organisation émergent s'apparente aux principes de fonctionnement expérimentés par quelques sociétés telles que Valve ou au One-Person-Startup en place chez Angelist.
Lucca
  • Lucca se distingue de son côté par sa logique complètement intégrée autour du Produit (voir encadré plus haut à ce sujet). Mais aussi par 2 autres pratiques dignes d'être signalées.
  • Lucca accorde ainsi une importance particulière à la qualité de ses produits. Et cette qualité est mesurée par l'intensité nécessaire du Support par rapport au chiffre d'affaire généré. Elle se situe aujourd'hui à 2 tickets pour 1000 € de CA, soit moins d'un temps plein pour 3,3 M€ de CA en 2015.
  • Par ailleurs Lucca a mis en place une pratique de gouvernance inattendue : tous les salaires sont connus à l'intérieur de la société, et les salariés ayant plus de 3 ans d'ancienneté peuvent décider eux-mêmes de leur rémunération. 
  • Cette dernière pratique a de toute évidence des conséquences sur l'alignement et la responsabilisation des employés.

LES OUTILS

OUTILS DE GESTION DE ROADMAP / BACKLOG / SPRINT

Le trio vainqueur : la suite Atlassian, Trello, et Git/Github.

Pour l'instant très peu de sociétés ont recours à des applications de gestion de roadmap spécialisés. Certains ont mentionné en avoir essayé mais ne pas avoir été convaincus.

Jira (13), Trello (9), Github (7), Confluence (5), Asana (3), Redmine (2), Google Doc (5), Excel (2), Waffle.io (1), Scrumdo (1), Roadmunk (1), Intercom (1), Git (1), Clubhouse (1), Aha (1)

OUTILS DE TRACKING, ANALYTICS, DASHBOARD

GA (21), Mixpanel (5), Segment (4), Amplitude (4), Kibana (3), Intercom (3), Zendesk (2), Woopra (2), Tableau (2), Grafana (2), Dataiku (2), R (1), Piwik (1), Omniture (1), KissMetrics (1), Insights - New Relic (1), Heap (1), Graphana (1), Geckoboard (1), Fabric (1), Qlik (1), Business Object (1), Biron Analytics (1), Bime (1), Adobe Omniture (1)

OUTILS DE DESIGN D'INTERFACE

Le duo plébiscité est Sketch + Invision. A noter aussi l'utilisation par certains de l'outil Zeplin qui permet de fluidifier le passage de témoin entre équipe design et équipe de développement.

InVision (13), Sketch (12), Photoshop (3), Balsamiq (3), Zeplin (2), Marvel (2), Indesign (2), FramerJS (2), Axure (2), Principle (1), Powerpoint (1), Origami (1), Omnigraffle (1), Moqups (1), Keynote (1)

LES RÉPONDANTS

360Learning Julien Faure
AB Tasty Etienne Jan-Ailleret
Algolia Tim Carry
Lucas Cerdan
Azalead Jean-Yves Simon
Blablacar Rémi Guyot
Botify Nathalie Geoffrin
Captain Train Michel Galibert
Clustree Grégoire Charles
Criteo Vincent Roussilhon
Dashlane Alexis Fogel
Dataiku Kenji Lefevre
Drivy Alexandre Ozga
Etalab Rémi Talès
IKO Systems Pierre Godret
KissKissBankBank Solène Maitre
LaFourchette Anthéa Quenel
Leetchi Matthieu Pozza
Lengow Arthur Bourgeois
Gilles LeGall
Lucca Vincent Porcel
Mailjet Gérald Grosrenaud
Meetic Martin Berthonneau
MeilleursAgents.com Julien Cheyssial
Mention Bruno Correia
Netatmo Romain Paoli
OpenClassrooms Romain Kuzniak
Prestashop Sébastien Levaillant
Qobuz Quentin Leredde
Sketchfab Alban Denoyel
Snips François Pivan
The Food Assembly / La Ruche qui dit Oui ! Vincent Le Roy
François Chay
Tinyclues Olivier Cuzacq
Ulule Alexandre Boucherot
Videdressing Laura Peccia-Galletto
Voyages-sncf.com Yannick Combourieu