Noriaki Kano developed the Kano analysis model in the late 1980s to identify and contrast essential customer requirements from incremental requirements. One of his goals was to initiate critical thinking about the nature of requirements. His characterization approach can be used to drive prioritization of software requirements.

Kano analysis allows us to prioritize requirements as a function of customer satisfaction.

Kano defined four categories into which each feature or requirement can be classified (an Apple® iPod® is used for examples in each of the following four requirement categories):

1. Surprise and delight. Capabilities that differentiate a product from its competition (e.g. the iPod nav-wheel).
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).
4. Better not be. Represents things that dissatisfy customers (e.g. inability to increase song capacity via upgrades).

Surprise and delight requirements

For just a moment, think about software as a user, not an accountant. We want software that is interesting and fun to use. Affordances in the user interface that allow us to just “do what comes naturally” and have the software do exactly what we want. New ideas that make software better. We’re not talking about a button that pops up dancing squirrels when clicked, rather valuable features that make software great.

Great examples of valuable features include:

• The nav-wheel on the iPod, as a good hardware example.
• Google’s Gmail™ use of labels instead of folders for organizing email, as a good software example.
• Contextual help buttons that open to exactly the right page in a Help file.

All of the examples above are implementation details or the results of design decisions—not part of specifying requirements. However, when converting from market requirements to product requirements, we can point our development teams in the right direction and help them focus on innovative solutions to the right problems. These might be the requirements behind the delightful features listed above.

• Users must be able to select songs while holding the iPod in one hand.
• The system must provide an efficient way to organize email, with the assumption that users will never delete email.
• The system shall provide relevant help information for the context in which the user requests help.

More is better requirements

These are the most easily grasped concepts—bigger, faster, better, stronger. The challenge in writing a more is better requirement is in knowing when enough is enough. Requirements such as “minimize” or “maximize” are ambiguous. What is the theoretical minimum response time for a search engine? Does it take a few hundred micro-seconds for the bits to travel from the server to the user, plus a few micro-seconds for switch latency, plus a few nano-seconds for a CPU to find the answer? It would be completely impractical to unambiguously request that our developers minimize search time.

Specifying precise objectives can be very difficult as well. The law of diminishing returns comes into play. There is a concept in economics called utility which represents the tangible and intangible benefits of something. We can consider the utility of a feature with respect to the target users. A graph of the utility for speed of search-result generation would look like this:

We can see that as the speed of results increases, the incremental benefit to the user decreases. While utility is strictly increasing, it is increasing by less and less. When writing a requirement, how do we determine the speed that is truly required? It would be ambiguous to say “as fast as possible” or “as fast as is reasonable.” And it would be naive to think that we did not need to understand something about the implementation before specifying an unambiguous requirement like “search must complete in 2 seconds.”

Thus far, we have only described the benefit side of the cost-benefit analysis needed to specify the requirement. We have to iterate and interact with our development team to determine the impact of a speed specification on costs. After getting feedback from our implementation team, we now have an understanding of the cost of implementing “search,” as shown below:

We can see how it gets progressively more expensive to make progressively smaller increases in speed. This is our “development reality” and we can’t ignore it when specifying how fast “search” needs to be. To determine the optimal specification, we have to find the point in the curves where the incremental benefit of searching faster is equal to the incremental cost of searching faster. We can do that by graphing utility versus cost as shown below:

The circle in the graph above shows the point where the slope of the curve equals 1. At this point in the curve, an additional increase in speed provides less benefit than the associated increase in cost. At any point to the left of the circle, we are “leaving money on the table” because there is a better point to the right. This is the optimal speed to specify.

Reality check

In the real world, we will not have the precise data that allows us to draw these graphs and quantitatively identify the Pareto optimal point on the cost-benefit curve. It is important to understand the fundamental principles of the trade off so that we can make informed decisions and judgment calls.

Some analyses will be relatively easy, as our development curves are usually discrete data points based on estimates of the work required to implement particular designs. We also won’t have access to the full spectrum of design choices, because we will be limited by other constraints on the system as well as the creativity and capabilities of our development team in proposing alternatives.

Must be requirements

Must be requirements are the easiest to elicit and are the ones that most people consider when they talk about requirements.

Stakeholders can usually tell us what they must have in the software. In the Am I hot or not? post on requirements prioritization, the company 37signals focuses on this as its primary criterion for inclusion in a software initial release. They choose to only put essential, or must be requirements, into the initial release of software.

Better not be requirements

This is just the opposite of surprise and delight. If dreamers think about what makes something great, then critics complain about what holds it back. This bucket does not have a place in Kano’s analysis. Saying, “Users don’t like confusing navigation,” does not provide any benefit relative to saying, “Users prefer intuitive navigation.” We suggest not using this category at all.

Apply the Kano techniques to make good prioritization decisions

1. Are our 1.0 release requirements all must be requirements?.
2. When we specify more is better requirements, are they unambiguous, and are they optimal—or at least practical?
3. Do we have any surprise and delight requirements that will enable us to create an innovative product?

Using Kano analysis to prioritize requirements

The first release of the software should primarily include must be requirements.

We talked about how 37signals and other companies have taken the “more is less” approach to releasing their software. The first releases (or beta releases, which has become the misnomer du jour) of successful products have focused the majority of their efforts towards achieving these highest priority requirements.

This trend has evolved because of what used to be called “Internet time.” Products are being released more quickly by startups, skunk-works, and other teams operating in Agile development environments. The dot-bomb generation of software developers has almost a decade of experience now, and is increasingly influencing company decision making, with the benefits of lessons learned about hype and substance. These teams and leaders are driving “relevant and differentiated” innovation into the marketplace faster than ever.

Geoffrey Moore, author of Crossing the Chasm, Inside the Tornado, and now Dealing with Darwin: How Great Companies Innovate at Every Phase of Their Evolution, recently posted an article Top 10 Innovation Myths, that is in line with his new book and definitely worth a read. Mr. Moore points out that innovation is not the goal—product differentiation resulting from innovation is the goal. He is absolutely right. An innovative way to minimize the window of an application is not likely to differentiate the product from its competitors. An innovative way to automatically validate requirements would be the proverbial better mouse trap.

Making things even more competitive is the increased speed and reduced cost of getting the message out. Idea virus is a term coined by Seth Godin, and every day another company learns how to do it. When a new product gets digg’ed or slashdotted, the stampede on the server is like the mobs that sought out super cheap computers during the last holiday season. The Internet traffic can become overwhelming and shut down the servers. But that still won’t stop the flow of traffic for really hot ideas—people will post links to a cached version of the page at Google™, and the idea virus keeps spreading.

It is not enough to be fast. But it is also not enough to be differentiated. Both are important—neither is sufficient alone.The twin-dynamic of smarter, faster competition combined with cheaper, faster effective marketing, demands that we focus on reducing time to market.

All of the must be requirements need to be included in the first release. If we could release the software without implementing features to support a must be requirement, then either no one will use the software, or the requirement is not a must be requirement.

Define and prioritize more is better requirements based on ROI

We have already discussed how to find the Pareto optimal point for specifying a more is better requirement. This is the point where additional investments in the measured characteristic are not offset by comparable gains, due to the law of diminishing returns. We showed the optimal point to be where the slope of the cost-benefit curve is 1 (or 100%). What we have not accounted for is the opportunity cost of spending those development resources on other features, capabilities, or projects. If we have a hurdle rate of 20% for investments, we should find the point on the cost-benefit curve where the slope is 1/1.2 (120% benefit for 100% cost). This normalizes our cost benefit decisions across projects.

The key to scheduling more is better requirements is to take advantage of the fact that they represent a continuum of performance and a continuum of benefit from that performance. Include a minimal amount of the requirement in the earliest release(s)—not the optimal amount. The optimal amount can be added later. We refer to this as requirement staging—or implementing portions of (or versions of) a particular requirement across multiple releases.

Surprise and delight requirements as differentiators

We care about surprise and delight features not because they are whimsical, but because they are valuable. A delightful splash screen does not make software easier to use, but it has value in both branding and word-of-mouth marketing. It is the buzz-marketing equivalent of great packaging for a physical product (like the ketchup bottle that stands upside down). Self-configuring software, error messages with “click here to automatically fix it” buttons are other examples of surprises with value. These examples can increase the number of possible users.

When prioritizing surprise and delight requirements, we must consider our marketing strategy to determine the importance of the requirement. Are we a startup and is this our first product? Are we a behemoth rolling out another bolt-on package for our installed base? These types of features are most valuable when individuals are making purchasing decisions and when we are relying on word-of-mouth marketing. The features are least valuable when the decision maker is three layers (and six figures) removed from the actual users. This decision maker can pragmatically decide that usability is irrelevant because he does not personally have to use it.

Summary

Kano analysis provides a powerful and easy-to-use means to classify requirements. We can use that classification to drive our prioritization decisions, making sure that we deliver all of the must be requirements in the first release. Kano also helps us focus on the requirements that will differentiate our software, while helping us make informed cost-benefit analyses on the more is better features.