Kano-model: featureverzoeken sorteren op klantgevoel

Het Kano-model is een manier om features te sorteren op hoe klanten reageren als ze de feature hebben en als ze die missen, in plaats van op hoeveel mensen erom vroegen. Noriaki Kano stelde het in 1984 voor, en het deelt elke feature in een van vijf groepen: basis (must-be), prestatie, aantrekkelijk (verrassers), onverschillig en omgekeerd. Voor een team met een stapel featureverzoeken is het nuttige deel dat het verklaart waarom een verzoek met tientallen stemmen niets toevoegt aan tevredenheid, terwijl een verzoek waar niemand op stemde kan veranderen hoe mensen over het product praten.

Wat zijn de categorieën van het Kano-model?

Basisfeatures zijn die waarvan klanten aannemen dat ze bestaan. Niemand prijst ze en iedereen merkt het als ze kapotgaan. Prestatiefeatures zijn die waarbij meer rechtlijnig beter is, zoals snellere rapporten of hogere limieten. Aantrekkelijke features zijn onverwacht, dus hun afwezigheid kost niets en hun aanwezigheid levert echt enthousiasme op. Onverschillige features bewegen niets in beide richtingen, en omgekeerde features maken sommige klanten blijer als ze worden weggehaald.

De categorie is een eigenschap van een feature voor een groep klanten op een bepaald moment, en daarom kan dezelfde feature voor verschillende segmenten in verschillende groepen vallen.

Hoe voer je een Kano-enquête uit?

Stel per feature twee vragen. De functionele vraag peilt hoe de klant zich zou voelen als het product de feature had. De disfunctionele vraag peilt hoe die zich zou voelen als het die niet had. Beide gebruiken dezelfde vijf antwoorden: ik vind het fijn, ik verwacht het, ik ben neutraal, ik kan ermee leven, ik vind het vervelend.

Combineer de twee antwoorden met het standaard evaluatieraster om per respondent het oordeel over elke feature te classificeren:

M is basis (must-be), O is prestatie (eendimensionaal), A is aantrekkelijk, I is onverschillig, R is omgekeerd en Q is een twijfelachtig antwoord dat zichzelf tegenspreekt. Tel de letters over de respondenten per feature en neem de meest voorkomende als categorie. Liggen twee categorieën dicht bij elkaar, meld dan beide, want een verdeling van 40/38 zegt dat het segment verdeeld is, niet dat één antwoord won.

Welke featureverzoeken horen in een Kano-enquête?

Alleen die je serieus zou overwegen te bouwen en niet op gevoel kunt rangschikken. Vijf tot vijftien features is een werkbare enquêtelengte, en elke feature heeft een beschrijving van één zin nodig die een klant zich kan voorstellen zonder mockup. Haal kandidaten uit je bijgehouden backlog nadat je duplicaten hebt gegroepeerd, want tien verzoeken om hetzelfde horen als één feature in de enquête te komen. De groeperingsstap staat beschreven in featureverzoeken bijhouden.

Laat bugfixes weg, en alles wat al in een contract is beloofd. Een enquête kan je niet vertellen of je een crash moet verhelpen.

Wie moet je ondervragen?

Mensen die het product al gebruiken, opgesplitst naar de segmenten die voor jou tellen. Een enquête naar je hele lijst levert vaak het gemiddelde van meerdere verschillende groepen op, en een gemiddelde verbergt de bevinding. Gratis en betalende gebruikers, nieuwe en langlopende accounts, en kleine en grote teams plaatsen dezelfde feature vaak in verschillende categorieën. Houd de resultaten per segment gescheiden en beslis voor welk segment de volgende release is.

Gebruik de mensen die de verzoeken schreven als startpubliek en voeg een willekeurige steekproef van actieve gebruikers toe, zodat de enquête niet alleen de luidste minderheid bevat. Hoe je de vraag formuleert en verstuurt staat in klantfeedback vragen.

Hoe zet je Kano-resultaten om in een prioriteitsvolgorde?

Bouw in deze volgorde: eerst de gaten in de basis, dan prestatiefeatures waar je achterloopt op de alternatieven waarmee je klanten je vergelijken, dan een of twee aantrekkelijke features per release, en onverschillige en omgekeerde features als laatste of nooit. De volgorde volgt uit wat elke categorie met tevredenheid doet. Een gat in de basis dichten neemt een reden om te vertrekken weg, prestatiewerk verhoogt de tevredenheid gestaag, en een aantrekkelijke feature is waar differentiatie vandaan komt.

Kano zegt welk soort waarde een feature heeft, en niet wat die kost. Combineer de categorie met een inschatting van de moeite voordat de feature op een plan komt. Een scoremethode zoals RICE scoring pakt de kostenkant aan, en de twee werken goed samen: Kano kiest de shortlist en RICE zet die in volgorde. De bredere afweging staat in featureverzoeken prioriteren.

Verschuiven features in de loop van de tijd tussen categorieën?

Ja, en dat is het nuttigste om over het model te onthouden. Aantrekkelijke features schuiven op richting prestatie en daarna richting basis naarmate concurrenten ze kopiëren en klanten eraan wennen. Tweestapsverificatie was ooit een prettige verrassing en is nu een verwachting voor zakelijke software. Een enquêteresultaat is een momentopname, dus herhaal het voor elke categorie waarop je inzet na een jaar, of zodra een concurrent iets vergelijkbaars uitbrengt.

Vertel klanten wanneer je een verrasser uitbrengt. Een feature in de aantrekkelijke categorie verrukt alleen mensen die ervan horen, waardoor de aankondiging deel van de feature is. Die lus sluiten is het onderwerp van een aankondiging voor een nieuwe feature schrijven.

Wat zijn de grenzen van het Kano-model?

Het meet uitgesproken gevoelens, geen gedrag, en kan dus overschatten wat mensen zeggen te willen. Het heeft per segment genoeg respondenten nodig om een patroon te zien, en een paar tientallen is vaak de praktische ondergrens. Het beoordeelt ook features een voor een en zegt niets over hoe ze op elkaar inwerken. Behandel de uitkomst als sterk bewijs voor een roadmapgesprek en leg het naast gebruiksdata en omzet. Voor het omzetten van de gerangschikte lijst in een plan, zie een product roadmap maken.

FAQ

Wat is het Kano-model in gewone woorden? Het is een methode die features indeelt in groepen op basis van hoe klanten zich voelen als de feature bestaat en als die ontbreekt. De groepen zijn basis, prestatie, aantrekkelijk, onverschillig en omgekeerd, en elke groep wijst naar een andere bouwprioriteit.

Hoeveel mensen heb je nodig voor een Kano-enquête? Er is geen vast aantal, maar elk segment dat je apart wilt lezen heeft genoeg antwoorden nodig om een duidelijke meerderheidscategorie te tonen. Een paar tientallen per segment is een gebruikelijk praktisch minimum, en een gespleten uitkomst met minder antwoorden lees je als onbeslist.

Is het Kano-model beter dan RICE? Ze beantwoorden verschillende vragen. Kano classificeert het soort waarde dat een feature klanten geeft, en RICE rangschikt werk op bereik, impact, vertrouwen en moeite. Veel teams gebruiken Kano om de shortlist te bouwen en een scoremethode om die te ordenen.

Hoe vaak moet je een Kano-analyse herhalen? Jaarlijks voor stabiele producten, en eerder als een concurrent een vergelijkbare feature uitbrengt. Verrassers worden na verloop van tijd verwachtingen, dus een oud resultaat kan je naar een feature wijzen die niet meer onderscheidt.

De technische beweringen in dit artikel zijn niet onafhankelijk gecontroleerd. Klopt er iets niet, laat het ons weten, dan corrigeren we het.

Meer op changeloop: Documentatie voor ontwikkelaars, Changelog-tools vergeleken