PIMP, pour séquencer vos US comme un beau gosse

Une nouvelle méthode pour devenir le Xzibit du Product Management

Vous aimez les anagrammes ? Vous vous sentez tout de suite plus expert quand vous les utilisez ? Vous trouviez d’ailleurs qu’il n’y en avait pas assez ? Et bien je partage votre avis ! C’est pour ça qu’aujourd’hui j’ai décidé de vous en présenter un nouveau. Si tout le monde connaît probablement déjà INVEST, je vous propose de découvrir aujourd’hui une checklist plus simple qui a émergé de ma pratique : PIMP. Quatre lettres qui en reprennent les fondamentaux et les focalisent sur le travail du PO/PM : garantir l’alignement des actions avec la stratégie, exécuter efficacement, maximiser la valeur et mesurer l’impact de ses initiatives.

Bien découper ses US est une compétence clé pour un PO/PM, mais cet aspect de son travail reste à mon sens trop souvent négligé. C’est pourtant un domaine dans lequel des compétences affutées peuvent faire la différence.

On évoque en effet plus souvent le sujet de la priorisation qui semble polariser toute notre attention. Et en filigrane, derrière tous les systèmes de type impact/effort, où l’effort est estimé par l’équipe de développement, on postule implicitement le fait que la complexité d’un projet reste constante. C’est omettre à mon sens de souligner que :

• la partie fonctionnelle peut être challengée pour n’embarquer que ce qui est strictement nécessaire en termes d’efforts
• la complexité croit de manière exponentielle, et que la variance des estimations augmente de pair avec le périmètre d’un projet

Pour prendre une analogie, c’est un peu comme commander une côte de boeuf (désolé pour nos amis végétariens et pour le côté incongru de l’image)

• certes, c’est appétissant, mais si l’on sort du cadre de la pure gourmandise pour se rattacher à celui, plus prosaique, de la survie, on se dit que peut-être on pourrait y ménager plusieurs repas. Et d’ailleurs, avant de penser au repas de demain, peut-être peut-on se concentrer sur le repas d’aujourd’hui. Challenger le périmètre fonctionnel de votre projet revient sensiblement à ça.
• Et en ce qui concerne le découpage, on peut filer la métaphore. Si vous taillez une pièce plus grosse que votre bouche dans votre côte de boeuf, non seulement vous allez vous fatiguer la machoire à force de la mastiquer, mais en plus, à peine votre bouchée passée dans votre gorge, vous risquez l’étouffement. Moins votre projet est découpé et plus il devient indigeste pour votre équipe qui, dès lors, peut déraper.

Un bon découpage d’US, et un bon séquençage du travail permettent donc de minimiser l’effort pour atteindre un impact et de diminuer le time to market de vos fonctionnalités. Maîtriser ces deux compétences garantira une exécution efficace de vos fonctionnalités.

P comme Pareto

Pareto a rendu célèbre le principe selon lequel 20% des causes produisent 80% des résultats. C’était vrai dans son jardin, où 20% des plants produisaient 80% des petits pois. C’est vrai en SEO, où 20% des mots clés (la « short tail ») rapporte 80% du traffic. C’est aussi vrai des tests utilisateurs où 5 utilisateurs suffisent à collecter 80% des retours d’usabilité formulés, nous dit l’éminent Nielsen.

Appliqué au développement de produits digitaux, ce principe revient à dire que 80% de notre impact proviendra de seulement 20% de nos efforts. Intéressant, n’est-ce pas?

Bonne nouvelle pour nous autres Product Managers qui courrons contre la montre. Penser Pareto nous permet de gagner du temps. En effet, à quoi bon s’acharner sur ces 20% de l’impact qui représentent 80% du travail ? N’a-t-on pas mieux à faire? Il ne s’agit donc pas d’être fainéant à dessein, mais d’investir son temps de la manière qui en maximise le rendement.

Penser Pareto, c’est prendre du recul pour filtrer le travail. Trop souvent on se créé des engagements factices par rapport à une vision cible que l’on idéalise. Mais penser Pareto nous rappelle que ce n’est pas parce que cela a été spécifié que cela sera fait. On ne vise pas le parfait, on vise l’efficace.

N’oublions pas le Product Management est un affaire de timing: il s’agit de délivrer le bon produit au bon public, au bon moment afin de maximiser la valeur de notre investissement. En produit comme ailleurs, tout est affaire de contexte, et il y a un coût à ne pas être disponible sur le marché (le cost of delay). En plus de réduire le time to market, si j’économise 80% des efforts, je diminue l’investissement requis. Je rends donc mécaniquement ma fonctionnalité plus intéressante au regard de méthodes de priorisation qui intègrent l’effort (comme impact/effort ou sa variante RICE par exemple)

Un autre intérêt de « penser en mode Pareto » c’est de nous forcer à fixer un objectif. Soit on poursuit 80%: mais 80% de quoi au juste ? Qu’essaie-t-on de faire ? Une fonctionnalité n’est pas une fin en soi, et ce n’est pas parce qu’on livre beaucoup de nouveautés qu’on fait pour autant avancer notre organisation, car le delivery ne garantit pas l’impact.

Aussi, le P de Pareto, c’est aussi le P de Pourquoi. Or, un des mots les plus importants pour un Product Manager, c’est justement ce mot : Pourquoi ?

• Pourquoi cette fonctionnalité ?
• Pourquoi cette fonctionnalité et pas une autre ?
• Pourquoi maintenant ?
• Etc.

La première chose qu’un Product Manager doit faire, c’est se poser cette question. Encore. Et encore. Et c’est pour cette raison que le premier P de cette checklist est le P de « Pareto », et avec lui, de « Pourquoi ». Il y a plusieurs avantages à cela :

• rester ouvert en termes de stratégie : on ne s’attache pas à une solution en particulier pour atteindre la cible. En quelque sorte, peu importe le flacon pourvu qu’on ait l’ivresse. Et avec plus de flèches à notre disposition, on aura plus de chances de faire mouche (pour faciliter l’idéation on pourra penser à des formats de type Impact Mapping, ou sa variante Opportunity Solution Tree de Teresa Torres)
• faciliter la communication : donner le but, le pourquoi d’une initiative permet un autre niveau de compréhension au sein de l’équipe, et lui donne en même temps un cadre pour adapter son travail en cas d’imprévu.
• éviter l’histoire sans fin où l’on itère mais on ne sait plus vraiment pour quelle raison : à trop avoir la tête dans le guidon on est devenu amoureux de sa feature, et on entend la rendre toujours plus belle. Penser Pareto, c’est se concentrer sur le fait de retirer l’essentiel de la fonctionnalité. On ne veut pas en faire la plus belle : mais on veut simplement qu’elle soit suffisamment belle.

I comme itérative

Un voyage de 1000 lieux commence toujours par un pas nous dit Confucius, ce qui le place dans la catégorie des agilistes précurseurs, plus de 2500 ans avant la création du Manifeste Agile. En particulier, la construction d’un produit digital ne devrait pas déroger à la règle et rester itérative.

Pourtant, on a beau opposer projet et produit, se proclamer agile, être initié aux bienfaits des boucles de feedbacks courtes qu’il s’agisse de sprints ou de cycles lean startup (le fameux « build, measure, learn« ), force est de constater que notre attitude vis-à-vis de nos fonctionnalités reste très orientée projet. Nos roadmaps sont souvent des backlogs de projets et non d’impacts. Et dans les faits, on a souvent tendance à livrer des fonctionnalités, pour livrer des fonctionnalités. Et, une fois le lancement passé, à passer à une autre fonctionnalité, comme on passerait à un autre projet.

Pourtant, une fonctionnalité, c’est un comme un petit produit, et en tant que tel, ce n’est jamais vraiment fini. Ce qui compte d’ailleurs, ce n’est pas de penser à la finir, c’est de penser à la finir suffisamment dans un contexte donné.

Et les contextes peuvent être nombreux. Par exemple un contexte business on l’on va chercher à bouger tel indicateur jusqu’à tel niveau. Ou encore un contexte produit dans lequel on va chercher à réduire suffisamment la dette technique ou la dette d’interface pour pouvoir plus facilement construire par dessus dans un second temps. Etc.

Quand on pense itération, on minimise les investissements. Et donc les risques. C’est une aide fondamentale pour le PM. Si la feature est itérative, alors la première version ne sera pas la dernière. On peut donc relativiser sa finition, et se concentrer sur l’essentiel, à savoir éprouver nos hypothèses au moindre coût, qu’elles concernent le problème ou son implémentation.

Oubliez le mythe de la fonctionnalité parfaite. Elle n’existe pas: on pourra toujours faire mieux. Par ailleurs, c’est une illusion de penser qu’on pourra avoir tout juste du premier coup. Livrer c’est apprendre. Il est quasiment certain que les informations que l’on collecte lors d’une phase de recherche amont sont plus incomplètes et moins fiables que tout ce que vous apprendrez à lancer la vraie fonctionnalité avec du vrai code devant des vrais utilisateurs. C’est tout simplement normal d’avoir besoin 3-4 itérations pour atteindre un niveau satisfaisant. En fait, c’est l’inverse qui serait anormal.

Ne sacralisez plus les lancements. Un lancement c’est banal, on en fait tous les jours. Et en plus ce n’est pas une fin en soi puisque votre fonctionnalité va vivre. Certes, si on n’a pas cette culture de l’itération, alors la version initiale restera la version finale: on a donc raison de faire attention à ce qu’on envoie en production. Mais si l’itératif fait partie de votre façon de faire, alors ce que vous envoyez en production ne restera pas 50ans dans le même état.

Ne surspécifiez pas. A quoi bon spécifier 20 tickets, si seulement 4 sont nécessaires pour avoir un premier prototype convaincant? Surtout, si l’on part du principe que ce prototype vous ouvrira les yeux au point de créer de nouveux tickets que vous ne pouviez que difficilement imaginer initialement. Dans ce contexte, surspécifier:

• c’est gâcher son temps, encore plus si vous partagez ces US avec votre équipe qui devra les estimer
• c’est se faire peur, en grossissant arbitrairement le périmètre de travail, et diminuer la prédictibilité, car nos estimations ont plus de variance sur des gros périmètres
• Et c’est aussi créer implicitement un engagement avec du travail qui risque d’être superflu

Aussi, au lieu de chercher à tout maitriser au point de passer 6 mois en recherche (et de faire exploser, soit dit en passant, le coût de votre fonctionnalité), explicitez ce que vous cherchez à apprendre de votre approche et créez une première version « lean ». Lean ne veut pas dire aride, ni même « pourri« : mais maigre. Une version « maigre » contient ce qu’il faut, et uniquement ce qu’il faut, pour atteindre un but fixé. Et sur la base des informations que vous collecterez (est-ce que le design marche, quelle est la meilleure approche pour organiser le code, qu’est-ce l’on apprend des actions des utilisateurs), vous ajusterez le tir.

Et pour minimiser les risques de réputation liés à la livraison d’une fonctionnalité dont l’état de finition laisserait (selon vous) à désirer, les approches sont nombreuses: en production ne signifie pas visible de tous les utilisateurs. Du bon vieux display:none (mon préféré, héhé) au feature flipping, en passant par des canary release, beaucoup d’outils existent pour déployer une fonctionnalité et ne la rendre accessible qu’à un public restreint.

C’est bien beau me direz-vous, mais comment on fait ?

Et bien, découpez ! Encore, et encore. Devenez pour vos US ce que les couteaux japonais de précision sont au poisson cru.

Il n’y a pas de recette uniques pour bien découper ses US, et la pratique joue un rôle important et créera des réflexes. Si le Story Map reste un grand classique pour mettre le pied à l’étrier et séquencer un projet de manière macro, les deux conseils que je trouve le plus utiles pour descendre à une granularité plus fine, c’est de :

• bien garder en tête la métaphore du Hamburger, utile pour nous rappeler comment livrer des vrais incréments de valeur à chaque bouchée
• et de faire plusieurs découpages à la suite, pour chercher à rendre toujours plus fines vos itérations

Pour le reste, une approche type SPIDR, imaginée par Mike Cohn, pourra vous donner quelques pistes pour comprendre comme, en fonction de votre contexte, vous pourriez découper vos US.

M comme mesurée

« Ce qui ne se mesure pas ne se gère pas« , nous dit Peter Drucker. Or le PM gère un produit, n’est-ce pas ?

On a beau critiquer la culture de l’usine à fonctionnalités (la fameuse « feature factory« ), elle ne sort pourtant pas de nulle part. Piloter ses initiatives par l’impact requiert, dans l’organisation, une maturité des pratiques autour de la donnée: des indicateurs sont clairement définis, avec des définitions partagées, des données accessibles facilement, idéalement non disséminées dans une multitude d’outils, les personnes sont formées et autonomes…

Mais cette maturité idéale fait encore souvent défaut: sur le terrain on constate des équipes avec des indicateurs peu actionnables et peu prédictifs du succès de leurs utilisateurs, des plans de marquage incomplets, des Performance Analysts partagés entre les équipes, avec une faible connaissance des problématiques des utilisateurs du produit sur leur périmètre (donc un oeil trop générique pour lire la donnée), des pans entiers de données difficilement accessibles aux équipes produits et qui restent principalement aux mains de la finance ou du marketing…

Aussi, il est compréhensible que nombre de PMs auxquels on demande d’être data-driven se mettent à mesurer la vélocité de leur équipe ou le nombre de fonctionnalités livrées : même si ça n’a en définitive que peu de sens, cela reste en effet souvent la méthode de suivi la plus accessible.

Pourtant:

1. comment identifier les problèmes qui méritent que l’on investisse dans leur résolution si on n’a pas de système de suivi qui nous permette de comprendre l’utilisation de notre produit ?
2. comment savoir si on a fait mouche au lancement d’une nouvelle fonctionnalité si on n’a pas de système de mesure qui nous permette de voir les effets produits par notre travail ?

On disait plus haut que le Pourquoi était fondamental dans la démarche du PM. La mesure, c’est le contrepartie du pourquoi, c’est l’autre plateau de la balance qui va nous permettre de faire les comptes, in fine.

• A quoi verra-t-on qu’on a réussi ce que l’on voulait faire ?
• Que veut-on apprendre de cette initiative ?
• Quel comportement veut-on induire chez l’utilisateur ?
• Quelle hypothèse veut-on tester ?
• Quel proxy metric veut-on pousser, et à quel niveau ?

Les questions que l’on peut se poser sont nombreuses, et un critère de succès peut n’être que vaguement quantitatif. Il n’y a pas en effet que des critères « froids » pour mesurer que l’on a fait un pas en avant. Rien que documenter nos apprentissages est une manière de rendre compte d’un développement et de montrer que l’on ne s’est pas seulement agités, mais que l’on a avancé.

L’important ici est de se poser, tôt, la question du suivi de notre initiative. C’est une aide de plus pour :

• tester notre idée et la rendre plus robuste: il est possible qu’on essayant de définir la mesure, on s’aperçoive que notre idée n’était en réalité qu’une lubie qui n’a que peu d’intérêt.
• avoir plus d’idées car en définissant des manières de capturer le succès, on va articuler des indicateurs et ces derniers sont aussi, dans un mode Impact Mapping, d’excellents points de départs pour avoir plus d’idées
• rendre notre objectif plus clair et plus facilement communicable avec l’ensemble des parties prenantes

Avoir une mesure du succès clairement expicitée devrait donc faire partie de la DoR (« Definition of Ready« ) de votre fonctionnalité. Et prendre ce réflexe de construire, pour chaque nouvelle fonctionnalité, un tableau de bord de suivi qui vous permettra d’en suivre l’appropriation par les utilisateurs et qui sera, lui aussi itératif (car les données appellent toujours de nouvelles données pour les faire parler), diminuera au fur et à mesure votre dette data.

Une dernière observation: l’homme est fainéant par nature, et se poser la question de la mesure du succès (quel que soit sa définition) de vos initiatives va rendre votre travail plus complexe, du moins au début. On aura l’impression de prendre des précautions inutiles, de rendre des comptes, de perdre son temps dans des circonvolutions de formes superflues… Car on sait. Mais en vrai, on ne sait pas vraiment. On peut avoir une bonne intuition produit, mais elle ne doit pas servir à nous reposer sur nos lauriers et excuser notre paresse naturelle. Aussi, comme tout changement de routine, le coût initial de mise en place de tels réflexes sera probablement élevé, et rallentira le discovery, surtout si, dans votre organisation, la donnée est éparpillée un peu partout et n’est que faiblement structurée. Mais assez rapidement vous en percevrez les bénéfices, notamment en termes de confiance dans vos initiatives et de communication avec vos parties prenantes. Alors faites comme-moi: ne vous posez pas trop de questions, considérez que c’est simplement une case de plus à cocher et que cela fait partie de votre travail. Et le jour où cela vous évitera de vous lancer dans des batailles inutiles, vous serez content !

P comme Précise

Trop souvent on déforme ce qu’il y a à faire pour le faire rentrer dans le template convenu pour exprimer nos spécifications. On peut citer à titre d’exemple les Users Stories rédigées en mode solution, et souvent organisées pour attribuer à la volonté de notre utilisateurs une fonctionnalité qu’on a envie de faire en tant que PM. Aussi, le plus souvent, au risque de caricaturer légèrement, l’US la plus représentative de notre backog serait :

En tant que PM,

Je veux faire [telle fonctionnalité X]

Afin de montrer que je travaille bien sur [tel projet Y]

Et de ne pas laisser mes développeurs inoccupés

Bien évidemment je force le trait, mais vous voyez le point: on a vite fait de se perdre dans le formalisme et de perdre l’essentiel de vue. User Story, Job Story, Feature Briefing, etc: à multiplier les termes pour nos spécifications, on en oublierait presque que le but premier d’une spécification est de communiquer efficacement. Et que le seul formalisme qu’une spécification devrait remplir, c’est précisément celui qui lui permet de remplir sa fonction à savoir

• de donner les informations nécessaires pour comprendre ce que l’on essaie de faire
• de déterminer comment on jugera que le travail a été fait

Construire un produit se fait à plusieurs. Aussi, la compréhension par tous, et pas seulement par le PM, de ce que l’équipe essaie de faire est clé pour maximiser l’efficacité du travail. Bien sûr, c’est une lapalissade, mais les gens sont différents et projettent leur vision du monde sur vos mots. Plus vous limiterez les possibilités pour des interprétations possibles (car vos mots sont précis, ou que vos tickets sont courts), plus vous augmenterez l’alignement de l’équipe autour du travail à mener.

Par ailleurs, il y a toujours une part d’incertitudes derrière ce que l’on cherche à faire. On va peut-être avoir une mauvaise surprise en se mettant à coder. Ou bien on aura oublié des cas de figure. Ou encore, le design ne marche pas et est inutilement complexe.

Pour pallier cette incertitude, et garder une communication efficace avec son équipe, il me semble important

• d’insister sur le pourquoi de la fonctionnalité, sur ce qu’on cherche à produire en la menant à bien. En dissociant le plan (le « comment » de la fonctionnalité) de l’objectif, vous donnerez la flexibilité nécessaire à l’équipe pour ajuster ses actions en fonction des nouvelles informations qui seront collectées lors de l’implémentation, sans changer le principe de ce qu’on essayait de réaliser initialement
• de réduire autant que faire se peut l’objectif de la fonctionnalité : moins on courra de lièvres à la fois, moins on aura tendance à mélanger des problèmes (donc à formaliser des plans inadaptés en plus d’être complexes) et plus facile sera la compréhension de la part des autres membres de l’équipe
• d’utiliser des mots simples, non techniques, lisibles de tous : simplifier la communication peut paraître un conseil trivial, mais force est de constater que nous passons notre temps à faire le contraire, notamment en utilisant des acronymes obscurs qui sont autant de barrières à la compréhension, ou en exprimant avec un langage technique une action qui, certes est technique, mais peut très bien être écrite en français.

Idéalement vous pouvez atteindre un point où vous avez presque assez de place dans le titre de votre ticket pour exprimer ce que vous compter faire (le plan, mais qui reste adaptable) et pourquoi vous comptez le faire. Par exemple, cacher les boutons de zoom sur mobile pour alléger la charge cognitive. Ou déclencher tel mécanisme sur tel évènement pour diminuer les demandes de support liées à tel problème.

Avec une telle formulation, 80% de votre spécification est faite :

• elle contient le pourquoi, le quoi et en précise même le périmètre
• elle est lisible de toutes les parties prenantes (y compris des personnes, qui en cas de turnover, viendraient reprendre votre backlog)
• elle contient le plan de bataille, mais reste adaptable car communique clairement l’objectif et donc votre équipe pourrait imaginer des manières plus efficaces pour l’atteindre

Pour rajouter plus de clarté vous pouvez mettre une ou deux phrases de contexte dans votre US, qui permettront d’articuler ces tâches avec vos priorités du trimestre, et d’en justifier avec quelques éléments de preuve. Et dans beaucoup de contextes, cela sera suffisant.

Un point d’attention : veillez à ne pas confondre précision avec surspécification. Si vous avez trop de critères d’acceptances dans votre US, par exemple plus de 4, il y a quelque chose qui ne va pas, et vous pouvez probablement la redécouper encore une ou deux fois. Par précis, on entend simple et clair. Dites vous qu’une bonne US, c’est, peu ou prou, la longueur d’un tweet. Gardez cette contrainte, et cela vous aidera pour créer des petits incréments de valeur.

Pour résumer

PIMP n’est pas vraiment un framework, c’est une liste qui permet de s’assurer, quand on est face d’un projet qu’on l’organise à un niveau micro que l’on oublie rien de vraiment important. Pourquoi cette liste? Car de plus en plus je constatais que je ne retenais d’INVEST que le V (« Value ») et le S (« Small »). Et il me semblait manquer cette composante de séquencement du travail alors même que c’est un des domaines où, empiriquement, un PO/PM peut apporter beaucoup de valeur, et aussi de momentum, à son équipe. Voyez donc cet article plus comme une manière d’ouvrir le débat, et je serais ravi d’en discuter plus en détail avec vous !