Modèle de Kano : trier les demandes selon le ressenti client

Le modèle de Kano est une façon de trier les fonctionnalités selon la réaction des clients quand elles sont présentes et quand elles manquent, au lieu de se fier au nombre de personnes qui les ont demandées. Proposé par Noriaki Kano en 1984, il range chaque fonctionnalité dans l’un de cinq groupes : indispensable (must-be), performance, attractive (delighter), indifférente et inverse. Pour une équipe qui croule sous les demandes, son apport utile est d’expliquer pourquoi une demande avec des dizaines de votes peut n’ajouter rien à la satisfaction, alors qu’une demande que personne n’a votée peut changer la façon dont on parle du produit.

Quelles sont les catégories du modèle de Kano ?

Les fonctionnalités indispensables sont celles que les clients supposent présentes. Personne ne les félicite, et tout le monde remarque quand elles cassent. Dans les fonctionnalités de performance, plus il y en a, mieux c’est, de façon linéaire, comme des rapports plus rapides ou des limites plus hautes. Les fonctionnalités attractives sont inattendues : leur absence ne coûte rien et leur présence suscite un vrai enthousiasme. Les fonctionnalités indifférentes ne font bouger rien dans aucun sens, et les fonctionnalités inverses rendent certains clients plus heureux quand on les retire.

La catégorie est une propriété d’une fonctionnalité pour un groupe de clients à un moment donné, ce qui explique que la même fonctionnalité puisse tomber dans des groupes différents selon les segments.

Comment mener un sondage Kano ?

Posez deux questions sur chaque fonctionnalité. La question fonctionnelle demande comment le client se sentirait si le produit avait la fonctionnalité. La question dysfonctionnelle demande comment il se sentirait s’il ne l’avait pas. Les deux utilisent les mêmes cinq réponses : ça me plaît, je m’y attends, je suis neutre, je peux faire avec, ça me déplaît.

Croisez les deux réponses avec la grille d’évaluation standard pour classer l’avis de chaque répondant sur chaque fonctionnalité :

M est indispensable (must-be), O est performance (unidimensionnelle), A est attractive, I est indifférente, R est inverse et Q est une réponse douteuse qui se contredit. Comptez les lettres sur l’ensemble des répondants pour chaque fonctionnalité et retenez la plus fréquente comme sa catégorie. Quand deux catégories sont proches, indiquez les deux, car un 40/38 vous dit que le segment est partagé, pas qu’une réponse l’a emporté.

Quelles demandes de fonctionnalités mettre dans un sondage Kano ?

Seulement celles que vous envisageriez réellement de construire et que vous ne savez pas classer à l’instinct. Cinq à quinze fonctionnalités, c’est une longueur de sondage raisonnable, et chacune a besoin d’une description en une phrase qu’un client peut se représenter sans maquette. Tirez les candidates de votre backlog suivi après avoir regroupé les doublons, car dix demandes pour la même chose doivent arriver au sondage comme une seule fonctionnalité. L’étape de regroupement est décrite dans le suivi des demandes de fonctionnalités.

Laissez de côté les corrections de bugs et tout ce qui est déjà promis par contrat. Un sondage ne peut pas vous dire s’il faut corriger un plantage.

Qui faut-il sonder ?

Les personnes qui utilisent déjà le produit, réparties selon les segments qui comptent pour vous. Un sondage envoyé à toute votre liste produit en général la moyenne de plusieurs groupes différents, et une moyenne masque le résultat. Utilisateurs gratuits et payants, comptes récents et anciens, petites et grandes équipes placent souvent la même fonctionnalité dans des catégories différentes. Gardez les résultats de chaque segment séparés et décidez pour quel segment sera la prochaine release.

Prenez comme audience de départ les personnes qui ont écrit les demandes, puis ajoutez un échantillon aléatoire d’utilisateurs actifs, pour que le sondage ne soit pas seulement celui de la minorité la plus bruyante. La façon de formuler et d’envoyer la demande est dans comment demander un feedback client.

Comment transformer les résultats Kano en ordre de priorité ?

Construisez dans cet ordre : d’abord les manques sur les indispensables, puis les fonctionnalités de performance où vous êtes en retard sur les alternatives auxquelles vos clients vous comparent, puis une ou deux fonctionnalités attractives par release, et les indifférentes et inverses en dernier ou jamais. L’ordre découle de l’effet de chaque catégorie sur la satisfaction. Combler un manque sur un indispensable supprime une raison de partir, le travail sur la performance fait monter la satisfaction régulièrement, et une fonctionnalité attractive est la source de la différenciation.

Kano dit quel type de valeur porte une fonctionnalité, et ne dit pas ce qu’elle coûte. Associez la catégorie à une estimation d’effort avant de l’inscrire dans un plan. Une méthode de scoring comme le scoring RICE traite le côté coût, et les deux se combinent bien : Kano établit la présélection et RICE l’ordonne. La décision plus large est traitée dans comment prioriser les demandes de fonctionnalités.

Les fonctionnalités changent-elles de catégorie avec le temps ?

Oui, et c’est ce qu’il y a de plus utile à retenir sur ce modèle. Les fonctionnalités attractives glissent vers la performance puis vers l’indispensable à mesure que les concurrents les copient et que les clients s’y habituent. L’authentification à deux facteurs était autrefois une agréable surprise et c’est aujourd’hui une attente pour les logiciels professionnels. Un résultat de sondage est un instantané : refaites-le pour toute catégorie sur laquelle vous pariez après un an, ou dès qu’un concurrent livre quelque chose de proche.

Dites aux clients quand vous livrez une fonctionnalité attractive. Une fonctionnalité de la catégorie attractive n’enchante que les personnes qui l’apprennent, ce qui fait de l’annonce une partie de la fonctionnalité. Boucler cette boucle est le sujet de comment rédiger l’annonce d’une nouvelle fonctionnalité.

Quelles sont les limites du modèle de Kano ?

Il mesure des sentiments déclarés, pas des comportements, et peut donc surestimer ce que les gens disent vouloir. Il lui faut assez de répondants par segment pour voir une tendance, et quelques dizaines sont souvent le plancher pratique. Il évalue aussi les fonctionnalités une par une et ne dit rien de leurs interactions. Considérez le résultat comme un indice solide pour une discussion de roadmap, et placez-le à côté des données d’usage et du chiffre d’affaires. Pour transformer la liste classée en plan, voyez comment construire une roadmap produit.

FAQ

Qu’est-ce que le modèle de Kano en termes simples ? C’est une méthode qui range les fonctionnalités en groupes selon ce que ressentent les clients quand la fonctionnalité existe et quand elle manque. Les groupes sont indispensable, performance, attractive, indifférente et inverse, et chacun renvoie à une priorité de développement différente.

Combien de personnes faut-il pour un sondage Kano ? Il n’y a pas de nombre fixe, mais chaque segment que vous voulez lire séparément a besoin d’assez de réponses pour faire ressortir une catégorie majoritaire nette. Quelques dizaines par segment sont un minimum pratique courant, et un résultat partagé avec moins de réponses doit se lire comme non tranché.

Le modèle de Kano est-il meilleur que RICE ? Ils répondent à des questions différentes. Kano classe le type de valeur qu’une fonctionnalité apporte aux clients, et RICE ordonne le travail selon la portée, l’impact, la confiance et l’effort. Beaucoup d’équipes utilisent Kano pour établir la présélection et une méthode de scoring pour l’ordonner.

À quelle fréquence refaire une analyse Kano ? Chaque année pour les produits stables, et plus tôt quand un concurrent livre une fonctionnalité similaire. Les fonctionnalités attractives deviennent des attentes avec le temps, donc un ancien résultat peut vous orienter vers une fonctionnalité qui ne différencie plus.

Les affirmations techniques de cet article n'ont pas été vérifiées de façon indépendante. Si quelque chose est faux, dis-le-nous et nous le corrigerons.

À voir sur changeloop : Documentation développeurs, Comparatif d'outils de changelog