KANO ? Késako ...

KANO ? Késako ...

Introduction et contexte

Il y a un peu plus de quatre ans maintenant nous avions monté la première formation Officielle Product Owner chez Thales avec Thierry Conter et Patrick Barroyer.

Nous avions déjà d’excellentes formations de 3 jours pour les ingénieurs dans lesquelles nous abordions déjà le rôle du Product Owner et quelques outils.

Un slide en particulier parlait du modèle de Kano, je le présentais assez rapidement, n’ayant jamais expérimenté cette démarche, n’ayant pas pris la peine de creuser le sujet. Honnêtement, je pense que personne en sortie de formation à l’époque n’a pu percevoir le potentiel de ce modèle et en quoi il était utile ...

Vive l’amélioration continue !

Pour la formation Product Owner, j’ai eu l’occasion de creuser le sujet.

Pourquoi exhumer cela aujourd’hui ? tout simplement parce que c’est un outil qui a parfaitement sa place dans des démarches de Design Thinking, de LeanStartup, de Business Modeling, et vous le comprendrez j’espère en lisant l’article.

Késako Kano ?

Le modèle de Kano classe les fonctionnalités dans différentes catégories que nous allons découvrir une par une grâce à des schémas comprenant deux axes :

  • un axe satisfaction client
  • un axe qui représente le degré de réalisation d’une fonctionnalité (est ce que la fonctionnalité est implémentée un peu , beaucoup, passionnément, à la folie, pas du tout).

(Il est assez facile d’illustrer tout cela au travers de l’évolution du marché des téléphones portables, j'ai rapidement jeté une ou deux idées entre parenthèses)

1 . Première catégorie : les fonctionnalités essentielles ( par exemple une gestion des contacts ?)

2 . Ensuite, il y des éléments de performance ( la puissance, la taille de stockage, la qualité de l'appareil photo ?)

3 . Il y a aussi des fonctionnalités attractives (Tango, waterproof ?)

4 . Il y a bien sur des éléments indifférents (je n’ai pas d’exemple qui me vienne rapidement, peut être telle ou telle application installée par défaut ?)

 5 . Il y a des éléments non désirés (si les fabricants de Smartphone ont bien fait leur travail, nous ne devrions pas trouver d’exemple, qu’en pensez-vous ? nous verrons plus loin que cela dépend de chaque individu, il est possible que je sois insatisfait d’une application installée par défaut pour reprendre l’exemple précédent ou d’une surcouche bancale d’un OS standard mais que cela puisse plaire à d’autres personnes)

Attention, ça bouge !!

Jusqu’ici, c’est assez simple non ? Alors ajoutons un premier élément à bien garder en tête et qui apporte un peu de complexité : cela bouge dans le temps :

Un appareil photo sur un téléphone pouvait être attractif pour une majorité il y a plus de 10 ans, c’est maintenant sans doute passé : pour certains, en éléments de performance (course aux pixels, stabilisateurs, traitement d’image) et en fonctionnalité essentielle pour d’autres.

Attention, votre utilisateur vous cache des choses !

Petit focus sur ce que nous pouvons déduire de tout cela sur les exigences ? Les besoins ?

Incroyable, il y aurait des non-dits, du spécifique, du transcendant ... que nous nous devons d’aller explorer !

How To Kano ?

Biais et pièges

Comme vous le voyez, la théorie est assez facile à comprendre, rien de bien nouveau ou de contre intuitif, le modèle se base sur du bon sens. Comme tout modèle, il n’est pas parfait, il a des défaut, il n’est pas exact, et comme tout bon modèle, il est très utile pour guider, aider à avancer.

Mais au fait comment pouvons nous nous en servir ? Comment avancer concrètement grâce à ce modèle ?

Là, il n’y a pas de secret, il va falloir sortir du building et aller à la rencontre des utilisateurs (actuels, potentiels, etc.).

Nous allons leur démontrer quelque chose (pretotyping, POC, prototype, MMF, etc.), les questionner puis analyser leurs réponses (ça vous rappelle forcément des démarches de développement de produit, learning cards, UX Design, etc.)

Là où ce modèle est intéressant c’est qu’il implique une certaine façon de faire pour le questionnement.

En effet, si vous posez la question suivante :

Comment qualifieriez-vous l’importance de cette fonctionnalité ?

Vous vous rendrez rapidement compte que vous venez de faire une erreur assez courante : vous n’avez questionné que sur une perspective unique, et vous ne savez pas trop comment exploiter les résultats. Si un utilisateur vous donne une note de 1 à cette question, que pouvez vous en déduire ? Pas important et pourquoi pas ou bien pas important et je n'en veux surtout pas ?

 Le modèle Kano nous rappelle là simplement trois choses importantes :

1. Trouver les bonnes questions est fondamental.

Si vous avez l’habitude de faire des sondages, des questionnaires clients, et/ou si vous animez des séminaires, des ateliers de travail (world café, fishBowl, etc.), vous connaissez l’importance de la formulation des questions. Cela doit vous prendre du temps et c’est normal.

2. Il faut faire exprimer des sentiments

La question « Est-ce que cette fonctionnalité vous semble importante ? » vous apportera des éléments sur du non désiré, de l’indifférence ou de l’essentiel.

La question « Que ressentez-vous si cette fonctionnalité est présente ? » Permet de toucher les aspects attractifs et de performance (« non-dits », vous vous rappelez ?)

3. Il faut sortir de la perspective unique

Ce sont les résultats croisés qui permettront de catégoriser les fonctionnalités comme nous le verrons un peu plus loin.

Une perspective unique n'apporte pas une grande aide à la décision/priorisation


A minima, il faut donc aussi chercher du côté de l’insatisfaction :

Cela permet un premier travail de classification et apporte des données intéressantes dans une démarche de valorisation métier.

Avec le modèle de Kano, vous pouvez démarrer avec les deux questions qui sont ci-dessous, la table d’évaluation qui suit vous aidera dans l’analyse des résultats :

«  Que ressentez-vous si cette fonctionnalité est présente ? »
«  Que ressentez-vous si cette fonctionnalité est absente ? »

Catégories d’interviewés / Personas

Nous avons déjà vu que la catégorisation pouvait bouger dans le temps ... eh bien, j’ai une autre bonne nouvelle :), ... elle dépend de chaque individu.

Une bonne pratique sera de s’interroger sur les différents types d’utilisateurs visés par votre service ou produit et de créer des personas par exemple qui vous aideront à classifier vos résultats et à analyser les sorties de votre démarche.

Exemple de couplage de la table de Kano avec deux catégories d’utilisateurs (personas)

(E = Essentielle, P = Performance, A = Attractive, I = Indifférence, N = Non désiré, Q = "Questionnable" )

Voilà pour cette introduction au modèle de Kano qui est loin d’être parfaite, mais qui apporte, je l’espère, assez d’éléments pour une meilleur compréhension du modèle.

J’espère que cette lecture aura été utile pour vous … à propos qu’avez-vous pensé de cet article ?

ne cherchez pas à cliquer ... c'est une image :) Et puis rappelez vous que la perspective unique ne rapporte pas suffisamment d'informations.

Explorez les sentiments,  évitez les perspectives uniques.

C’est ce que font plutôt bien des outils de recueil de feedback comme le perfection game, le delta plus, etc.

D'ailleurs, qu’avez-vous apprécié dans cet article ? Qu’avez-vous ressenti en le lisant ou parcourant ?

Quels axes, idées mériteraient d'être encore plus détailler ? Qu’auriez-vous enlevé, simplifié ?

François-Xavier Maquaire

CPO - wedolow.com - Améliorez de 40% la performance de vos logiciels embarqués !

7y

Ce billet est devenu une conférence : https://es.slideshare.net/fxMaq/kano-un-outil-pour-product-owner (avec quelques petits ajustements :) à vous de les trouver)

Like
Reply

To view or add a comment, sign in

Others also viewed

Explore topics