Any views expressed within media held on this service are those of the contributors, should not be taken as approved or endorsed by the University, and do not necessarily reflect the views of the University in respect of any particular issue.

The Kano model: Helping us think about the value of features

In recent months I’ve been investigating the Kano model, which is a way to plan and prioritise features of a product to better meet user expectations. After discussing with the team, we decided to try it out through the planning process for some upcoming EdWeb CMS features.

We received funding this autumn to deliver new features in EdWeb that are intended to facilitate greater interaction with visitors to the website – social media sharing features and ‘rate this page’-type functionality.

The initial brief was quite open though. How do we identify the core set of essential features, and beyond that the extras that are likely to be most cost-effective while delivering greatest levels of satisfaction to the web publishing community?

Enter the Kano model.

In this post, I’ll give you an introduction to the Kano model, provide links to learn more, and then outline our experiences using a prioritisation process based around it.

What is the Kano model?

The Kano model is a theory of product development and customer satisfaction developed in the 1980s by Professor Noriaki Kano, which classifies customer preferences into five categories.

Wikipedia definition of the Kano model

The Kano model can help us predict the reaction of users to key elements of a product. It also provides an explanation as to why users are initially delighted and why their delight fades over time.

Kano model graph

The three main groupings of the Kano model: Attractors (Excitement Generators), One-dimensional features (Performance payoff), and Must-have features (Basic expectations)  (Image source:


Learn more about the Kano model

Rather than try to explain the model, I’d recommend the following materials which are among the best I came across when reading up on the Kano model:

Video title still from Jared Spool's presentation

Jared Spool’s session covers how to build a strategy that solves real problems, not just adds new features. (Image source:

There is always more to build than you have the time, people and money for.


Jeff Patton, author of User Story Mapping

What we did

Brainstorming, rationalising and discussing

We’ve had these features in the pipeline for a long time, and had background research already. So we had a fair idea of the kinds of things we might do. But it has been clear from the outset that with the funding available we were only ever going to be able to do a subset of this list.

Five of the team got together to take part in a mini-workshop for about an hour and a half. Together we represented the editorial, support and tech development elements of our team.

The first thing we did was brainstorm the features we might expect to see. Everyone wrote their own items independently and expressed them in terms of what a CMS user or a website visitor would want to do. Essentially very quick and rough user stories.

Together we then sorted the post-it notes we’d written individually; de-duplicating, clarifying, rephrasing and discussing them as we put them on the wall in groups that made sense to us. We find this is a very quick and productive way to sort out our potential requirements and get everyone to a common level of understanding.

This process is far quicker, more effective and more enjoyable than collaborating in the drafting of a requirements document.

Mapping to the Kano model

So at this stage we had a 2 sets of post it notes, each in subgroups; one for social media sharing and one for ‘rate this page’ functionality. The descriptions were rough, but they were commonly understood as we’d spent the past half hour creating and refining them together.

We split into two groups and started mapping the post-its to a graph which used the scales:

  • Low impact to high impact
  • Low cost to high cost
Kano model

Over time, attractive features become must-haves. We also tried working with these axes. (Image source:

(We actually had one group trying a slightly differently pair of axes as different articles I’d read proposed different things. One group tried ‘Low satisfaction (disgust)’ to ‘High satisfaction (delight)’ and ‘Absent (wouldn’t miss it)’ to ‘Best of breed’. These axes had additional descriptive points on the scale too. On reflection, after the exercise we found this version slightly more difficult to work with.)

So, by doing this mapping exercise we placed each of the feature requirement into one of the three region categories of the Kano model:

  • Must-have features
  • One-dimensional features
  • Attractive features

What also happened as we did this was that new ideas came out about how we could practically do less or more with a particular feature, which would make it more technically difficult (or easier) and would (we assume) hold a different level of expectation or appeal for the CMS user.

So the mapping process helped us to discuss the nature of the features once again, refine our descriptions and break functionality down into smaller chunks that we may or may not deliver.

Collaborating with post it notes on a wall

Stratos and Bruce map potential social sharing features to the Kano model


Group discussion at wall of post it notes

Presenting our work back to the wider group facilitated better shared understanding of potential features and how we felt the CMS user group would perceive them.


At the end of this session, I was very pleased how smoothly it had gone, considering we’d never attempted it before. (Admittedly, it helps working with a group of people who all know their roles, and are familiar and comfortable with workshop collaboration exercises).

Using the Kano model gave us the opportunity to expose our potential project deliverables to another dimension; that of how they fit into user expectations. This has helped a lot in prioritising work and defining the MVP (minimal viable product).

Stratos Filalithis, Project Sponsor


From Kano to a development roadmap

A few days later, Bruce and I got back together to review the Kano graphs we’d produced and turn them into user story maps which would help Bruce to plan the order of the features we introduce to EdWeb.

Following the method outlined in Sophie Dennis’ slide deck, we:

  1. Mapped the stages a CMS user would go through in the process of using the functionality
  2. Assigned the features we’d identified as must-have features, as these would be the ones we need to deliver first (the ‘product backbone’ as Jeff Patton would put it)
  3. Worked through the one-dimensional and the attractive features which could form the basis of subsequent releases
Post it notes mapped to a Kano model graph on a sheet of paper

Once we’d identified and grouped potential features, we mapped them to this Kano model graph


Post it notes on a wall, representing a draft product roadmap

Bruce and I translated our CMS features from the Kano model to this roadmap.


Using the Kano model together in a workshop environment was a great way to discuss and quickly and easily evolve potential requirements. We got a common understanding of what we thought we needed and our priorities, which made it easier to write full user stories for development.

Bruce Darby, Product Owner & Project Manager

Next steps

Being able to properly map will go into each release relies on us understanding how long each feature is going to take to develop.

Bruce is now working with Billy and colleagues in IS Applications Division to estimate the cost of each feature development. With this detail, he will be able to establish how many of the features we’ve planned out we’ll be able to deliver, and when.

We’re also beginning a process of engagement with the CMS user community and project sponsors to validate our assumptions about what are must-have, one-dimensional and attractive features. The collaborative, user-focused approach we’ve taken makes it easier to express the work we plan to do through narrative and mock-ups. This is being shared for comment via the development wiki.

Interested in workshops and Kano to help plan your product strategy?

Get in touch if you’d like advice on running similar sessions yourself, or to get me to facilitate it for you.

Remember – this approach will work for any kind of features of a product or a service. So while our story here is about new software features, we could have used it for website content development, or user support and training, or event management.

Neil Allison’s profile and contact details


2 replies to “The Kano model: Helping us think about the value of features”

Leave a reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>


Report this page

To report inappropriate content on this page, please use the form below. Upon receiving your report, we will be in touch as per the Take Down Policy of the service.

Please note that personal data collected through this form is used and stored for the purposes of processing this report and communication with you.

If you are unable to report a concern about content via this form please contact the Service Owner.

Please enter an email address you wish to be contacted on. Please describe the unacceptable content in sufficient detail to allow us to locate it, and why you consider it to be unacceptable.
By submitting this report, you accept that it is accurate and that fraudulent or nuisance complaints may result in action by the University.