Prioritizing Software Requirements – Kano Take Two

Let’s try this again.

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!

Kano analysis recap

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 the 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).

Using the categories to prioritize requirements (discussing them in reverse list-order)

3. The first release of the software should include primarily ‘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 we used to call internet time. Products are being released more quickly by startups, skunk-works, and other teams operating with Agile development approaches. The dot-bomb generation of software developers have almost a decade of experience now, and are increasingly influencing company decision making, with the benefits of the lessons they learned about hype and substance. These teams and leaders are driving relevant and differentiated innovation into the marketplace faster than ever before.

Geoffrey Moore is a big thinker and author of Crossing the Chasm, Inside the Tornado, and now Dealing with Darwin: How Great Companies Innovate at Every Phase of their Evolution. (Chasm and Tornado are two of my favorite books about innovation – great ideas, and quick reads). He recently posted an article – Top 10 Innovation Myths, that is in line with his new book and definitely worth a read. One of Mr. Moore’s points is that innovation isn’t the goal – product differentiation resulting from innovation is the goal. He’s absolutely right. An innovative way to minimize the window of an application isn’t likely to differentiate the product from it’s 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 went after super cheap computers this past christmas. The traffic can even be overwhelming and shut down the servers. And that still doesn’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 isn’t enough to be fast, as Mr. Moore points out. But it also isn’t 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 truely a must be requirement.

2. ‘More is better’ requirements need to be rationally defined and then prioritized based on ROI.

We showed in our previous post 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 that optimal point to be where the slope of the cost-benefit curve is 1 (or 100%). What we didn’t account for is the opportunity cost of spending those development resources on other features or 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. In the earliest release(s) – include a minimal amount of the requirement – 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.

1. Surprise and delight requirements can be differentiators.

We care about surprise and delight features NOT because they are whimsical, but because they are valuable. A delightful splash screen doesn’t make software easier to use – but it has value in both branding and word of mouth marketing. It’s 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, or help novices clear the suck threshold more quickly. These are the kinds of things that make our customer-salespeople more likely to promote our products (as Seth Godin describes them).

When prioritizing these requirements, we have to consider our marketing strategy to determine their importance. 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’re relying on word of mouth marketing. They are least valuable when the decision maker is three layers (and six figures) removed from the actual users – someone who can pragmatically decide that usability is irrelevant because he doesn’t have to use it personally.

* The tiny car in the picture is a Fiat – a legally binding command or decision.