Mark Needham

Thoughts on Software Development

Kano Model: Some ThoughtWorks examples

with 4 comments

My colleague Jason Yip recently linked to the Kano Model and although it’s a theory about product development the definition of what counts as a product seems like it can be quite broad.

The best explanation of the model that I’ve come across so far is a post by Jean Claude Grosjean which Frankie linked me to.

Grosjean describes the three types of requirements like so:

Must Have (“Basic needs”)

These are not always expressed but they are obvious to the customer and must be met…[they] are not a source of satisfaction but can cause major disappointment.

Performance needs (“Linear”)

The need is expressed and customer satisfaction is proportional to the level of performance (and quality) of what is implemented.

Delighters (“Exciters”)

These requirements are not necessarily expressed. Sometimes they’re unconscious.

This is the happy surprise that can make a difference but if they are not there then there won’t be any dissatisfaction or frustration because they’re not expected.

Exciters are the key to innovation.


To work out which category a requirement fits in Grosjean suggests we ask the following two questions:

  • Functional question: “How would you feel if the product had feature X ?”
  • Dysfunctional question: “How would you feel if the product didn’t have feature X ?”

I was thinking about this idea with respect to scenarios inside an organisation.

I’m anaphylactic allergic to dairy products, eggs, nuts and seafood so my general expectation if I go to any event arranged by ThoughtWorks is that I’ll have to work out for myself what I’ll be able to eat.

However, when I first started working at ThoughtWorks UK in 2006 we had an office manager called Vicki Mott who didn’t leave me to fend for myself.

She would call me up or email me before every event she organised, check what I was allowed to eat and then make sure there was something I could eat at the venue.

I never expected anyone to do that so it was certainly a delighter for me.

In this case the ‘product’ is more a ‘service’ being provided by another member of an organisation but I feel that the same theory applies.

Jared Spool explains that what were previously exciters will move to performance needs and then eventually basic needs as time goes on:

One of the predictions that the Kano Model makes is that once customers become accustomed to excitement generator features, those features are not as delightful. The features initially become part of the performance payoff and then eventually migrate to basic expectations.

An interesting example that I can think of which seems to fit this is the way some aspects of travel are dealt with in ThoughtWorks Australia.

In Australia if you are travelling anywhere for ThoughWorks then there will be a driver to drop you to and pick you up from the airport.

When I first saw this it was a delighter for me because I’d never seen anything like it but now it’s become expected which leads to disappointment because we don’t tend to do that in the other countries.

Of course it’s still important that other basic/performance needs are met otherwise the delighters aren’t able to have the same impact but I hadn’t previously thought that much about viewing a service as a product.

Be Sociable, Share!

Written by Mark Needham

March 6th, 2011 at 8:37 am

  • Hi Mark, have not read your blog in a while (some time ago you were focusing on language-specific issues) but today I decided to revisit and here it is a fantastic post.

    The transmutation of exciters into basic requirements is my personal definition of quality. ‘Knowledge’ is a bless and a curse because after we are exposed to a delighter expectations will not be the same. Our standards are therefore defined by what we know, the references we have. The neighbor grass is always greener, right?

    As architects and designers we might unintentionally induce clients to open the Pandora box of creeping featurism. Developers typically have this mentality: the fancier the better. Not always. We need to educate the tastes of our audience in a controlled fashion. Otherwise, as you say, disappointment is guaranteed.

  • Hey Claudio,

    Yeh I’ve noticed that the blog has become much less about language specific issues. I’m not really sure what to write about with respect to languages at the moment – I wasn’t really see that much on the last project I worked on.

    Right now I’m training our graduate program so I guess the blog posts will be much more around that and what I learn from this experience.

    Hopefully the language stuff can make a return after that though – I enjoy writing about code much more than process stuff.

    Interesting observation about creeping featurism. So we need to gradually introduce delighter features and not put them in all at once or we’re going to struggle in the future is what I understand from what you said?

    Makes sense!

  • Hi Mark,

    Yes, I think you got me correctly. Delighters could reflect our own (unconscious?) appetite for experimentation. When we are too deep involved in techie thoughts it is easy to go down this path – all we want is an opportunity to push the limits of what we can do with the tools at hand. And it is generally easy to convince clients (and ourselves) that ‘we must have it’.

    In many cases developing delighter features ‘will require extra 500% effort to handle only 1% of the use cases’ after all ‘exciters are the key to innovation’.

    The Kano model is indeed a nice tool for product investigation – some people working on brand new ideas and trying to identify the tastes of potential customer groups. But I think it would not apply so well to the typical IT project.

  • Hi Mark,

    Just thought about dropping the following quote in this post, it describes the risk behind inducing clients to adopt exciters:

    “Shifting Baseline Syndrome.” This one hit home for me because I was just at a McDonald’s and guiltily ordered a Quarter Pounder With Cheese. I remember when these sandwiches were first introduced and they looked huge at the time. A quarter pound of meat on one sandwich seemed gargantuan. But when my burger arrived and I opened the box, the thing looked puny. That’s because all the other sandwiches on the menu were things like double quarter pounders. My baseline of a normal burger had shifted. Kedrosky shows how these shifts distort our perceptions in all sorts of spheres.