How 2 simple questions can help shape your product roadmap

I read with some sadness recently that Apple are discontinuing the iPod shuffle, their stripped down digital music player. I guess in an age where everyone carries a digital music player in the form of a smart phone this is hardly surprising, but I think it’s a real shame because the iPod shuffle is such a fantastically well designed product. It’s a great product not so much because of what it does, but rather surprisingly because of what it doesn’t do. Let me explain.

I have a trusty, rather beat up iPod shuffle (shown below), which I still use on a regular basis. I use it in the gym because I don’t want my precious iPhone getting damaged. I use it when I’m out jogging because it’s so lightweight and weatherproof. I use it when I’m out and about because I don’t want to fill my precious iPhone memory with stored music (I’ve given up hope on Apple providing the option of adding memory through a microSD card).

Image for post
Image for post
My trusty little iPod shuffle

I love my little iPod shuffle, I really do. It’s incredibly light and portable, and can be clipped to your clothes to keep headphone wire dangle, and therefore the risk of sudden and unexpected earphone yanks to a minimum. It goes all week without having to be charged and holds just enough music to stop things from going stale. It does all these things because it lacks one thing that pretty much every other digital music player out there (including smart phones) have — a screen. Sure the absence of a screen makes selecting a specific track, playlist or album very tedious but then that’s not really the point of the iPod shuffle. Load it up with your favourite tunes and let the little dude randomly choose which ones to play. The absence of a screen not only makes for a very cheap and portable device, with a great battery life, but in some ways it actually enhances the user experience. You can avoid the dreaded paradox of choice — the trauma of having to choose from all the music available to you, by letting your trusty little iPod shuffle decide for you.

You see thinking about what a product or service shouldn’t offer, is a great way to help shape your roadmap. Too many product teams obsess over how users will react to a new feature, when a better starting question would be, “How might users feel if they didn’t have this feature?”. If you were designing a digital music player, a screen would probably be at the top of your feature list, but the iPod shuffle product team rightly identified that a screen wasn’t a must have feature. Indeed, in a lot of ways not having a screen actually made for a more compelling product.

Being prepared to say ‘No’ to new ideas and features can feel uncomfortable, even confrontational sometimes, but it’s important if a product or service is going to remain focused on what is most important to users. As Steve Jobs once said:

Image for post
Image for post

I’ve found that asking teams to think about how users might feel if they didn’t have a feature, as opposed to just considering how users might feel if they did have a feature is a better gauge of how important that feature is. If users aren’t going to miss a feature if it isn’t there, or indeed, aren’t using an existing feature then it isn’t necessary, it’s as simple as that.

The kano model

The Kano Model is a great way to get teams thinking about how users will react to features, or perhaps more importantly, the absence of features. Using the kano model two questions are asked for each potential product feature:

  • How will users feel if they have the feature?
  • How will users feel if they didn’t have the feature?

Answers can be captured via a 5 point likert scale:

  1. Like it
  2. Expect it
  3. Neutral
  4. Can tolerate it
  5. Dislike it

And can then be mapped using the table below.

Image for post
Image for post

This will place features into one of the following categories (note that there are a number of different Kano model category names out there):

  • Basic features — Features that all users will expect, but can’t really get excited about, like a car having windscreen wipers, or a steering wheel.
  • Performance features — Features that will increase satisfaction the better they are implemented, such as the miles per gallon that a car delivers, or the size of the boot (or trunk, if you’re American).
  • Excitement features — Features that wouldn’t necessarily be missed if they weren’t there, but can provide real delight when present. For example, surround sound within a car, or keyless entry.
  • Indifferent features — Features that don’t really evoke any feelings for users. They can take them, or leave them.
  • Detrimental features — Features that actually cause dissatisfaction when present, such as an automatic handbrake for drivers like myself who prefer manual handbrakes.

Applying the Kano model

The Kano model can be used as a discussion tool within a product team, or even by directly asking and surveying users. You should only use the resulting categorisation as a guide, but the answers to both of the questions are invariably very insightful. The kano model is a great way to find out from users which features are likely to be most important, and to get teams thinking about the impact that features are likely to have on the user’s experience. I’ve listed some more articles about the Kano model below if you want to find out more about this great way to help shape your product roadmap.

If you like this article then please recommend and share it. You can find lots more articles like this on my blog: UX for the Masses

See also

Written by

Former techy turned UX Jedi. Checkout out my blog (UX for the Masses) for more about me.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store