Formulaire de contact
Oops! Something went wrong while submitting the form.
Nous vous répondrons le plus rapidement possible.
Formulaire de contact
Nous vous répondrons le plus rapidement possible.
.png)
Ce n'est pas nouveau, l'un des aspects les plus difficiles du product management est d’établir des priorités. Comment s’assurer que nous nous concentrons bien sur ce qui est essentiel aux attentes utilisateurs ou à la croissance de l'entreprise ?
Dans plusieurs métiers ayant attrait à la gestion de projet, on définit généralement par “prioritaire” une tâche sur laquelle on travaille au regard d’une deadline à respecter avant toutes les autres, ou alors selon l'ordre d’arrivée des e-mails.
Dans le product management, la priorisation est d'un tout autre niveau !
Vous avez généralement une liste de fonctionnalités et de tâches non prioritaires étalée devant vous. Certaines parties prenantes vous disent que la fonctionnalité A serait vraiment opportune et qu'elle vous permettra de passer à la vitesse supérieure. Mais une autre partie prenante clé suggère gentiment d'inclure la fonctionnalité B dans la V1. Et enfin, votre analyste de données est convaincu que la fonction B est totalement inutile et que les utilisateurs réclament la fonction C.
Et c’est au product manager de trancher !
Voici trois méthodes que tous product managers devraient connaître : MoSCow, RICE et Kano.
Connue sous le nom de technique de priorisation MoSCoW ou d'analyse MoSCoW, MoSCoW est une méthode couramment utilisée en gestion de projet Agile.
A la base, il ne s’agit pas d’une méthode pour prioriser les tâches mais d’une méthode de priorisation des exigences fonctionnelles et non fonctionnelles utilisée pour le développement.
Il s'agit d'un outil particulièrement utile pour communiquer aux parties prenantes ce sur quoi vous travaillez et pourquoi.
Le nom est un acronyme de quatre catégories de priorisation :
Must have, Should have, Could have et Won't have.
NB : le "o" de la méthode ne sert qu'à donner un sens à l'acronyme pour faciliter sa mémorisation
Examinons de plus près ce que signifient réellement ces catégories :
Must Have : l’Indispensable
Le terme "Must Have" désigne les fonctionnalités dont vous ne pouvez absolument pas vous passer pour votre lancement ou votre évolution. Cela peut être pour des raisons juridiques, de sécurité ou commerciales.
C’est “indispensable” lorsqu’il s'agit d'un élément qui a été promis à vos utilisateurs et qui est à l'origine de l'engouement suscité par votre produit.
Pour déterminer si un élément peut être qualifié d'indispensable, réfléchissez aux pires et aux meilleurs scénarii possibles pour ne pas l'inclure. Si vous ne pouvez pas imaginer le succès sans cet élément / fonctionnalité, c'est indispensable !
Should Have : Devrait être
Le terme "Should have" désigne les éléments qu'il serait préférable d'inclure, mais sans lesquels vous n'êtes pas voué au désastre.
Ces points apportent une vraie valeur ajoutée et/ou leur importance contribue à l'atteinte des objectifs. La différence avec les Must Have réside souvent dans le fait que leur traitement peut être différé.
Typiquement dans le cadre d’un MVP, on étudiera la complexité de réalisation et/ou la valeur business pour décider d’embarquer, ou pas, l’élément.
Could Have : Pourrait avoir
Les éléments placés dans le Could Have sont ceux plutôt agréables à inclure dans votre produit si vous disposez des ressources nécessaires, mais ils ne sont pas indispensables pour réussir.
La frontière entre "Should Have" et "Could Have" peut être très mince. Pour déterminer la place de chacun, réfléchissez à l'impact de chaque exigence (ou de son absence) sur l'expérience client. Plus l'impact est faible, plus l'exigence est placée en bas de la liste des priorités.
Will Not Have : N'aura pas
Lorsque nous disons "Nous ne l'aurons pas", cela ne signifie pas que cette exigence ne sera JAMAIS intégrée. Ils ne sont pas exclus du projet, mais font partie des points qui restent dans le backlog pour un traitement ou une intégration ultérieure, car à date, les éléments ne génèrent pas assez de valeur du point de vue utilisateur ou pour diverses autres raisons, comme un manque de ressources ou de temps.
Dans tous les cas, matérialiser cet item est important car il vous aide, vous et vos partenaires, à vous mettre d'accord sur ce qui ne sera pas inclus dans la version initiale.
Une autre méthode clé de priorisation est le système de notation RICE.
RICE est l’abréviation de Reach, Impact, Confidence et Effort et permet de définir un score aidant à prioriser les fonctionnalités.
L’utilisation du framework RICE peut avoir de nombreux avantages comme l’alignement des équipes produits lorsqu’il faut prioriser mais aussi une échelle comprise par tous. Le RICE comme le story point est une valeur d’estimation (de prévision).
Voici la définition de chaque Items
Reach
Le premier facteur pour déterminer votre score RICE est d’avoir une idée du nombre de personnes que vous estimez que votre initiative atteindra dans un laps de temps donné.
Vous devez décider à la fois ce que « Reach » signifie dans ce contexte et la période sur laquelle vous souhaitez la mesurer. Vous pouvez choisir n’importe quelle période (un mois, un trimestre, etc.) et vous pouvez décider que la portée fera référence au nombre de transactions client, aux inscriptions à l’essai gratuit ou au nombre d’utilisateurs existants qui essaient votre nouvelle fonctionnalité.
Reach nous aide à nous recentrer sur les clients. Comme pour tout ce qui concerne le produit, veillez à ce que vos réponses soient étayées par des données et non par des idées toutes faites.
Impact
Maintenant que vous avez réfléchi au nombre de personnes que vous allez toucher, il est temps de penser à la manière dont elles seront affectées en tant qu'individus.
L’impact peut refléter un objectif quantitatif, tel que le nombre de nouvelles conversions pour votre projet lorsque les utilisateurs le rencontreront, ou un objectif plus qualitatif tel que l’augmentation de la satisfaction client .
Même en utilisant une métrique quantitative (« Combien de personnes voyant cette fonctionnalité achèteront le produit ? »), mesurer l’impact sera difficile, car vous ne serez pas forcément en mesure d’isoler votre nouveau projet comme la raison principale pour laquelle vos utilisateurs agissent.
Il n'existe pas de véritable méthode scientifique pour mesurer l'impact. L'échelle suivante est la plus démocratisée :
Confidence
On ne va pas se mentir, l’idéal est de se baser sur des datas qui permettent de poser un indice de confiance d’atteignabilité. Mais lorsque nous n’avons pas de datas à disposition, l’idée est de définir un indice de confiance en se projetant sur un modèle empirique.
La « Confiance » de votre score RICE vous aide à contrôler les projets dans lesquels votre équipe dispose de données mais qui s’appuie davantage sur l’intuition. Par exemple, si vous disposez de données pour l’estimation de votre « Reach » mais que votre score d’ « Impact » représente davantage une intuition ou une preuve anecdotique, votre score de confiance aidera à en tenir compte.
Dans les deux cas, l’indice de confiance est un pourcentage que vous allouez à chaque élément pour augmenter leur niveau de priorité ou pour prioriser les éléments pour lesquels vous préférez ne pas prendre de risque.
En général, tout ce qui est supérieur à 80 % est considéré comme un score de confiance élevé, et si vous estimez un score de confiance inférieur à 50 %, considérez cela comme un « moon shot » et supposez que vos priorités doivent être ailleurs.
Effort
Dans cet item, l’objectif est de penser “complexité” à résoudre la tâche / atteindre l’objectif. Pensez alors à la quantité de travail qu'un membre de l'équipe peut faire en un mois. Estimez la quantité de travail nécessaire à chaque membre de l'équipe travaillant sur le projet.
Plus le temps alloué à un projet est important, plus la portée, l'impact et la confiance devront être élevés pour que l'effort en vaille la peine.
Vous aurez besoin des informations de toutes les personnes concernées (Métiers, développeur, ingénieurs, etc.) pour calculer l'effort.
En conclusion, vous obtenez une matrice complète représentant l'ensemble des éléments nécessaires pour calculer votre RICE score
Vous devriez maintenant avoir quatre chiffres représentant chacune des 4 catégories. Pour calculer votre score RICE, il suffit de multiplier Reach par Impact, puis par Confidence. Divisez ensuite par Effort.
Votre score final représente "l'impact total par temps travaillé". Plus le chiffre est élevé, plus vous êtes proche de l'impact élevé/du faible effort.
NB important : Le score RICE sert à ouvrir les discussions sur les priorisations mais ne doit pas être pris directement au pied de la lettre
Le modèle de Kano, créé par Noriaki Kano en 1984, est une approche permettant de séparer la satisfaction et la non satisfaction au regard de la présence ou non de la fonction attendue par le client/utilisateur
Le modèle de Kano est mieux représenté par un graphique :
Définition des 3 grandes catégories :
“Attractif”
représente les caractéristiques que les clients/utilisateurs percevront comme allant au-delà de leurs attentes. Ce sont les éléments qui vous permettront de vous différencier de vos concurrents.
Proportionnel
Classe les fonctionnalités qui, plus elles seront développées et abouties, plus elles généreront de la satisfaction.
“Obligatoire”
Représente sans surprise le minimum attendu par les clients pour résoudre leurs problèmes. Sans elles, le produit leur est pratiquement inutile.
Pour savoir comment les clients apprécient certaines caractéristiques, utilisez des questionnaires demandant comment leur expérience de votre produit changerait avec ou sans elles et classez les fonctionnalités dans la matrice, et placez les dans la matrice suivante.
L'idée principale du modèle de Kano est que plus vous vous concentrez sur les caractéristiques comprises dans ces trois fourchettes surlignées.
NB : Il est important de procéder à des réévaluations périodiques, car il se peut que des fonctions qui étaient auparavant des "merveilles" se rapprochent des "fonctions de base" à mesure que la technologie progresse et que les clients s'y attendent par défaut.
Ces 3 cadres de hiérarchisation ne sont ni normatifs, ni figés. Un modèle différent conviendra à des situations différentes, et là encore, c'est à vous de faire ce choix.
Le modèle de Kano est utile pour prendre des décisions centrées sur le client et se concentrer sur son plaisir, mais il peut prendre du temps pour réaliser tous les questionnaires nécessaires pour que vos idées soient précises et justes.
Beaucoup de gens apprécient le système de notation RICE car il prend en compte la confiance de manière qualitative, mais il reste beaucoup d'incertitudes.
MoSCoW se concentre sur ce qui compte à la fois pour le client et les parties prenantes, ce qui est particulièrement utile pour les chefs de produit qui ont du mal à gérer les attentes des parties prenantes. C'est également la méthode la plus simple à comprendre pour les parties prenantes non techniques.
Gardez en tête que le but de la priorisation est de consacrer du temps aux tâches importantes, à celles qui feront une différence à long terme et vous feront avancer dans la bonne direction.
L’objectif est d’achever un travail qui représente un véritable progrès, et de laisser tout le reste, toutes ces « occupations moindres », derrière vous
Bien entendu, il ne s'agit pas des trois seules méthodes existantes. Chaque projet implique des contraintes différentes, libre à vous de tester et de trouver ce qui fonctionne pour vous et votre produit.
Besoin d’échanger sur le sujet ou d'être formé/accompagné, prenez rdv.
Abonne toi à notre newsletter pour recevoir l’essentiel de l’actualité Design toutes les deux semaines dans ta boîte mail !
.png)
.png)
