3 ateliers de priorisation pour communiquer avec vos stakeholders

En tant que Product Manager, qui n’a jamais entendu la phrase “psssst, tu ne pourrais pas intégrer cette feature dans le sprint …” ? On parle souvent de la communication avec ses utilisateurs et son équipe technique, mais peut-être pas assez des communications avec les parties-prenantes. Il est essentiel qu’elles comprennent les problèmes que rencontrent vos utilisateurs afin d’être à même de prioriser les solutions à développer le mieux possible.

Cerner ses problématiques avant de prioriser les solutions

En tant que product manager, votre priorité sera de vous concentrer sur les problèmes que rencontre votre cible, afin de leur proposer un outcome. Une fois que ceux-ci seront bien cernés et priorisés, il sera temps de réfléchir à toutes les solutions que vous allez pouvoir apporter pour y répondre, c'est-à-dire les outputs.

À toutes les étapes du développement d’un produit, il sera crucial de prioriser :

• Les problématiques : c'est-à-dire les irritants que rencontrent vos utilisateurs, ceux qui sont à traiter en premier, qui auront le plus de valeur.
• Les solutions : une fois le problème cerné et les différentes options pour le résoudre énumérées, il faudra se concentrer sur celles qui auront le plus d’impact pour vos utilisateurs.

De nombreux outils de priorisation existent, certains faisant appel à de savants calculs, d’autres un peu plus ludiques. Différents critères sont habituellement pris en considération :

• la valeur utilisateur ou business
• la satisfaction utilisateur
• la complexité technique
• le temps de développement / le nombre de personne à mobiliser

L’objectif principal reste de s’assurer que toutes les parties prenantes soient alignées sur les epics à prioriser et que le choix se fasse de manière collective et transparente.

Rien de mieux donc que d’animer un atelier pour mettre tout le monde d’accord ! Product leader, managers métiers, décideurs, invitez les personnes concernées et décisionnaires qui vous semblent pertinentes, notamment ceux avec des intérêts divergents.

Vous pouvez également intégrer le légal, le design, des développeurs, la finance, des devops, les Product Managers d’autres équipes... Ils vous permettront d’apporter des réponses rapidement et d’éviter que des points critiques soient oubliés au début du projet.

Assurez-vous également que les différents participants aient bien en tête les problèmes utilisateurs qui souhaitent être résolus, la complexité des features, l’état d’avancement (d’un point de vue produit, design et technique) et les dépendances avant de les prioriser.

Une fois que toutes les solutions et leur périmètre sont clairs pour chaque participant, passez à la priorisation.

Atelier n°1 : MoSCoW

Selon l’état d’avancement de votre produit, vous pouvez commencer l’atelier par un rappel du product vision board ou que le management fasse un rappel des enjeux.

L’objectif est de hiérarchiser les features par priorités :

Must have : ce qui est vital pour le produitShould have : ce qui est important mais non vitalCould have : ce qu’il serait bien d’avoirWon’t have : ce qui représente peu ou pas de valeur et qu’on peut facilement abandonner

Fonctionnement :

1- Dessiner sur un tableau blanc les 4 zones (Must have, Should have, Could have, Won’t have).

2- Préciser que l’objectif est de faire des choix et de ne pas tout mettre dans Must, n’hésitez pas à définir le nombre de features attendues par zone au besoin.

3- Demander à vos participants

Vous pouvez réaliser cette étape de façon collective ou individuellement avec une mise en commun. L’objectif est d’avoir des échanges constructifs pour obtenir un consensus de tous les participants, certains tickets seront peut être découpés ou allégés. Communiquez, soyez réaliste et transparent, cela vous permettra d’être fier de ce que vous montrerez au management et aux équipes. Vous aurez ainsi une priorisation claire et justifiable qui vous aidera dans la gestion de votre backlog.

Atelier n°2 : Buy a Feature

Une fois vos features priorisées avec le MoSCoW, il se peut qu’il y en ait encore trop dans la section Must et qu’une deuxième étape de priorisation soit nécessaire. C’est à ce moment-là que l’atelier Buy a Feature entre jeu !

Plusieurs variantes existent mais l’objectif reste le même : prioriser les features via une estimation de leur coût relatif.

Fonctionnement :

1- Lister les fonctionnalités que vous souhaitez prioriser et assigner, collectivement ou en amont de l’atelier, un prix en fonction du coût de développement, de la complexité et des efforts requis pour chaque fonctionnalité.

2- Ensuite, attribuez un budget à chaque participant afin qu’il puisse acheter des features. Le budget total des participants ne doit pas trop se rapprocher du coût total estimé des features, s’ils ont suffisamment d’argent pour acheter toutes les features, ils ne seront pas poussés à faire des choix.

Astuce : les participants ont le droit de collaborer et d’acheter une feature à plusieurs. Idéalement, au moins une des features doit avoir un prix plus élevé que le budget individuel.

3- Observer les débats et négociations. À vos notes ! Vous allez en apprendre davantage sur les besoins et priorités des participants.

4- Une fois que les participants ont dépensé leur budget (attention ils ne peuvent pas le dépasser) chacun explique ses choix et pourquoi ils ont privilégié telle ou telle feature.

5- Faite le total du nombre de fois qu’une fonctionnalité à été achetée, celles qui ont été achetées le plus souvent sont à prioriser.

Pour les features qui ont été priorisée uniquement par une ou deux personnes, assurez vous qu’elles puissent justifier leur choix, il se peut que certains critères n’aient pas été prises en compte par les autres participants.

6- Réitérer l’opération si nécessaire.

Atelier n°3 : Guerilla prio

Libre à vous d’inventer de nouveaux ateliers, plus adaptés à votre contexte et à vos participants. L’idée de celui-ci est d’avoir une discussion de priorisation uniquement sur les features qui sont sujettes à débat. Il se peut en effet que les participants soient d’accord sur les principales features et que la négociation se fasse que sur quelques unes.

Fonctionnement :

1- D’un côté vous avez tous les post-it avec les features ou points à prioriser, de l’autre un tableau en 3 colonnes : Now, Next, Later.

• Now : apporte beaucoup de valeur, rapide à mettre en place
• Next : valeur ajoutée moyenne, assez long à mettre en place
• Later : valeur ajoutée faible, long à mettre en place

2- Les participants prennent les post-it et les positionnent dans une des cases Now, Next, Later.

3- Une fois tous les post-it placés, tout le monde regarde la priorisation proposée et identifie ceux qu’il trouve mal positionnés.

4- Pour les features qui sont à repositionner selon certains, ouvrez une discussion et repositionnez-les au besoin.

Attention, encore une fois, l’objectif n’est pas que tout soit dans la case Now !

Faites preuve de bon sens !

L’idéal serait de pouvoir se baser sur des metrics et non uniquement sur un ressenti et l’opinion de plusieurs personnes, c’est tout l'enjeu de nombreux outils de priorisation tels que RICE, Kano, …

Dans la mesure du possible, essayez de les intégrer, cela vous donne la possibilité de créer vos propres ateliers de priorisation. Tous les PM vous le diront, pour animer des ateliers, il faut avant tout faire preuve de bon sens !

Selon l’état d’avancement de votre produit, le niveau d’information des participants, adaptez les ateliers. Vous pouvez en faire de très simples, avec une matrice effort/valeur pour chaque epics ou feature puis demander à chacun de placer un jeton sur les 3 plus importantes peut-être suffisamment efficace.

Une fois votre roadmap priorisée, vous serez à même d’organiser votre backlog au quotidien et d’être garant des objectifs définis. Bien entendu, votre roadmap pourra être repriorisée ultérieurement.