Comment prioriser ?
Parmi toutes vos tâches et objectifs, prioriser est l’exercice sur lequel le product owner le plus attendu.
En effet, votre responsabilité principale est de maximiser la valeur produit.
C’est votre faculté à gérer les priorités qui va permettre à l’équipe de délivrer le plus de valeur possible à l’utilisateur.
Plutôt que de vous lister toutes les façons de prioriser, j’ai décidé de vous donner la meilleure méthode de priorisation en fonction du cycle de vie du produit.
En effet, il existe beaucoup trop de méthodes pour prioriser (toutes plus subtiles les unes des autres).
En revanche, une chose dont on parle peu c’est que prioriser dépend de la maturité du produit que vous gérez.
En clair, il faut en permanence adapter votre méthode en fonction du cycle de vie du produit.
Dans ce post, je vous décris le type de priorisation à adopter :
- Au pré-lancement
- Post-lancement
- Avec un produit mature
Prioriser au démarrage d’un projet (pre-launch).
Démarrez avec un customer journey
Au tout début, quand votre démarrez un projet, vous n’avez rien. Pas de produit, pas de user stories, juste un objectif et quelques idées.
J’y reviendrai dans mon prochain post, mais à ce stade, il est souvent utile de commencer par un Design sprint.
Au cours de cet exercice, vous devriez ressortir avec un customer journey.
Ce customer est simplement le parcours utilisateur de votre futur service, étape par étape.
Découpez vos épics
Maintenant que vous avez un parcours utilisateur, il vous suffit de catégoriser chaque grande étape de votre customer journey en Epic.
Par exemple, imaginez que pour l’app mobile Medium vous avez le parcours utilisateur divisé en épic de la manière suivante
- Inscription
- Ajout des thèmes préférés
- Discoverability / editor choice
- Recherche
- Fonction de partage (clap, commentaire…)
- Ajout d’un article
- Paramètres
Le parcours utilisateur vous permet de découper plus facilement l’ensemble de votre service en fonction de la progression narrative de votre service.
Je parle de la fonction narrative comme s’il s’agissait d’un film car bien souvent un bon parcours utilisateur doit raconter une histoire.
A l’inverse d’un film, cette histoire à plusieurs fins possibles car c’est l’utilisateur qui décide de sa destinée (comme un jeu vidéo).
Néanmoins, dans n’importe quel service digital, l’histoire débute de la même manière pour tout le monde (inscription, onboarding….).
Faites un story mapping
Maintenant que vous avez vos épics, vous rentrez dans la phase de découpage au niveau des users stories. C’est ce que l’on appelle le story mapping.
Sur le cas Medium par exemple, vous pouvez découper l’Epic inscription en 4 users stories :
- Page d’accueil avec bouton d’inscription
- Formulaire d’inscription
- Fonction annexes : Mot de passe oublié, confirmation du mot de passe
- Page de confirmation / bienvenue
Le story mapping vous permet de découper des épics dans le désordre.
L’idée est de commencer par l’epic qui vous semble la plus mature à attaquer.
Ce que j’entends par mature, c’est l’Epic qui a le moins de dépendances pour débuter le développement.
Par exemple:
- Une épic peut être en stand by à cause d’un problème technique non résolu par le backend.
- Une autre peut être en stand by car vous êtes en attente d’infos marketing (contenu, images, prix…) ou commerciales pour compléter l’offre de votre produit.
Comment prioriser quand le backlog est presque vide ?
Si vous avez déjà quelques user stories voire même quelques épics de prêtes, ne vous prenez pas la tête.
Ici la valeur business n’a pas trop d’importance car vous n’avez pas encore d’utilisateur.
L’idée la plus simple est de prioriser vos users stories en fonction du parcours utilisateur.
Dans la logique des choses, ca serait bien de commencer par le début du parcours utilisateur afin de bâtir un MVP qui à une logique.
Mettez de coté tous les corner cases ou scénarios extrêmes.
Bâtissez une expérience pour un seul type d’utilisateur (celui qui correspond à votre cible principale).
Oubliez les cas uniques.
Ne cherchez pas la perfection mais visez à sortir une démo le plus vite possible.
Cette démo va vous servir de base pour itérer sur le produit plus rapidement.
Prioriser sur un produit qui vient d’être lancé
Lancement J+10
A ce stade, vous êtes en mesure de collecter les premiers résultats et avis utilisateurs.
Je donne 10 jours mais selon le type d’industrie ou de service cela peut prendre plus de temps.
Pendant ce temps d’attente, continuez à itérer sur votre parcours utilisateurs.
En théorie, le produit que vous avez lancé est loin d’être complet.
Sinon, comme le dit Reid Hoffman (fondateur de LinkedIn),
Si vous attendez d’avoir un produit parfait, c’est que vous avez lancé trop tard.
Collectez les données.
Je ne l’ai pas mentionné dans le premier chapitre, mais pour tout produit et en particulier pour les produits nouveaux, vous devez vous assurer de mettre en place un système de tracking des données.
Si c’est un produit web, faites en sorte de connectez au moins un outil comme google analytics et de paramétrer vos dashboards.
Si c’est un produit applicatif, implémenter des events à envoyer en base et reportez ces événements sur des outils de visualisation tels que chart.io ou tableau (il y en a des dizaines sur le marché pour toutes les bourses).
Prioriser les quick wins.
L’étape de lancement d’un nouveau produit est excitante mais aussi très stressante car vous devez être constamment au four et au moulin.
Dès que vous récoltez vos premières données, il y a de fortes chances que plein de choses ne se passent pas comme prévu et que vous ayez de grosses surprises.
Si vous voyez un signal d’alarme du type :
- Taux de rebond énorme sur la page d’accueil
- Gros pourcentage d’abandon en plein milieu du tunnel d’onboarding.
- Fonctionnalité non utilisée
- Etc…
Soyez réactif.
Votre première priorité est de mettre de côté tout ce que vous êtes en train de faire pour trouver une solution au problème en production.
Etant donné que vous itéré en suivant le parcours utilisateur, il est inutile de s’obstiner à vouloir livrer l’étape 3 (même si cela vous tient à coeur) s’il y a un blocage dans l’étape 1.
La logique d’un nouveau produit est de suivre le Framework AAARR (j’en parle ici).
Avant de chercher à optimiser certaines étapes à fond, assurez vous de délivrer une expérience qui permet à l’utilisateur d’aller du point A à Z sans bloquer à C, F ou M.
Peu importe si toutes les étapes ne sont pas parfaites, faites en sorte que le plus d’utilisateurs possibles captent votre narrative du début à la fin.
Si vous avez stabilisé une Version 1.
Admettons que vous avez survécu la zone de turbulences des premières semaines / mois et que vous avez désormais une base d’utilisateurs actifs stables.
Désormais, il est temps de penser à moyen terme.
La V1 c’est bien mais ce produit est encore trop limité pour les core users.
Il est donc temps de prioriser autrement et de laisser de côté la logique du parcours utilisateur.
A ce stade, je vous conseille le framework MoSCoW. Cette méthode permet de prioriser les users stories à moyen terme selon les critères suivants :
Mo — Must have : User story qui Doit être réalisé sans discussion
S — Should have : User story qui Devrait être réalisé au maximum.
Co — Could have : User story qui Pourrait être réalisé s’il n’y a aucune autre tâche plus importante en cours.
W — Won’t have : User story qui a été un temps envisagée mais qui ne sera pas réalisée.
Evidemment, cette priorisation doit s’établir sur une base concrète :
- Les premiers résultats et analyses quantitatifs récoltés
- Les avis utilisateurs (questionnaires, feedbacks, commentaires et notes AppStore et PlayStore)
- Les nouveaux objectifs business
Vous entrez désormais dans une sphère où les priorités sont basées sur des critères objectifs. Fini les intuitions et prémonitions.
Prioriser des user stories avec un projet mur
Le contexte
A partir de cette étape, votre situation est :
- La majeure partie des fonctionnalités clés est déjà livrée
- La valeur produit est déjà haute
Normalement niveau marché, à ce stade vous devez avoir une solide base de clients / utilisateurs.
Celle-ci peut encore se consolider mais l’effort majeur pour acquérir de nouveaux clients est situé au niveau marketing.
Pourtant, à ce stade votre backlog est plein à ras bord.
Au fil des mois vous avez créé des brouillons de user stories que vous n’avez jamais implémentées.
Comment faire le tri
Il y a très peu de chance qu’une Killer feature se cache dans votre backlog.
Au contraire, toutes les users stories sont d’ordre secondaires et vous ne savez pas les prioriser.
Idéalement vous espérez avoir de nouveaux insights utilisateurs pour planifier votre prochain gros projet.
Malheureusement ceux ci se font attendre et vous allez devoir trier ce backlog et alimenter les prochains sprints.
Pour faire face à cette situation, je vous propose une autre méthode pour prioriser.
La méthode du ROI.
- ROI en anglais c’est un acronyme qui signifie Return of Investment (Retour sur investissement en francais)
- Pour prioriser en fonction de la méthode du ROI vous devez maitrisez 2 concepts: La valeur et la complexité.
La complexité, si vous êtes familier avec le Poker grooming, cela ce traduit par les points d’effort que vous donnez pour chiffrer chaque user stories (1,2,3,5,8 etc…)
La valeur, cela signifie ici la valeur business.
En clair, c’est l’impact de la story sur une KPI de votre business (Revenus, acquisition, rétention…).
Par exemple,
Sur un site e-commerce, la fonction panier à plus de valeur que la fonction “agrandir les photos” car son impact sur le chiffre d’affaire est plus grand.
Calcul du ROI
En général, la valeur se définit sur une échelle de 100 à 1000.
100 étant la plus petite valeur et 1000 la plus grosse.
Ainsi, pour calculer le ROI, la formule est ultra simple. Il s’agit d’une simple division.
ROI = Valeur / complexité (point d’effort)
Pourquoi ne pas prioriser avec la valeur business seulement ?
Bonne question.
Le problème d’utiliser la valeur comme seul critère de priorisation à ce stade c’est que vous risquez de gaspiller des ressources.
Explication :
Imaginez que vous avez 2 users stories:
L’une avec une valeur de 300 et l’autre avec une valeur de 600.
Logiquement, si vous ne prenez en compte que le critère de valeur, vous allez prioriser la US à 600.
Maintenant, si je vous dis que la US de 300 à 2 points de complexité et que la US de 600 à 8 points de complexité.
Faites le calcul du ROI pour chacune :
ROI de l’US 1 = 300 / 2 = 150
ROI de l’US 2 = 600 / 8 = 75
Soudainement, le retour sur investissement de la US 2 est deux fois inférieur à l’US 1.
En cherchant à maximiser à tout prix la valeur produit en priorisant uniquement des US ayant des valeurs hautes, vous omettez le coût de production.
La méthode du ROI permet d’apporter la dimension de coût
Quand utiliser le ROI ?
Dans une stratégie de rentabilité, le coût et le temps de production sont aussi importants que le bénéfice.
Attention cependant à ne pas suivre ce principe à la lettre.
N’oubliez pas le contexte.
J’insiste sur le fait que la méthode du ROI est à adopter lorsque la valeur produit est déjà haute et que vous êtes face à un backlog avec des petites users stories uniquement.
Si vous êtes dans un cycle plus early et que vous avez des US ayant des valeurs qui dépassent les 800, ne cherchez pas à calculer le ROI.
Ne prenez en compte que la valeur business.
Il s’agit ici de fonctionnalités clés pour votre produit voire même Killer.
Vous ne pouvez pas vous en passer.
Le mot de la fin
Il existe d’innombrables techniques pour prioriser vos US.
Faire un inventaire nécessiterait presque d’écrire un livre uniquement dédié à ce sujet ( le RICE, le Kano…).
Mon conseil est simple. Ne soyez pas figé.
Adaptez votre méthode en fonction du cycle produit dans lequel vous vous situé.
Prioriser est un exercice de bon sens.
Si vous avez les bonnes informations marché, vos priorités sont définies par la vision produit que vous portez.
N’oubliez pas non plus d’inclure les membres de votre équipe dans l’exercice de la priorisation afin de respecter un certain alignement.
Je profite de cet article pour vous indiquer que dans les prochains jours, je vais sortir une nouvelle rubrique appelé formats courts.
Dans cette rubrique je traiterai de sujets plus succinctement pour répondre rapidement à des questions que je reçois.
Lors de ces prochains formats courts, j’aborderai, en outre, 2 points que je n’ai pas traité dans ce post, à savoir :
Très intéressant, merci!
Merci Céline !
Bonjour Julien,
Je suis désolé, mais je pense qu’il y a un véritable problème dans la compréhension de la notion de ROI. Le ROI est le rapport entre les recettes (le cash flow) et les dépenses (l’investissement). C’est une grandeur sans dimension qui s’exprime en pourcentages. Et c’est absolument fondamental pour deux raisons.
1) La grandeur s’intéresse à la question monétaire, qui est inhérente à la logique de rentabilité et de profit d’une entreprise lucrative. Penser qu’on peut supplanter ce paramètre par un autre, qui a une unité différente, c’est soit échapper à cette logique, soit être incapable de voir la non linéarité dans la passage d’une grandeur à l’autre. Pour faire simple, ce n’est pas parce que vous avez 2 fois plus de clics – par exemple – que vous gagnez 2 fois plus d’argent. Il y a d’ailleurs plein de situations où des gens sont incités par leur influenceur préféré à cliquer sur un lien sponsorisé, pour lui faire gagner de l’argent, alors qu’ils ne vont rien dépenser.
2) L’unité au dénominateur doit permettre d’effectuer des comparaisons cohérentes. Or il me semble que les points d’efforts utilisent les valeurs de la suite de Fibonacci (1, 2, 3, 5, 8, 13, 21, etc.), ce qui aboutit à des problèmes.
En effet, supposons que je doive réaliser une tâche A « deux fois plus complexe » – à vrai dire je ne sais pas ce que ça veut dire, puisqu’il n’y a pas d’outil de mesure de la complexité – qu’une tâche B de complexité 3, mais qui me rapporte deux fois plus. En toute logique, si A me rapporte deux fois plus que B, alors leurs « ROI » sont similaires (disons que A rapporte 600 et B 300). Or la complexité 6 n’existe pas. Je suis obligé de choisir entre 5 et 8. Ce qui implique que mon A pourrait aussi bien avoir un ROI de 600/8 = 75 100.
En théorie, ces deux tâches ne peuvent pas être hiérarchisées. Pourtant, je dois ici faire un choix pour les hiérarchiser arbitrairement.
Si maintenant, je remplaçais 600 par 650, je devrais théoriquement choisir A. Pourtant, si je prends la complexité 8, j’obtiens un résultat inférieur à 300/3 = 100.
Ce système de prise de décisions semble, en fin de compte, totalement arbitraire.
Malheureusement j’ai déjà eu une personne en entretien qui croyait m’avoir piégé parce qu’elle attendait de moi que j’évoque le ROI dans la hiérarchisation des tâches. Mais c’est très complexe de calculer un authentique ROI. Une erreur d’estimation est très fréquente et, même une fois la tâche à hiérarchiser accomplie, il est difficile d’estimer quels revenus peuvent être attribués à sa réalisation (on risque en effet de tomber dans le piège du post hoc ergo propter hoc). Il est donc plus honnête d’accepter que la hiérarchisation fait intervenir beaucoup de données différentes et une grosse part de subjectivité.
Évidemment, comme j’ai eu une formation scientifique et que j’ai une passion pour la science, je prête une grande attention à ce genre de détails. Et le monde de l’entreprise a malheureusement tendance à me décevoir sur ce point. Je regarde néanmoins avec attention votre blog, en tant que jeune diplômé qui cherche à parfaire ses connaissances du poste. Même si, pour le moment, je peine hélas à trouver un emploi.
Cordialement,
Julian
Je me permets d’ajouter un complément, mais je pense que votre ROI ressemble en fait plus à un taux de productivité. Je ne comprends pas très bien pourquoi mobiliser cette notion de ROI. Surtout qu’un ROI ne sert pas qu’à effectuer des comparaisons, mais doit aussi pouvoir dire si une action est rentable (ROI > 1) ou pas (ROI < 1). Or ici, il n'y a aucun seuil de rentabilité.
Ma question est donc : est-ce vraiment une notion qui est mobilisée par beaucoup de product owner ?
Julian