This post is by Suzanne Abate, CEO, The Development Factory
For most product managers in charge of planning the product roadmap, the task of determining which features to include and which to prioritize is a daunting one.
Feature planning is made more difficult by pressures from designers who want an opportunity to showcase new user interface ideas and developers who may be motivated to execute the simplest possible version or be prone to over-complicating every detail.
So how do you plan and prioritize features effectively?
Try The Kano Model.
Introduction to The Kano Model
In the mid nineteen-eighties, Dr. Noriaki Kano introduced a framework for addressing the problem of feature set planning, which is still studied and applied today.
The core concept suggests all features can and should be labelled according to five categories (3 primary and 2 edge case) and mapped onto a quadrant where the x axis measures execution (how well or poorly a feature is implemented) and the y axis measures customer satisfaction (from extreme satisfaction to extreme dissatisfaction).
Basics — Basic Features are typically the nuts and bolts functions of any product — such as your car brakes or numeric keypad on your phone.
When basics are implemented extremely well, they tend to produce a neutral response at best because they are features that customers expect or take for granted. Nobody is giving out awards to car companies for having great brakes because being able to stop is a critical and expected function of any vehicle.
However, if basics are implemented poorly, customers quickly become dissatisfied because we expect better.
Let’s take a crude example from romantic relationships. If we are lucky to have a partner who cooks dinner for us every night, we tend to expect and rely on them for feeding us. If suddenly our partner enrolls for a night class or simply decides to hang up the tongs and we have to cook our own dinner, well, needless to say it will be an uncomfortable adjustment.
If your product is entering into an established market with lots of competition, you may need to build a lot of basic features into your minimum marketable feature set just to be competitive at the outset.
Performers — Performance Features generally refer to quantifiable benefits such as processing speed or storage capacity.
Most of the time customers can articulate these needs in general terms like “I wish my videos would upload faster” or “I want images to render immediately on arrival.”
Performance features have a linear effect. The more there are / better they are, the happier we are. Performance features are also important because they most inform the decision-making process when customers are evaluating which product to buy.
Examples of performance features are: 4x longer battery life, +5 extra miles per gallon over the leading competitor, 12 megapixels with telephoto zoom.
Delighters — Delighters are as they suggest, features that delight. In particular, they tend to delight us because we do not expect or want them but we are pleased when presented with them.
Delighters are innovations. Our opportunity to create value and brand equity, often at little expense to us.
For example, “Free Shipping for Amazon Prime members,” and “native emoji keyboard.”
Delighters live almost exclusively in the upper right quadrant because they rarely produce a negative effect. After all, it’s hard to hate something you didn’t know you needed or wanted!
Two Edge Case Categories
There are two other categories in The Kano Model, that are typically dismissed as rare circumstances or edge cases.
However, I believe that much can be learned from “Indifference” and “Reversals.”
Indifference — Indifference refers to features that produce a completely neutral effect whether implemented well, poorly, or not at all.
Most of the time products are bloated with neutral features because product leaders are afraid to leave things out.
But the very fact that a feature produces no measurable benefit for a customer should rule it out from the roadmap altogether — as it simply adds cost to the product development process and can actually decrease performance indirectly. Exceptions are purely functional but unexciting elements such as login modules.
Reversals — The easiest way to describe a reversal is: the feeling when somebody else’s baby finally stops crying on a long flight.
Sometimes, by removing a feature altogether, customer satisfaction actually increases.
As with neutral features, reversals present product managers an excellent opportunity to learn about and weed out (or else significantly improve) annoying features that can devalue your product.
So how do you determine which features will produce which results?
All you have to do is ask!
Okay that’s a bit of a simplification.
The Kano Model, like any user experience modality, requires customer interaction.
We must learn what customers really want, not what they say they want or what we think they should want.” — Eric Ries, The Lean Startup
As we already know from our own forays into customer development, people don’t always know what they want.
For this reason, The Kano Model uses a specific survey method intended to find the truth by poking customers in the feels.
The “Kano Survey” works by asking two questions for each feature, one positively framed and one negatively framed.
(Positive) If you had a piece of software that would allow you to upload a video file of any size in less than 10 seconds, how would you feel?
(Negative) If the videos took closer to 20 seconds and some as much as 30 seconds, how would you feel?
For control, the responses are limited to five answers:
The +/- framing helps you determine whether your feature specification is registering as beneficial or not and, by default, produces a range of tolerance or “acceptability.”
Let’s look at another example using price:
(Positive)If you were able purchase this product with all the features we discussed for $100, how would you feel?
(Negative) If you were able to get all the features but the price was $500, how would you feel?
Remember, customers rarely tell us what they want but some creative poking using this method can get them to leak valuable data.
Features that register negatively through surveys can be abandoned or put on ice.
For ideas that yield positive reactions (and little negative resistance), it’s also important to ask customers for help in prioritizing, by having them rate the discussed features between on a scale of 1–5, where one is “not all that important” and five is “extremely important.”
Just because all of our ideas are well-received, doesn’t mean we should invest in developing them all. This second framing of prioritization forces customers to recalibrate their answers and in many cases could result in seemingly positive features moving closer to neutrality.
Letting the graph results dictate the plan
After you’ve conducted your research you can plot your aggregate results onto the quadrant to see how your product spec looks on the customer satisfaction scale before you build it.
If you’re tracking heavy on basics or indifference, then you need to find a way to bolster excitement by improving performance and / or introducing delighter features.
Extreme satisfaction can help keep customers from switching to the new new thing, whereas dissatisfaction tends to send people looking.
For this reason, it’s not just important to conduct The Kano Model during product development but ongoing through your product lifecycle.
Delighter features are a proven way to create a unique value proposition, but we humans are fickle and overtime even features that once delighted us become expected. Can anyone say airplane wifi?
“A product or service will only be successful if it effectively solves one or more important customer problems.” — David Verduyn, kanomodel.com
What are some product features that have delighted you most recently? Can you share an example of a time you felt happier when a company removed a feature, or wished they would?
For more articles like this visit 100 Product Managers website.
Image Credit: CityStart Boston
Disclaimer: This is a curated post. The statements, opinions and data contained in this column are solely those of the individual authors and contributors and not that of iamwire or the editor(s). The article was originally published by the author here.