Au cours d’une mission, nous avons été confrontés à une question que l’on connaît tous, comment aider un Product Manager à prioriser ? C’est un atelier Buy a Feature qui nous a permis de trouver une solution.
Contexte
Lors de la construction d’un produit, il est difficile de s’accorder sur une roadmap de développement. Nous avons généralement une liste de fonctionnalités toutes très importantes mais aucun moyen facile de les prioriser. C’est en tout cas un problème que j’ai rencontré chez un client.
Voici le contexte de la mission :
- La construction d’un produit numérique B2C de consultation de commande e-commerce
- Plus de 10 stakeholders sur le projet, avec chacun des intérêts distincts
- Le MVP a déjà été identifié suite à un story map. Ce MVP ne concernant qu’un nombre réduit de commandes ; il nous fallait augmenter les cas fonctionnels gérés par l’application ainsi qu’y inclure de nouvelles fonctionnalités.
- Suite à ce MVP nous devions identifier une roadmap de trois mois.
L'objectif était de définir une priorité satisfaisant tous les stakeholders, incluant de nouvelles features et élargissant le nombre de clients concernés.
Après plusieurs propositions de roadmap rejetées, nous avons donc fait un atelier Buy a Feature réunissant toutes les parties prenantes afin d’obtenir une priorisation validée par tous.
Préparation de l’atelier
Attention, pour que cet atelier soit bien compris et percutant, il faut une bonne préparation !
Les différentes étapes de préparation de l’atelier sont les suivantes :
- Constituer la liste des features
Au cours d’un brainstorming, nous avons identifié un maximum de features pouvant intéresser les stakeholders. Nous avons ensuite trié et priorisé ces features en enlevant celles jugées moins pertinentes ou celles trop complexes pour être traitées en début de projet. A la fin de ce tri nous avions environ 25 fonctionnalités (ce qui est pour moi un maximum).
N.B. : Avoir la liste d’un maximum de features éventuelles n’a pas pour but de remplir la roadmap de l’année, mais d’anticiper les questions des participants pendant l’atelier si leur sujet a été écarté.
- KPI sur ces features (actuel/objectif)
L’idée derrière ces KPIs est de fournir aux participants de quoi comparer les features les unes aux autres. Nous avons donc sorti un maximum de données comme le nombre de clients concernés par une feature ou une estimation du taux de clics.
N.B. : Vous pouvez aussi évaluer la valeur business de chaque fonctionnalité pour pouvoir les comparer.
- Estimation du prix des features
Une des phases essentielles dans la préparation de cet atelier est l’estimation du coût de chaque fonctionnalité. Pour l’obtenir vous pouvez faire une session d'extreme quotation ; un planning poker risque d’être trop chronophage.
N.B. : Je conseille plutôt l’extreme quotation car nous ne cherchons pas ici à obtenir le coût exact mais une estimation relative des features.
Après avoir classé les features par complexité, nous avons fait une première estimation du prix en suivant la suite de Fibonacci (en K€) ; les features les moins complexes valaient 1000 € puis 2000 € et ainsi de suite… Nous avons ensuite itéré sur ce premier jet afin d’harmoniser les prix et de limiter le nombre de fonctionnalités “peu coûteuses”.
- Budget
Une fois les prix fixés, il reste à évaluer le budget qui sera distribué entre les participants. Pour cela nous avons calculé le coût total des features (dans notre cas 500 000€) et nous avons pris une fraction de cette somme comme budget (120 000€, soit légèrement moins d’un quart de la somme totale). La fraction choisie dépend de la durée de la roadmap voulue.
N.B. : Nous avions listé des features pour environ 1 an, et devions déterminer une roadmap pour le premier trimestre, d’où une sélection d'un quart de la somme seulement.
Déroulement de l’atelier
- Participants
Pour l’atelier nous avions convié les représentants des différentes parties prenantes du projet. Nous avons ensuite réparti équitablement le budget entre eux et nous leur avons présenté le déroulement de l’atelier.
N.B. : Gardez un nombre de participants raisonnable. Nous étions un peu plus d’une dizaine au cours de notre session et à mon sens c'est le maximum.
- Présentation de l’atelier : 10 min
Lors de la présentation il est important que chaque participant comprenne l’objectif de l’atelier, son déroulement mais aussi les situations auxquelles ils vont être confrontés (négociations).
- Achats : 30 à 60 min selon le nombres de fonctionnalités et le nombre de participants
Les participants regardent de plus près chaque feature puis identifient celles qui les intéressent. Ils vont ensuite se rapprocher des participants ayant les mêmes objectifs qu’eux. Dès qu’une feature est achetée, il faut bien le communiquer aux autres participants.
N.B. : Il est intéressant de donner un budget à l’équipe afin qu’elle puisse aussi participer à sa roadmap. Dans notre cas, l’équipe n’essayait pas d’acheter des features mais elle aidait à l’achat de ce qui lui paraissait pertinent.
- Priorisation : 10 à 20 min selon le nombre de fonctionnalités
Une fois les achats terminés, nous avons établi une priorité de développement entre les différentes features choisies. Même si tous les sujets identifiés seront développés, il est important de définir cet ordre afin d’éviter des retours de stakeholders s'impatientant de ne constater l'avancement de leur sujet.
Pour ce faire, nous avons d’abord demandé l’avis de l’équipe car certains sujets peuvent être moins coûteux s’ils sont traités en dernier et inversement. La priorité ainsi définie a été partagée avec tous les participants.
Observations
Outre le partage de la priorité, nous avons pu observer plusieurs autres éléments au cours de cet atelier :
- Questions sur les prix :
Dès le début de l’atelier, il nous a été demandé s’il était possible de négocier les prix. Il est donc important de définir les prix avec l’équipe afin de pouvoir mettre en avant la complexité d’un sujet.
- Limiter les demandes de dernière minute :
Partager la roadmap et la priorité avec tous les participants permet de limiter le nombre de “demandes urgentes de dernière minute”.
- Participation de l’équipe
La présence de l'équipe a été très bien accueillie par l'ensemble des participants. L’équipe s’est sentie plus impliquée dans la construction du produit et ses explications ont permis aux participants de mieux comprendre les différences de complexité entre les sujets.
Il est vrai que les utilisateurs du produit sont idéalement les participants de cet atelier mais dans des entreprises de taille conséquente, il est difficile de les interroger directement. De plus, nous sommes souvent confrontés aux enjeux business ou aux obligations de l’entreprise : jouer cet atelier en interne devient alors pertinent.
En définitive, je conseille cet atelier à tout Product Manager qui rencontrerait des difficultés à obtenir une priorisation, une définition de roadmap ou qui cherche à fédérer les différentes parties prenantes d’un projet ou encore simplement à sensibiliser les acteurs extérieurs à l’équipe au coût d’une fonctionnalité.
