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.

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

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

Surprise and delight. Capabilities that differentiate a product from it’s competition (e.g. the nav-wheel on an iPod).

More is better. Dimensions along a continuum with a clear direction of increasing utility (e.g. battery life or song capacity).

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.

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

Conclusion

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!

4 thoughts on “Goldilocks and the Three Products”

2) I think this article is an AWESOME example of how the Internet, Blogging & Creative Commons licenses work together to enable us to build upon each others’ works (and those of the commenters) in almost real-time to enhance our collective understanding of key concepts. Beautiful!

BTW, I really like your idea that user interaction improvements allow addition of more features at a given level of user happiness.

Excellent addition to what I consider is quite a series on product development. Hats of to Kathy for getting the ball rolling and to Michael and you for taking this forward. Every product manager should have all three posts bookmarked :) (I have Kathy’s diagram pinned to my corkboard)

“Create an inspiration board: Empty a bulletin board in your work area when you begin a project. Each time you see something (pictures, magazine articles or other items) that you think is compelling, tack it to the board. “Before long, you’ll start seeing connections between the images that will enliven and expand your work.””

@sehlhorst on Twitter

Who Should Read Tyner Blain?

These articles are written primarily for product managers. Everyone trying to create great products can find something of use to them here. Hopefully they are helping you with thinking, doing, and learning. Welcome aboard!