Product Management 2.0 : Une histoire de croissance

Les roadmaps produit sont-elles toujours aussi pertinentes ? Comment les product managers devraient-ils prioriser les fonctionnalités ou améliorations? Le product management peut-il apprendre quelque chose du courant growth hacking ?

Cet article est une traduction en français de l'article d'Alex Davis Product Management 2.0: A Growth Story, dont la version originale est lisible sur Medium.

Après 4 ans à faire du growth hacking, j'ai récemment effectué une transition vers un rôle de Product Manager à plein temps en rejoignant les équipes Sync et Accounts de Firefox.  Pour rappel, le concept de "growth" est une combinaison de produit et de marketing ; je me suis logiquement dit : "hey, ça va être un jeu d'enfant."

Les premières galères

Il s'avère que passer de "growth" à produit n'a pas été aussi simple que je l'avais envisagé. La première chose qui m'a posé problème, en tant que PM, a été le concept de la roadmap produit. Je me suis senti l'obligation d'en créer une, vu que... c'est ce que font les product managers, non? Mais s'engager sur un planning de fonctionnalitées pour les 3 prochains mois m'a paru être une énorme contrainte. Comment peut-on être agile avec ça ? Que faire si de nouvelles opportunités se présentent ? Et si on a besoin de faire des améliorations sur quelque chose qu'on vient juste de livrer ? Est-ce que cela retarde toute la roadmap ?Donnerons nous une mauvaise image de l'équipe en matière de fiabilité ? Comment communiquer là-dessus ? Et ce ne sont que quelques unes des questions qui me traversaient l'esprit.

Pour accroître encore plus le poids de notre roadmap, mes deux équipes s'étaient engagées sur un certain nombre d'OKRs (Objectives and Key Results / Objectifs et Résultats Clés) pour le 3ème trimestre. Nos Résultats Clés étaient des fonctionnalités spécifiques et des patch à livrer. Nous n'avions pas d'autre solution que de livrer ce qui était prévu.

KPI

En tant que PM, je me suis rendu compte à quel point on s'enlise facilement dans le besoin de livrer toujours plus de fonctionnalités. Cependant, il est important de se rappeler que chaque fonctionnalités ou patch qu'on livre est supposé impacter un KPI (Indicateur clés de performance). En voici quelques exemples :

• Améliorer votre parcours d'inscription devrait générer plus de nouveaux utilisateurs actifs.
• Un bon onboarding devrait combler l'écart entre les solutions que le produit peut apporter à l'utilisateur et ce que l'utilisateur sait actuellement faire. Une amélioration de l'onboarding se mesure par un taux d'engagement et de rétention accru, ce qui booste le nombre d'utilisateurs actifs.
• Fixer des bugs et des crash peut influencer les KPIs de façons similaires, mais avec différents degrés d'impact.
• Livrer une feature que les utilisateur réclament depuis des mois devrait également être facilement rattachable à un KPI.

Considérant cela, comment peut-on impacter efficacement les KPI si on s'en tient à une roadmap ? Mon expérience de growth hacker m'a appris que la première version de quoi que ce soit a rarement l'effet escompté. Si tout se passait tout le temps comme prévu, je serais devin. Malheureusement, ce n'est qu'à travers des itérations, tests et mesures rapides que l'on peut apprendre et commencer à faire bouger les choses. C'est un concept que le courant Growth Hacking connait et maîtrise depuis des années, dans le sens où la seule supposition qu'ils se risquent à faire est que la plupart de leurs hypothèses échoueront.

Mettons de côté les OKRs, KPIs et autres acronymes business, et parlons plutôt de comment avoir un impact mesurable.

Le processus de croissance

La méthode scientifique

Lorsque je travaillais pour ViraNinjas et SociableLabs, nous avions développé avec mon équipe un processus de croissance (que je trouvais à l'époque révolutionnaire), pour prioriser les développements par impact et documenter au mieux les enseignements tirés. Il s'est avéré que Brian Balfour a mis au point de son côté un processus de croissance similaire, qu'il décrit bien mieux que je n'ai pu le faire dans toutes mes interventions sur le sujet. Je vais me contenter d'essayer de le résumer ici :

Ce processus n'est pas inconnu chez Mozilla. Je l'ai implémenté dans mes deux première semaines au sein de l'équipe "growth" de Firefox et son succès à été tel qu'il a été progressivement adopté par certaines équipes marketing et par une partie des équipes travaillant sur Firefox Android et Firefox Accounts.

Bref, quelle est cette méthode ?

Ce processus aborde les améliorations ou les nouvelles fonctionnalités selon une perspective scientifique. Tout n'est qu'expérimentation avec un groupe de contrôle (une technique souvent appelée "A/B tests").

Je crée un document avec toutes ces informations, avant même de commencer un test, pour clarifier mon objectif. L'équipe "growth" de Firefox appelle ce document une "recette" parce qu'il doit être assez détaillé pour qu'on y retrouve tous les ingrédients nécessaires à quelqu'un qui voudrait reproduire ce test. Les recettes sont conçues pour éliminer toutes les ambiguïtés possibles concernant les résultats, si jamais quelqu'un devait les relire 6 mois plus tard. Elles sont également parfaites pour responsabiliser les équipes. Et le mieux dans tout ça, c'est que les recettes passées sont une des meilleures sources d'inspirations pour créer de nouvelles hypothèses solides.

Priorisation

Avant de créer vos recettes, comment déterminez-vous lequel de vos idées ou problèmes à résoudre aura le plus grand impact ? Chaque idée d'optimisation doit être ajoutée à un backlog priorisé à l'aide d'un score. Ce processus permet de créer un pipeline produit dynamique et en perpétuel changement. Les scores sont déterminés par :

Le trafic (1 mauvais - 5 bon)

Combien d'utilisateurs verront ce changement ? Ce changement est-il caché dans votre page de paramètres, ou bien au contraire visible dès votre page d'accueil ?

L'impact (1 mauvais - 5 bon)

A quel point pensez-vous pouvoir améliorer cette fonctionnalité ou ce parcours ? Si votre taux d'inscription est de 10%, le faire monter jusqu'à 20% représente une amélioration de 100%. Si 80% des utilisateurs complètent déjà une étape du funnel, les faire monter jusqu'à 90% ne représente qu'une amélioration de 12.5%.

Facilité (1 mauvais - 5 bon)

Est-il possible de tester ce changement dans l'heure ? En un jour ? Une semaine ? Un mois?

Indice de confiance (multiplicateur)

Ce facteur a été moins populaire dans le passé, mais c'est selon moi l'un des plus importants. D'où vient votre idée ? Avez-vous formulé votre hypothèse à partir d'observations fiables ? Ou bien venez-vous juste de l'inventer ?

C'est Merritt Aho qui, à l'Opticon 2015, m'a rappelé l'importance d'une hypothèse solide (indice de confiance). Il est parvenu à quantifier quelque chose que je savais, par expérience, être vrai. La probabilité de réussite de votre test dépend de l'origine de votre hypothèse. Il catégorise les produits et idées de tests selon les "sources" suivantes :

• C'est une "bonne pratique dans le milieu" : vous avez 30% de chances d'améliorer un KPI avec votre test/feature.
• Notre concurrent le fait : Vous avez 20% de chances de gagner.
• Notre boss nous dit de le faire : Vous avez 15% de chances de succès.
• On a déjà observé tel ou tel comportement dans nos statistiques, ou au cours de tests utilisateurs : dans ce cas, votre hypothèse a de grandes chances d'être valide et a une chance sur deux d'être confirmée.

Soyons honnêtes, les tests A/B ne sont pas une excuse pour faire n'importe quoi et échouer. On est (tout de même) payés pour réussir ! Appuyez vos idées de fonctionnalités sur des données et des observations solides, pour mettre toutes les chances de votre côté à chaque fois. C'est pour cela que l'indice de confiance est aussi important à mes yeux.

La méthode décrite plus haut est maintenant devenue tellement répandue dans l'industrie que la plateforme de Sean Ellis, GrowthHacker.com a récemment lancé l'outil Projects pour aider les services marketing à l'adopter.

Si vous venez de vous lancer (que ce soit une nouvelle startup, ou un nouveau produit), vous n'avez souvent pas le luxe de posséder une grande quantité de métriques avec lesquelles travailler. Ce qui renforce l'importance de prototyper au plus tôt. Les prototypes vous permettent de collecter des données dès que possible à travers divers métriques et tests utilisateurs.

Ok, il est temps de revenir aux acronymes. Maintenant que nous avons bien mis en évidences la méthode qui permet de générer le plus d'impact, essayons de rattacher tout cela à nos OKR et nos KPIs.

Combiner Product Management et Growth

Si vous êtes arrivés jusque là, c'est ici que les choses intéressantes commencent. Vous en êtes donc au point où j'en suis aujourd'hui avec mes propres équipes produit.

Voici en gros les étapes que je mets en place pour maximiser l'impact du produit (faire progresser mes KPIs) mais également pour tenir mes OKR trimestriels.

1. Définissez et mesurez les KPIs de votre produit et de votre entreprise. Sans des données solides et des métriques de succès bien définies, vous continuerez à livrer des features raccrochées à une roadmap sans considération d'impact.
2. Faites que les résultats clés de vos OKRs soient ... des résultats clés. Vous ne pouvez faire ça qu'une fois que vous aurez défini vos KPI et que vous pourrez les suivre. Ce qui veut dire : ne vous focalisez pas sur des livrables ou des fonctionnalités, concentrez-vous sur l'impact que vous pouvez avoir sur vos KPIs (par exemple : augmenter le taux d'inscription de 10%). Ce point pourrait constituer un article sur les KPIs entier en soi. Mon collègue Responsable Ingénierie, Ryan Kelly, me l'a partagé à la suite de discussions sur comment rendre nos priorités plus orientée data. Cet article a probablement contribué à lancer la machine.
3.  Priorisez vos fonctionnalités à l'aide de scores, de la même façon que vous prioriseriez une idée dans une équipe Growth.
4. Laissez tomber la roadmap, et créez un pipeline de features (i.e : tactiques) à l'aide des scores que vous avez assignés à chaque feature. Travaillez sur les features qui auront le plus d'impact sur l'atteinte de vos résultats clés et par extension de vos objectifs.
5. Créez vos recettes. Considérez ces dernières comme le nouveau format de vos fiches de spécifications. Avec un pipeline, vous saurez pratiquement toujours quels seront les 1 ou 2 prochaines fonctionnalités à implémenter. Commencer à construire votre plan de test à l'aide de la méthode scientifique énoncée plus tôt. (Pour rappel : Observations, hypothèses, métriques de succès, variations, résultats, conclusions, prochaines étapes). Tout cela vous forcera à adopter une approche "data-driven".
6. Traitez chaque feature de la même façon que vous approcheriez un test A/B. Prototypez, mesurez, itérez. Si vous préférez, appelez ça un déploiement progressif.
7. Après chaque test, enregistrez vos résultats et définissez les prochaines étapes à suivre dans votre recette.
8. En prenant appui sur vos résultats, révisez votre pipeline de features. A vous de définir si vous pouvez avoir plus d'impact en itérant sur la même feature ou si vous aurez de meilleures chances avec la tactique suivante (dans votre backlog priorisé). Selon mon expérience, une seule itération n'est généralement pas suffisante pour avoir un réel impact, mais trop d'itérations finissent en général par être une perte de temps.

En conclusion

Boom ! C'en est fini de la roadmap produit traditionnelle ! Longue vie à la pipeline de features ! Ce qui va nous permettre de nous concentrer sur l'amélioration de nos KPIs produit. Et pour ce faire, nous sommes passés d'OKRs orientés sur la livraison de features à des OKRs qui se préoccupent des vrais résultats.
Je suis en train de mettre tout cela en place avec l'équipe Firefox Accounts donc j'essaierai d'écrire un article de blog sur les problèmes que nous rencontrons au fur et à mesure du processus. Je suis sûr que nous allons itérer sur notre methode de la même façon que nous itérons sur nos features.

Quelles sont les limites du pipeline de features ?

Il reste toujours des choses avec lesquelles je me bats. Par exemple, les utilisateurs et les entreprises veulent avoir accès à une roadmap produit. Cela permet à tout le monde de savoir quoi espérer et à quelle date ; ce qui est beaucoup plus difficile avec un pipeline. Je me retrouve à exposer mes objectifs plutôt que mes features qui ont été réduites à l'état de "tactiques". Mais peut-être que les utilisateurs commencent à s'y habituer. La plupart des grands éditeurs d'applications mobiles en sont arrivés à un point où ils n'écrivent même plus de note de release à chaque version. Est-ce que c'est devenu la nouvelle norme ? Est-ce que les objectifs constituent une vision produit suffisamment forte pour contenter les managers ? Qu'en pensez-vous ?
Un autre problème auquel certaines équipes peuvent faire face avec une méthode comme celle-ci est la question des cycles. Si vous travaillez en cycles de release longs (4-6 semaines en nightly build, + 4-6 semaines en Alpha + 4-6 semaines en Beta), votre trimestre sera fini avant même que vous puissiez savoir si vous avez atteint vos résultats clés, et ce sera impossible pour vous d'être en mesure d'itérer rapidement. Si vous voulez faire des changements après la livraison de votre fonctionnalité lorsque vous aurez collecté des données intéressantes, il vous faudra attendre encore 3 mois.
Au-delà des retards infligés à l'itération, je peux concevoir à quel point des KPIs et OKR concentrés sur les résultats peuvent devenir une source de frustration dans le sens où il devient bien plus difficile de les faire progresser. Il vous faudrait presque avoir tout juste du premier coup, et à chaque fois.
Si seulement nous pouvions tous "Aller plus vite" ;)

Article de Alex Davis

Traduction par Marine Roy