Prioriser les fonctionnalités d’un produit digital est un sujet primordial et complexe. Découvrez dans cet article les différentes méthodes de priorisation utilisées par les équipes design et product.
En effet, la « roadmap product » va déterminer le futur produit, et donc sa pertinence auprès de ses utilisateurs, mais aussi de ses prospects.
Pour certaines startups, c’est leur survie qui est en jeu. Pour des scale-ups, des éditeurs de logiciel plus matures, ou encore des projets portés par des grands groupes, c’est leur développement et leur croissance qui vont être bien souvent portés par cette roadmap.
Or, bien souvent, lorsque l’on interroge des product managers, ou des consultants UX, ils n’ont pas systématiquement un processus très cadré pour planifier et prioriser les fonctionnalités de leur produit digital.
La priorisation va parfois découler directement de la direction, ou bien de l’équipe technique, voire un mélange d’opinions de toutes les parties prenantes.
Or, l’utilisation de frameworks, et la prise en compte de l’utilisateur, vont avoir plusieurs avantages :
- Mettre tout le monde d’accord
- Se baser sur des faits et non sur des opinions
- Créer un produit proche des besoins et des observations d’utilisateur
Pourquoi prioriser les fonctionnalités de son produit ?
Cependant, nous constatons souvent des freins à l’élaboration de la Roadmap product bien cadrées :
- Des managers veulent trouver des solutions aux problèmes d’aujourd’hui, et pas ceux de demain.
- Des managers se concentrent sur des conversations d’opinions, et n’estiment pas toujours nécessaire de baser leurs décisions sur un score ou notation.
- De nombreux produits changent de priorité constamment, et cela dû à des éléments hors de leur contrôle, comme des besoins pour les ventes ou des demandes clients.
- Il n’y a pas un framework de priorisation produit qui fonctionne pour chaque entreprise et secteur d’activité. Chaque entreprise a ses spécificités et facteurs qui impactent les priorités, il faut donc pouvoir s’adapter aux besoins.
Ne pas avoir de méthode claire pour prioriser ses fonctionnalités peut être tentant dans une équipe avec une très forte communication. Cependant, cela pourra rendre la communication complexe avec la direction, ou bien les actionnaires.
De plus, avoir une méthode de priorisation apportera toujours une vision plus “scientifique” et étayée de la priorisation, et permettra de remettre en cause les aprioris et biais de chacun.
Alors, quel framework et comment l’utiliser ? Nous avons compilé les principaux framework produit dans cet article ! 🙂
Les Framework de priorisation
Pour pouvoir les comparer, il est tout d’abord primordial de référencer les principaux framework de priorisation produit :
- Coût VS Bénéfice [COBE]
- ICE & RICE Scoring [RICE]
- Le modèle KANO [KANO]
- Buy-a-Feature [BUYF]
- Story Mapping [STMP]
- MoSCoW [MSCW]
- Valeur VS Complexité [VCC]
- La matrice Eisenhower [EIS]
N’hésitez pas à nous contacter si il en manque un que vous trouvez pertinent 🙂
Comment choisir le bon framework ?
Commencez par vous poser des questions concernant le type de données que vous collectez (qualitatives / quantitatives) et le temps que vous avez pour valider vos hypothèses, afin de choisir le bon framework.
Gardez à l’esprit qu’ils sont une base de travail, que vous pouvez les personnaliser à votre gré.
Coût VS Bénéfice [COBE]
C’est quoi ? Une longue liste de fonctionnalités, avec des caractéristiques, comme le nombre d’utilisateurs impactés, le coût, le risque, l’effort… Chaque critère est noté de 1 à 5 et pondéré en fonction de l’importance de chacun de ces critères.
Avantages : Quantifie l’importance de chaque fonctionnalité et son potentiel retour sur investissement.
Inconvénients : Les “poids” peuvent être manipulés selon les envies des membres de l’équipe. Il faut que l’équipe soit parfaitement alignée sur les notes de chaque critère, qui seront souvent partiellement subjectives.
ICE & RICE Scoring [RICE]
C’est quoi ? Le RICE est un système basé sur 4 critères : Reach (Portée, la largeur des utilisateurs concernés), Impact (impact par utilisateur), Confiance (quelle confiance as-tu dans ton score, généralement en pourcentage), et Effort (on va utiliser 3 notations comme “faible” / “moyen” / “élevé” ). Le score “ICE” exclu simplement le “Reach” de son calcul, ce qui rendra son utilisation plus simple.
Avantages : Aide les équipes qui ont besoin de décider entre des fonctionnalités difficiles à comparer.
Inconvénients: L’impact est une notion subjective qui devra être étayée par des éléments concerts, dans la mesure du possible.
Le modèle KANO [KANO]
C’est quoi ? Développé dans les années 1980 par le professeur Noriaki Kano, il classifie les préférences des utilisateurs en 5 catégories basées sur la satisfaction utilisateur VS la niveau de fonctionnalité.
Avantages : Utilise un raisonnement qualitatif, est très visuel.
Inconvénients : Ne prend pas en compte le coût, effort ou la complexité d’implémentation.
Buy-a-Feature [BUYF]
C’est quoi ? Créez une liste de fonctionnalités potentielles, et mettez un prix en face de chacune. Le prix peut prendre en compte les coûts de développement, valeur pour le client, ou tout ce que vous souhaitez. Les participants à l’atelier “achètent” les fonctionnalités qu’ils veulent pour la prochaine sortie de votre produit, en justifiant pourquoi. Il est possible que certaines fonctionnalités soient plus chères que l’argent d’un participant. Ils doivent donc combiner leurs ressources pour choisir les fonctionnalités les plus importantes.
Avantages : Forte collaboration, visuel et didactique. La contrainte de ressources peut faire aboutir des réflexions très intéressantes.
Inconvénients : Ne prend pas en compte la validation directe de l’utilisateur. Les choix des participants n’est pas forcément le souhait de l’utilisateur final.
Story Mapping [STMP]
C’est quoi ? Un modèle visuel qui permet de voir comment la fonctionnalité entre dans un parcours utilisateur global. La priorité des “stories” est placée de haut en bas, généralement en se basant sur la valeur pour les utilisateurs et le business.
Avantages : Forte collaboration et très visuel. Prend en compte l’expérience globale, dans les parcours existants, et non juste une fonctionnalité isolée.
Inconvénients : Pas de mesure quantitative de l’effort nécessaire pour déployer cette fonctionnalité, il peut être combiné avec un autre modèle de priorisation.
MoSCoW [MSCW]
C’est quoi ? Un modèle qui permet de classifier les fonctionnalités en 4 catégories :
- “Must do”
- “Should have”
- “Could have”
- “Will not have”
Cela permet de s’accorder sur l’importance de chaque fonctionnalité par rapport à l’autre. Très pratique dans un format d’atelier pour définir un MVP (minimum viable product).
Inconvénients : Fonctionne bien lorsque les grandes lignes du produit sont déjà définies, cela permet de s’accorder sur le cœur fonctionnel d’un produit et de se recentrer sur l’essentiel.
Avantages : Une certaine subjectivité, mais ouvre des débats intéressants. De plus, il est possible de baser les décisions sur des insights qualitatifs ou quantitatifs.
Valeur VS Complexité [VCC]
C’est quoi ? Un modèle qui permet aux équipes d’évaluer chaque fonctionnalité en fonction de la valeur qu’elle va apporter et de sa simplicité/complexité d’implémentation.
Avantages : Facile à utiliser pour une priorisation rapide, permet d’identifier les fonctionnalités à fort impact et les “quick wins”.
Inconvénients : Le terme de “complexité” peut être composé de nombreuses choses différentes, il est important d’en avoir une définition commune au sein de l’équipe.
La matrice Eisenhower [EIS]
C’est quoi ? Basé sur les principes du 34ème président des Etats-unis, la matrice d’Eisenhower est un modèle qui permet d’évaluer chaque fonctionnalité en fonction de son urgence. Cela permet à l’équipe produit de prioriser les tâches plus ou moins urgentes, lesquelles déléguer, ou ne pas faire du tout.
Avantages : Facile à utiliser pour une priorisation rapide, si des limites pour chaque quart sont définies (par exemple le budget), cela permet de forcer à prendre des décisions radicales.
Inconvénients : “Urgent” peut être sujet à débat, cela ne doit pas être confondu avec “prioritaire”. Il faut bien répartir les fonctionnalités dans les 4 quarts du tableau pour que celui-ci soit pertinent (ne pas placer 80% des fonctionnalités dans le quart “à faire”).
Conclusion
Finalement, tous ces modèles ne sont pas des méthodologies scientifiques, il faut les voir comme des outils de prise de décision et qui permettent de faciliter les échanges. Ils sont intéressants pour les raisons suivantes :
- Ouvrir un dialogue constructif au sein des équipes
- Inviter tout le monde à participer sur des bases équivalentes
- Prioriser sur une échelle commune
- Remettre des critères objectifs au coeur de la discussion
- Poser un cadre à la créativité
Ces frameworks sont des bases, qui peuvent être adaptées à vos besoins et personnalisés pour les besoins de votre produit et de vos équipes, amusez-vous ! 🙂
Nous sommes disponibles pour échanger autour d’un éventuel accompagnement UX.
