De AI Kano Model Analist skill voor Claude

Het probleem dat de skill oplost herken je waarschijnlijk uit je eigen roadmapoverleg. Alles op de lijst voelt belangrijk, want iemand heeft er een goed verhaal bij. De feature waar het team het meest trots op is, blijkt de klant niet te zien. De feature die de klant simpelweg verwacht, krijgt een applausronde als hij eindelijk werkt. En ergens onderaan staat iets dat capaciteit opeet zonder dat iemand kan uitleggen wat het oplevert. Het Kano model zet daar een ordening tegenover die uit één inzicht volgt: tevredenheid is geen lineaire functie van features. Sommige functies leveren niets op als ze er zijn en veel schade als ze ontbreken. Andere doen precies het omgekeerde.

Dit bestand is geschreven voor product- en marketingteams, oprichters die hun MVP-scope moeten kiezen, en iedereen die met een lijst functies zit en moet beslissen wat eerst gaat. De aanleidingen die het bestand zelf noemt zijn typisch: kiezen tussen features, discussies over MVP-scope, roadmapplanning, het opzetten van een klantenquete en het formuleren van het vragenpaar. Hij hoort thuis in de dienst AI en automatisatie, waar we dit soort werkwijzen ook echt inrichten voor bedrijven.

Eén ding moet je vooraf weten. Kano voorspelt tevredenheid, geen omzet en geen conversie. Beloven dat een wow-feature tot groei of retentie leidt, doet hij dan ook uitdrukkelijk niet. Wat je terugkrijgt is een ordening van je lijst en een onderbouwd advies over volgorde, meer niet. Dat is minder dan een businesscase en veel meer dan een stemronde.

Must Be, de basisfeatures. Klanten verwachten dat het er is. Aanwezigheid levert geen tevredenheid op, afwezigheid levert sterke ontevredenheid op. Het voorbeeld in de skill is het schone beddengoed in een hotel: niemand prijst je ervoor, maar als het ontbreekt is de review verwoestend. De consequentie voor je roadmap is contra-intuitief: je bouwt deze features eerst, tot het niveau dat de klant verwacht, en geen stap verder. Extra investeren in een Must Be levert geen extra tevredenheid op.

One Dimensional, de prestatiefeatures. Tevredenheid stijgt lineair met de mate waarin de feature aanwezig is. Meer is beter. Denk aan laadtijd, accuduur of prijs. Op deze categorie kun je echt winnen, en precies daarom adviseert de skill er twee of drie uit te kiezen en niet acht. Lineair betekent namelijk ook: elke stap kost weer evenveel als de vorige.

Attractive, de wow-features. Klanten verwachten het niet. Aanwezigheid creëert sterke positieve emotie en loyaliteit, afwezigheid is geen probleem. Het voorbeeld uit het bestand is het handgeschreven kaartje bij een online bestelling. De regel die de skill eraan hangt is scherp: één of twee tegelijk, klein gehouden, want ze zijn goedkoop in scope en duur in aandacht.

Indifferent, de neutrale features. De klant geeft er niets om. Of het er is of niet, het maakt geen verschil. Vaak zijn dit interne features waar het team trots op is maar die de klant niet ziet. Volgens het bestand is dit de categorie waar de meeste capaciteit stilletjes verdwijnt, en het advies is dan ook eenvoudig: schrappen of parkeren.

Reverse, de omgekeerde features. Aanwezigheid leidt tot ontevredenheid. Te veel notificaties, te veel onboardingstappen, functies die vooral in de weg zitten. Actief verwijderen of per segment uitzetbaar maken, want wat de ene groep als Reverse ervaart, kan voor de andere een wow-feature zijn.

Er is nog een zesde uitkomst, en die is geen categorie: Q van Questionable. Die verschijnt als de twee antwoorden elkaar tegenspreken. Daar mag hij dan ook niets van maken. Hij stelt de vraag opnieuw of markeert de feature als onbepaald, en dat is een uitkomst en geen probleem.

In diff-vorm, met regels uit het voorbeeld van de skill: hoe een roadmapzin verandert zodra hij uit de tabel komt in plaats van uit de vergaderkamer.

Daarna volgt het framework zelf: de vijf categorieën met per categorie een voorbeeld, en het dynamische principe Kano Drift als apart onderdeel. Pas daarna komt de werkwijze, en die telt zeven stappen. Stap 1 is de featurelijst opstellen of uitvragen. Stap 2 is de context ophalen: wie is de klant, welk segment, welke fase van de productlevenscyclus, welke concurrenten. Stap 3 is het vragenpaar, dat de skill het functional pair noemt: de functionele vraag hoe je je voelt als de feature er wel is, en de disfunctionele vraag hoe je je voelt als hij er niet is. Beide antwoorden gaan op dezelfde vijfpuntsschaal.

Stap 4 is de belangrijkste, en de instructie is daar opvallend streng geformuleerd: combineer de twee antwoorden in de evaluatietabel van Berger uit 1993 en lees de categorie af. Je interpreteert niet zelf, je leest af. Stap 5 bepaalt per feature het effect op klanttevredenheid, de prioriteit en de ontwikkelactie. Stap 6 controleert op Kano Drift, met de concrete vraag of deze feature de komende twee jaar naar een andere categorie verschuift. Stap 7 levert een roadmap met vijf concrete acties met tijdlijn, inclusief wat je actief schrapt.

De tabel zelf staat voluit in het bestand, en die zie je in FIG.03 hieronder terug. Er staat ook een instructie voor meerdere respondenten: tel per feature hoe vaak elke categorie voorkomt en neem de meest genoemde, en ligt het dicht bij elkaar, zeg dan dat er geen eenduidige categorie is. Optioneel, als er genoeg respondenten zijn, mag de skill de twee coëfficiënten van Berger berekenen. De tevredenheidscoëfficiënt is A plus O gedeeld door A plus O plus M plus I, en de ontevredenheidscoëfficiënt is O plus M gedeeld door dezelfde noemer. Hoe dichter bij 1, hoe sterker het effect.

Verder ligt de outputstructuur vast in vijf onderdelen: een contextsamenvatting van drie tot vijf regels, de classificatietabel met per feature het functionele en disfunctionele antwoord, de categorie, de ontwikkelactie en de drift, daarna de prioriteit per categorie, dan de Kano Drift waarschuwing en tot slot de vijf acties met tijdlijn. Het bestand sluit af met zeven weigeringen, vijf grenzen van het model en vijf bronnen. Wil je zelf zo'n bestand leren schrijven, dan legt SKILL.md schrijven die opbouw stap voor stap uit.

Nog een detail dat de moeite waard is, want het is precies het soort regel dat de meeste AI-antwoorden missen: heb je geen echte enquetedata, dan schat de skill de antwoorden in op basis van de klantcontext die jij geeft, en zegt hij er expliciet bij dat het een inschatting is en geen meting. Hij doet dus wel iets zonder onderzoek, maar hij noemt het niet anders dan het is.

De methode komt van Noriaki Kano. Samen met Seraku, Takahashi en Tsuji publiceerde hij in 1984 het artikel Attractive Quality and Must-be Quality in het Journal of the Japanese Society for Quality Control. Dat is de bron van het kernidee: kwaliteit is niet één schaal. Er bestaat kwaliteit die je moet hebben, kwaliteit waarin je beter kunt worden, en kwaliteit die verrast. Dat onderscheid klinkt vanzelfsprekend tot je een roadmap voor je hebt waarin alle drie door elkaar staan.

De evaluatietabel komt van Berger en collega's. Hun artikel Kano's Methods for Understanding Customer-defined Quality uit 1993 leverde de werkwijze die deze skill letterlijk overneemt: het vragenpaar, de vijfpuntsschaal en de kruistabel uit FIG.03. Ook de twee coëfficiënten komen daarvandaan. Dit is de reden dat de instructie zegt dat je afleest en niet interpreteert: de vertaalslag van antwoorden naar categorie is vastgelegd, niet aan de analist.

De toepassing in productontwikkeling komt van Sauerwein, Bailom, Matzler en Hinterhuber. Hun paper The Kano Model: How to Delight Your Customers uit 1996 beschrijft hoe je het model in de praktijk inzet, en Matzler en Hinterhuber koppelden het in 1998 in Technovation aan Quality Function Deployment. Daar komt de nadruk vandaan op wat je met de uitkomst doet, dus de ontwikkelactie per categorie in plaats van alleen een label.

De kritiek komt van Witell en Löfgren. Classification of Quality Attributes uit 2007 gaat over de zwakke plekken en de betrouwbaarheid van de methode, en het is veelzeggend dat een skill die het model wil gebruiken zijn eigen criticus in de bronnenlijst opneemt. Die kritiek zie je terug in de grenzen verderop: het model meet gestelde voorkeur en niet gedrag, en kleine steekproeven geven schijnzekerheid.

Ook zonder de skill te installeren kun je met deze principes je eigen lijst opschonen: stel per feature beide vragen, kijk waar de twee antwoorden je brengen, en durf op te schrijven wat je niet gaat bouwen. Leg je het model naast andere prioriteringsmethoden, dan is de RICE Prioritering skill de logische tweede blik, want die rekent met bereik en inspanning waar Kano alleen naar tevredenheid kijkt.

Daarna is het gebruik simpel: plak je featurelijst en beschrijf erbij voor wie je bouwt, in welke fase je zit en wat concurrenten standaard bieden. Die vier stukken context zijn geen formaliteit, want de skill weigert te analyseren zolang ze ontbreken. Heb je echte enquetedata, geef die dan mee als antwoordparen per respondent: dan telt de skill de categorieën en neemt hij de meest genoemde in plaats van te schatten. In de kennisbank staat de bredere uitleg over werken met AI.

Er zijn ook situaties waarin je hem beter laat liggen. Voor een algemene sterkte-zwakteanalyse of generieke prioritering is dit het verkeerde instrument, en dat zegt het bestand zelf in de frontmatter. Voor de marktkant kun je beter beginnen bij de SWOT-analyse skill, en voor de vraag of het verdienmodel eromheen klopt bij de Business Model Canvas Coach skill.

Daarnaast staan er vijf grenzen van het model zelf in, en die zijn eerlijker dan je van een instructiebestand zou verwachten. Het model meet gestelde voorkeur, niet gedrag. Wat mensen zeggen over een feature die nog niet bestaat, wijkt vaak af van wat ze doen als hij er is. De categorieën zijn momentopnames. Kano Drift is volgens het bestand geen randopmerking maar de belangrijkste beperking van het model. Delighters zijn moeilijk uit te vragen, want een klant kan niet verlangen naar iets dat hij zich niet kan voorstellen: vul die kant aan met observatie en met klachten over het huidige werkproces.

Het model zegt niets over kosten, haalbaarheid, technische afhankelijkheden of juridische verplichtingen, dus leg de uitkomst daar altijd naast. En kleine steekproeven geven schijnzekerheid: onder ongeveer twintig respondenten per segment praat je over signalen, niet over categorieën.

Die laatste grens verdient een waarschuwing die de skill zelf al geeft maar die makkelijk wegvalt in de nette tabel. Als je zonder respondenten werkt, staat er in de output dat het een inschatting is. Neem die zin serieus. Een ingeschatte categorie is een gestructureerde aanname, geen meting, en de tabel eromheen maakt hem niet waarder. Wil je de aannames onder je product eerst toetsen bij echte klanten, dan is de MOM Test Coach skill daarvoor gemaakt: die leert je vragen stellen waarop mensen niet beleefd kunnen liegen.

Je kunt de perfecte features bouwen en toch onzichtbaar blijven. Wordt je product nauwelijks gevonden, dan is dat het probleem voor de roadmap, niet erna. De gratis SEO scan laat in enkele seconden zien waar je site staat. En wil je doorpraten over wat AI verder voor je bedrijf kan doen, van losse skills tot volledige automatisering, dan doen we dat gewoon in een gesprek.