Basic Features vs Delightful Features

Basic Features
Basic features that a user expects to be there and work will never score highly on satisfaction, but can take inordinate amounts of effort to build and maintain.

Delightful Features
Score very highly on satisfaction and in many cases may not take as much investment. Small incremental improvements here have an outsized impact on customer satisfaction.

Hotel example:

Hot Water: No customer is going to rave on Twitter about how good the hot water in their hotel was, but if it wasn’t there, or it wasn’t hot enough, or took too long to get hot, you bet there would be a complaint, and a loud one.

It is crucial to understand at what point you’ve met the users’ expectations and to stop there. Any further development is a wasted effort.

A user will never tell you about basic expectations. If you sat someone down and asked them to design their perfect design they will not tell you about basic design. You have to observe and research to find these basic expectations.

The beauty of delightful features is that these features can deliver so much more user satisfaction per unit of investment than basic features.

The Problem of Delightful Features

All features will migrate from delightful to basic expectations. Once a user has come to expect that delightful feature – whether because you’ve had it for a while or because all their other products have it – the feature has become something they expect. The absence of that feature would now be a frustration, and you need to discover new delightful features.

Lessons

  1. Which features are meeting basic expectations? Only invest in developing or maintaining those to the extent that you need to satisfy the customer. Which features are your delighters? Focus your efforts here and make sure you’re constantly developing new ones.
  2. Monitor your customer satisfaction and competition to ensure that features you think delight users haven’t slid into basic expectations and no longer help your customer satisfaction.

Resource: Using The Kano Model To Prioritize Product Development

Advertisements

About Ahmed

Software craftsman, programmer, developer, system/business analyst, DBA and PM.
This entry was posted in Agile. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s