Skip to main content

Si vous voulez mon avis, deux des compétences les plus importantes en gestion de produit sont connaître vos priorités et savoir dire « Non ».

Aujourd’hui, nous allons approfondir la première (la seconde mériterait un guide à part !) et vous aider à prioriser votre travail tout en gardant tout le monde aligné sur vos priorités.

Une note importante sur les frameworks de priorisation des fonctionnalités produit

Avant d’explorer les façons de prioriser votre backlog, il y a un conseil important que je dois partager avec vous.

Vous voulez plus de The CPO Club ?

Inscrivez-vous gratuitement pour terminer la lecture de cet article :

This field is for validation purposes and should be left unchanged.
Name*
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form
By submitting, you agree to receive our newsletter and occasional emails related to The CPO Club. You can unsubscribe at any time. For details, review our Privacy Policy.

Les frameworks de priorisation ne sont pas destinés à être pris au pied de la lettre.

Non, vous n’êtes pas obligé de les utiliser exactement comme ils sont décrits dans le livre (ou dans ce guide). Le produit que vous gérez pourrait être complètement différent de ceux que l’auteur avait sous sa responsabilité lorsqu’il a écrit son livre. Des produits différents signifient des réalités et des besoins différents. Il est donc tout à fait normal d’adapter le framework à vos propres besoins. Après tout, un bon framework est celui qui fonctionne pour vous.

Des frameworks de priorisation produit à essayer

Savez-vous qu'il existe un framework de priorisation Thanos ? Il suffit de supprimer aléatoirement la moitié des fonctionnalités de votre backlog !

Bon, j’ai inventé cela. Mais vous voyez ce que je veux dire : il y a beaucoup trop de frameworks existants. Tellement que je ne pourrai clairement pas tous les couvrir dans ce guide. Honnêtement, je ne pense pas que vous soyez ici pour mémoriser des centaines de frameworks non plus.

À la place, je vais donc détailler ceux que j’ai personnellement utilisés au quotidien dans la gestion de produit et partager avec vous quelques conseils pratiques pour chacun. Il est aussi intéressant de réfléchir à la manière dont vous pourriez utiliser l’IA dans la priorisation des fonctionnalités en complément.

1. Modèle de Kano

Cette méthode de priorisation tire son nom du talentueux auteur et consultant en management japonais Noriaki Kano. La beauté de son approche réside dans sa simplicité.

Ce que Kano propose, c’est de classer vos fonctionnalités dans ces groupes :

  • Essentielles : Ce sont les fonctionnalités de base de votre produit, et leur absence entraînera une mauvaise expérience pour le client (une mauvaise rétention et de la résiliation sont garanties). Un bon exemple : la fonction chat dans Intercom ou la recherche d’avis clients dans G2.
  • Performances : Ces fonctionnalités créent de la valeur utilisateur selon leur présence. Plus il y en a, plus il y a de valeur. Regardez simplement la capacité de batterie/l’autonomie d’une voiture électrique moderne. Une meilleure autonomie offre (en général) plus de valeur aux conducteurs. Un autre exemple : le nombre d’intégrations dans Zapier.
  • Attractives : Au lieu d’apporter une valeur directe ou de répondre à une douleur utilisateur, ces fonctionnalités visent à renforcer l’attrait de votre produit. Des pages de vision du produit soigneusement conçues dans un outil de gestion de projet ou des sièges en cuir dans une voiture en sont de bons exemples.

Si nous devions visualiser la relation entre la fréquence de ces types de fonctionnalités et la satisfaction client qu’elles génèrent, cela ressemblerait à quelque chose comme cela.

kano model example

On voit ici que les fonctionnalités de performance sont de nature linéaire (donc, plus il y en a, plus vous obtenez de la valeur). Les fonctionnalités essentielles, en revanche, ne créent pas beaucoup de valeur supplémentaire. Elles servent plutôt à supprimer la source d’insatisfaction pour vos utilisateurs.

Enfin, la catégorie « attractive » est là pour donner un bonus de satisfaction supplémentaire. Mais elle n’aura aucun effet si vous avez loupé l’essentiel.

Nous avons rassemblé l’essentiel — prompts IA, offres exclusives, et une bibliothèque de ressources pour les responsables produit. Déverrouillez votre compte pour y accéder.

Nous avons rassemblé l’essentiel — prompts IA, offres exclusives, et une bibliothèque de ressources pour les responsables produit. Déverrouillez votre compte pour y accéder.

This field is for validation purposes and should be left unchanged.
Name*
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form
By submitting, you agree to receive our newsletter and occasional emails related to The CPO Club. You can unsubscribe at any time. For details, review our Privacy Policy.

Kano dans la vraie vie

Comment appliquer concrètement le modèle Kano ? Par expérience, le modèle Kano est rarement utilisé lors des réunions de priorisation ou de brainstorming. La raison est que c’est quelque chose de très intuitif, et il n’est pas nécessaire de le dessiner au tableau pour demander aux gens de classer leurs fonctionnalités dans ces trois catégories.

À la place, vous allez plutôt former vos parties prenantes à penser « Kano ». Grâce à cela, avant qu’ils ne vous soumettent une nouvelle demande de fonctionnalité, ils passeront l’idée à travers ce filtre mentalement et décideront si cela vaut la peine d’explorer ou non.

De cette façon, vous déléguez une partie du travail de priorisation des fonctionnalités à vos parties prenantes et vous gagnez énormément de temps sur de longues sessions de brainstorming.

2. Méthode MoSCoW

La méthode MoSCoW fait partie des approches les plus populaires pour prioriser les fonctionnalités. Sa popularité réside dans sa simplicité et son efficacité.

Pour appliquer cette méthode, il suffit de passer chaque fonctionnalité en revue dans votre liste et de lui attribuer l’une de ces quatre priorités :

  • Indispensable
  • Souhaitable
  • Possible
  • Ne sera pas inclus

Vous attribuez généralement ces priorités à partir d'une combinaison de facteurs, notamment la valeur créée pour les utilisateurs, la valeur commerciale, l’alignement stratégique, la complexité de la mise en œuvre, et d'autres encore.

Voici à quoi ressemblera une liste typique de fonctionnalités pour un service de streaming musical si vous appliquez MoSCoW.

liste de fonctionnalités pour un service de streaming musical
  • Ici, nous avons attribué le mode hors ligne comme « indispensable » en considérant que beaucoup de nos utilisateurs écouteront de la musique à bord d’un avion.
  • Les expériences en VR, en revanche, reçoivent la priorité « ne sera pas inclus » car elles sont assez difficiles à mettre en œuvre et très peu d’utilisateurs possèdent un casque VR pour en profiter.

MoSCoW dans la vie réelle

Bien que vous puissiez parfaitement utiliser MoSCoW pour vous aider à piloter vos réunions de priorisation, il existe un inconvénient qui le rend moins efficace pour ces situations.

Puisque la priorité dépend d’une combinaison de plusieurs facteurs, il devient assez long pour chaque membre de l’équipe d’expliquer le raisonnement derrière ses décisions produits. D’après mon expérience, les sessions MoSCoW sont assez lentes et inefficaces par rapport à d’autres cadres.

Mais cela ne veut pas dire que je n’aime pas MoSCoW. En fait, c’est le cadre que j’utilise le plus souvent. Mon endroit préféré pour appliquer MoSCoW est la liste des fonctionnalités dans un PRD.

Je donne généralement aux lecteurs le contexte sur la valeur utilisateur, les complexités techniques, et d’autres facteurs dans le document avant de procéder à la liste des fonctionnalités. Ainsi, quand ils voient « Indispensable » à côté de l’une d’entre elles, ils possèdent le contexte pour comprendre rapidement la logique de ma décision.

De cette façon, MoSCoW me permet d’obtenir une liste de fonctionnalités facile à comprendre dans un document de spécifications produit.

3. Méthode RICE

Contrairement aux deux méthodes précédentes, le modèle de notation RICE est un peu plus structuré et moins dépendant de l’intuition dans la prise de décision. Il identifie quatre facteurs distincts de priorisation et vous permet de quantifier et d’évaluer chacun séparément. Ces facteurs sont :

  • Portée : Elle représente la proportion de vos utilisateurs qui seront touchés par cette fonctionnalité.
  • Impact : L’ampleur de l’impact lui-même.
  • Confiance : Indique si vous êtes sûr que les personnes atteintes ressentiront bien cet impact.
  • Effort : Il s’agit du temps dont votre équipe de développement et produit a besoin pour que cette fonctionnalité soit prête.

Ce que vous faites généralement, c’est sélectionner une fonctionnalité, puis attribuer une note entre 0 et 10 pour chacun de ces quatre facteurs. Ensuite, vous calculez le score RICE avec cette formule.

Enfin, vous classez votre liste de fonctionnalités selon la métrique principale de ce cadre — le score RICE (plus le score est élevé, plus la priorité l'est). Voici à quoi ressemble le résultat d’une priorisation RICE.

exemple de priorisation RICE
  • Dans cette liste, nous pouvons voir que la Nouvelle Interface Utilisateur a reçu la note la plus élevée grâce à son faible effort et à sa grande portée/impact.
  • La fonctionnalité Synchronisation Cloud, en revanche, se trouve en bas de la liste en raison du niveau d’effort élevé qu’il faudra à votre équipe pour sa mise en place.

Score RICE dans la vie réelle

J’ai insisté sur le fait que ni MoSCoW ni Kano ne sont les meilleurs pour les réunions de priorisation et de brainstorming. Mais quel cadre j’utilise dans de tels cas ? C’est RICE !

En attribuant des notes distinctes pour chaque facteur, vous facilitez la présentation du raisonnement derrière les décisions lors de ces réunions (ce qui manque à MoSCoW). En plus, il devient possible de confier la notation de chaque facteur aux coéquipiers qui sont les plus compétents dans ce domaine.

Par exemple, votre équipe de développement produit est la mieux placée pour attribuer la note d’effort. Vos analystes de données, en revanche, comprennent le mieux la portée potentielle de la fonctionnalité.

4. Cartographie des User Stories

Techniquement, le User Story Mapping n'est pas un cadre de priorisation. Il sert plutôt à organiser le travail à accomplir pour votre équipe et à révéler toutes les fonctionnalités à ajouter pour garantir des parcours utilisateurs complets.

Pour construire une story map, listez les principales activités (ou "jobs") de vos utilisateurs puis décrivez les tâches qu'ils doivent réaliser pour chacune de ces activités. Ensuite, dressez la liste de toutes les fonctionnalités nécessaires afin que vos utilisateurs puissent accomplir ces tâches. Vous pouvez le faire avec des post-its sur un tableau blanc ou utiliser l’un des nombreux outils dédiés aux chefs de produit.

Voici à quoi ressemble la carte pour un service de streaming musical.

exemple de user story mapping

Vous ne serez probablement pas amené à faire beaucoup de priorisation à ce stade.

Cependant, le fait de consigner les fonctionnalités nécessaires pour chaque "job" vous aidera tout de même à prioriser car vous réaliserez qu’il manque certaines fonctionnalités pour des activités importantes (qui sont prioritaires à vos yeux).

Vous ajouterez alors rapidement ces fonctionnalités manquantes à votre backlog et les placerez en tête afin de vous assurer que cette activité spécifique soit pleinement couverte pour vos utilisateurs.

Dans l'exemple ci-dessus, nous avons une story map MVP en cours de développement (les stories terminées ont une coche à côté de leur nom). En l’examinant, on remarque que l’activité de gestion de compte est incomplète : les connexions via les réseaux sociaux n’ont pas encore été réalisées.

Donc, avant d’entamer le développement de la recherche d'artiste/album, nous devrions d’abord compléter la gestion des comptes.

Les Story Maps dans la vraie vie

Tout comme RICE, les story maps sont idéales pour vos réunions de priorisation et de brainstorming. Un des principaux avantages de ce cadre est d’apporter la perspective utilisateur dans la salle de réunion.

En observant les activités et les tâches utilisateurs, vos collègues seront moins enclins à proposer des idées de fonctionnalités qui n'apportent aucune valeur ou qui ne répondent pas aux besoins et douleurs réels des clients. Même s’ils en proposent, vous pourrez leur attribuer facilement une faible priorité puisqu’elles n’aident pas les utilisateurs à accomplir leurs tâches.

5. L’Opportunity Scoring

Structurellement, l’Opportunity Scoring ressemble à RICE. Cependant, contrairement à ce dernier, les critères du système d’évaluation d’opportunités ne sont pas figés et c’est à vous de les choisir.

Par exemple, pour aligner votre feuille de route globale avec votre direction, vous pouvez choisir comme critères l’adéquation à la stratégie produit, la faisabilité, et le potentiel de revenu. Voici à quoi pourrait ressembler une feuille de route priorisée selon ce cadre.

exemple d’Opportunity Scoring

Ici, nous avons utilisé une échelle de 0 à 5 pour noter chaque facteur et calculé la somme de tous les facteurs pour chaque élément de la liste.

Les scorecards dans la vraie vie

Grâce à la flexibilité de sélection des critères, les scorecards sont parfaites pour les réunions d’alignement inter-équipes.

Par exemple, si vous devez aligner votre roadmap avec vos équipes juridiques et sécurité et recueillir leurs avis sur les priorités, vous choisirez des critères pertinents pour elles (ex : risque de litige vs valeur business). Avec votre équipe marketing en revanche, vous pourrez utiliser l’effort, le coût, l’alignement avec les objectifs business, la portée marché et la confiance comme critères d’évaluation.

6. Matrice d’Effort

Vous vous souvenez sans doute de la matrice d’Eisenhower utilisée pour prioriser vos initiatives personnelles ? Eh bien, la matrice d’effort en est une version adaptée à la gestion des nouvelles fonctionnalités produit.

Son nom complet est la Matrice Valeur vs Effort, car elle visualise la relation entre ces deux facteurs pour chacune de vos tâches. Voici son apparence.

exemple de matrice valeur vs effort

Vous placez l’Effort sur l’axe Y, et la Valeur Client sur l’axe X. Ensuite, comme avec la matrice d’Eisenhower, vous la divisez en 4 quadrants et placez chacune de vos fonctionnalités en fonction de leur valeur et de leur effort. Enfin, vous priorisez vos tâches dans l’ordre suivant :

  1. Quick Wins (fonctionnalité à fort impact réalisable tout de suite)
  2. Grands projets (vos fonctionnalités stratégiques majeures)
  3. Compléments (fonctionnalités à implémentation légère à considérer plus tard)

Pour les fonctionnalités qui se trouvent dans le quadrant des gouffres de temps, vous les écarterez généralement car elles n'ont pas lieu d’être dans votre backlog.

Matrice d’effort dans la vie réelle

Le principal avantage et le principal inconvénient de ce cadre résident dans sa simplicité.

C’est un avantage, car vous pouvez facilement expliquer le processus de priorisation aux personnes présentes et commencer à choisir immédiatement les bonnes fonctionnalités.

L’inconvénient, c’est que la matrice d’effort ne met pas en évidence les différents facteurs qui jouent un rôle majeur dans la priorisation (confiance, portée, dépendances, etc.).

Ainsi, le meilleur cas d’utilisation pour ce cadre est lors de courtes réunions d’alignement où les détails ont peu d’importance (car vous organiserez généralement une session plus approfondie, par exemple avec la méthode RICE, en complément).

Alignez vos parties prenantes avec la feuille de route de votre produit

La priorisation de votre travail est importante. Mais elle n’aura aucune valeur si vous n’alignez pas tout le monde autour de vos priorités. De nombreux cadres dont nous avons parlé aujourd’hui sont collaboratifs par nature et vous apportent automatiquement cet alignement.

Cependant, si vous choisissez un cadre qui ne nécessite pas de rassembler tous vos parties prenantes dans la même salle, assurez-vous de partager votre liste de priorités avec les personnes concernées et de l’aligner sur leurs attentes et besoins.

N’oubliez pas de vous abonner à notre newsletter pour d'autres ressources et guides sur la gestion de produit, ainsi que pour recevoir les derniers podcasts, interviews et autres retours d'expérience d'experts et de leaders du secteur.

Suren Karapetyan

Suren Karapetyan, MBA, est chef de produit principal spécialisé dans les solutions SaaS pilotées par l'IA. Il s'épanouit dans le monde dynamique des start-ups en phase initiale et trouve l'adéquation produit-marché pour celles-ci. Son portefeuille est varié, allant d'outils de suppression du bruit pour le télétravail à des logiciels de dédouanement pour des agences gouvernementales.