Tag Archives: Kano analysis

Don’t Prioritize Features!

Estimating the “value” of features is a waste of time.  I was in a JAD session once where people argued about if the annoying beeping (audible on the conference line) was a smoke alarm or a fire alarm.  Yes, you can get to an answer, but so what?! The important thing is to solve the problem.

Continue reading Don’t Prioritize Features!

Dell Cell Phone Lacks Differentiation

No cell for Dell.  According to Kaufman Bros. analyst Shaw Wu, carriers rejected prototypes from Dell because the “lack of differentiation.”  As product managers, we know the importance of keeping up with the Joneses, but we also know the importance of including differentiated value in our product offerings.

Continue reading Dell Cell Phone Lacks Differentiation

Viral Product Management


Our previous article looked at the economics of a Freemium business model.  One element that is key to making a strategy that involves “free” work financially is growing your user base.  One way to get that growth is through a word-of-mouth marketing campaign.  This article looks at different elements that characterize or affect the successfulness of a viral product – from a product management perspective.

Continue reading Viral Product Management

Why Prioritization Matters

I am a big fan of boxes and arrows, but this time, Jeffrey Davidson found a great article by Dan Willis before I did, and told me about it. Thanks Jeffrey! The article is about how to deal with the what and how of requirements and design – and it provides some really sage advice. But what got my attention was the lack of prioritization of requirements in his example.

Continue reading Why Prioritization Matters

Flashback: A Year Ago This Week on Tyner Blain [2006-03-03]

looking back in a mirror

Prioritizing Software Requirements – Kano Take Two

ipod mini

In our previous post on Kano requirements classification, we introduced the concepts and showed how to apply them. One of our readers commented privately that we didn’t show how to use the techniques for prioritization. We’ll do that in this post. Thanks very much for the feedback!

The Code Freeze is Killing the Dinosaurs

skeletal t-rex

The software development process for most companies has a flow – gather requirements, design, implement, test, release. There can be feedback loops, iterative cycles, spirals or waterfalls, but they all have these steps. When teams “freeze the code” and submit to test, they are creating their own mini-ice age and dooming themselves to extinction.

Foundation Series: User Experience Disciplines


UX, pronounced you-ex, is the shorthand for user-experience. It represents the science and art of tailoring the experience that users have with a product – in our case, software. UX is a relatively new term, rapidly overtaking HCI (human-computer interface) and CHI (computer-human interface) as the acronym du jour. There are several disciplines within this field, we’ll introduce each of them.

Differentiate Your Product – Circumvent Comparisons


Look Ma! Me Too! The temptation to compete against a checklist can be overwhelming. When we have a competitor who provides 100 of this or 200 of that, it might seem smart to offer 200 of this and 300 of that. We’ll be better off if we focus instead on creating the other thing. The best way to compete is to valuably differentiate our product, not outdo our competition.

More is better features are just that – more is better. But more of the same old thing is worth a whole lot less than some of something else.

Continue reading Differentiate Your Product – Circumvent Comparisons

Prioritizing Software Requirements With Kano Analysis – Article Published

productmarketing.com cover

Pragmatic Marketing, through their print magazine, productmarketing.com has published an article on Kano Analysis in vol 4, issue 3 (May/June 2006). The article was written by Scott Sehlhorst and represents a merging of two of the posts (1, 2) at Tyner Blain that focus on Kano Analysis. Special thanks to Krystin Benmoussa for doing a great job of editing the article! Productmarketing.com magazine includes some fantastic articles of particular interest to product managers and product marketing managers. There are over 50,000 subscribers to the printed form of the magazine, and back-issues are also available online. We’re honored to be included in this issue. Thanks to Steve Johnson at Pragmatic for suggesting it initially, and thanks to the awesome graphic designers that did the layout and graphics – they make the piece look fantastic in the print version.

Link to the online archive of the article: Prioritizing Software Requirements With Kano Analysis

Goldilocks and the Three Products

three bears

  • This product has too many features.
  • This product has too few features.
  • This product is just right!

Michael on High-Tech Product Management and Marketing has a fantastic “wish I wrote that” post about the importance of having the right number of features. He has several references, the best of which is Kathy Sierra’s Featuritis vs. the Happy User Peak post from June 2005. The two posts combined provide great insight into why having too many features is bad, while acknowledging that too few is just as bad. In this post we will look at what we can do to apply these insights and also change the rules some, making our software more desireable than our competition.

Kathy Sierra’s curve

CC license at http://creativecommons.org/licenses/by-nc-sa/2.5/

Thanks Kathy Sierra for allowing re-use of your work.

Kathy’s basic point is that users get happier as we add features – up to a point – and then the confusion and complexity of dealing with extra features outweighs the benefits of having those features. In the discussion thread on her post, people use the Microsoft Word example – most people only use 10% of the features, and people counter with the position that different users use different features. Kathy’s post explores more than just software and addresses car radios and other interfaces.

Michael’s extension of ideas

Michael reviews the recent Business 2.0 article titled “Simple Minds” that in short says “more is more, and it always has been”. I guess there’s a bit of backlash about the quest to create minimally functional software. To quote Michael:

Simpler is indeed better, as long as your product meets your customers’ core needs. You may lose some customers because you don’t have some non-core features, but in most cases – I believe – that loss will be more than made up by those customers you gain since your product is simple, easy to use and yet meets their core needs.

His article is a fantastic and thought provoking read. I especially like his use of the pocket utility knife for feature comparison!

Tying ideas together

We’ve posted before about exceeding the suck-threshold by creating software that people can use. Another of Kathy’s great ideas. Visually, here’s what that looks like using the same framework Kathy has presented.

chart redrawn

suck threshold

We can see that to clear the suck threshold, we need to have more than some minimal amount of features, without having too many features. Our goal is to reach the peak of the curve, where we have the optimal amount of features (for competent users).

How do we reach the goal?

When we use Kano analysis to prioritize features, we’re already halfway there (and then some). Recapping from that post:

Kano provides three relevant classifications of requirements (the fourth category is redundant). All requirements can be placed in one of these categories.

  1. Surprise and delight. Capabilities that differentiate a product from it’s competition (e.g. the nav-wheel on an iPod).
  2. More is better. Dimensions along a continuum with a clear direction of increasing utility (e.g. battery life or song capacity).
  3. Must be. Functional barriers to entry – without these capabilities, customers will not use the product (e.g. UL approval).

The must-be features are the first piece in the puzzle, and they are easy to overlay on the diagram.

must be diagram

What gets us to the goal is our differentiated innovations – the surprise and delight features.


Shifting the curve
As both Kathy and Michael point out, we still feel a lot of pressure to keep adding features. Even if we use Kano to hit the ideal software goals, what keeps us from having feature-creep and bloat until it’s all worthless. They both suggest investing in making the software better, instead of making it do more. And we agree about making it better. If we make the user experience better, we can make the software do more too without falling back below the suck-threshold.

Consider the more is better requirements. Think of them in two categories – user interaction improvements, and application performance improvements.

User interaction improvements remove complexity, and make software easier to use. This results in more user happiness from a given feature, and also allows us to implement more features at a given level of happiness (appeasing salespeople).


Application performance improvements don’t create as dramatic of a shift (they don’t make the application easier to use). They do, make it more enjoyable for a given feature set – shifting the curve up.


Release Planning

We posted before about prioritizing requirements across releases. The initial release should focus 80/20 on must-be and surprise and delight requirements. After the first release, we should prioritize 50/50 effort on surprise and delight and more is better requirements. This split of effort balances the goal of product differentiation (adding features) with the goal of user happiness (shifting the curve).


We have to have a minimum set of features. Too many features is bad. The Kano approach helps us to pick the right requirements to prioritize. It also helps us change the shape of the curve for our software, allowing us to add more features while simultaneously increasing user satisfaction.

Thanks again to Michael and Kathy for their great contributions to this and other topics!