How to make a minimum viable product with the Kano Model

Minimum viable product visualisation by Henrik Kniberg

Source: Henrik Kniberg

What does minimum viable product mean?

Imagine you’ve got an idea for a new product. Should you create the entire finished product right away before you start selling it? Generally speaking that’s a bad approach.

The main risk you face is whether or not customers will want to buy your product, or will enjoy using it and continue paying if it’s a subscription. Maybe you’ve spent a long time or a lot of resources to create the finished product, or maybe making changes to a finished product to adjust it to the market is going to be costly.

Instead, the idea is to create a simple or lightweight version of the idea that is quicker to produce, then put it out to market and see what reaction you get. This is the “minimum” version of that product so you can see how well it does, in a shorter timeframe and for less cost.

The “viable” part is very important - it’s no good creating only a thin slice of the product idea that doesn’t include the core parts, or that isn’t fully functional. If your minimum product is not properly representative of the value proposition that the final product will offer, then any signals you get from the market will not be useful to you. It must have the key features or some approximation of the core functionality included to be viable.

So a minimum viable product is the quickest version of your idea that allows you to learn about what is required in the final product for it to be successful in the market.

Eric Ries popularised the idea of MVP through his book The Lean Startup. Since then it’s been written about a lot, and in some places the core philosophy has changed or been misinterpreted...

Sometimes the MVP ends up just being “version 1” of a product, or the first release simply to get something live that can be iterated on. This is the wrong way to think about a minimum viable product in my view. A minimum viable product is for learning about your core idea and testing your riskiest assumptions, not proving out your delivery pipeline.

How to prioritise features for your minimum viable product?

You can use the Kano Model to prioritise features your minimum viable product.

There are 3 key feature categories in Kano to think about:

Must-haves without which the product doesn’t fulfill the customer’s core needs
Performance where customer satisfaction goes up in line with the quality of the feature
Delighters where the customer isn’t expecting something but is super happy to see it

There are other categories in the Kano Model but these are the key ones for now. At a minimum your MVP should include must-have features and delighters.

For the must-have features, think about the core value proposition. What is the fundamental benefit of the thing you’re building? It’s usually a problem you’re solving for the customer, or an opportunity you’re helping them exploit.

I like the Jobs To Be Done framework for this - what is the job your customer needs to get done which your new product helps them with? What is the outcome they ultimately want after using your product?

For your delighter features, you can get creative. Nobody expects to get delighters in a product, but when they pop up it creates engagement, motivation, loyalty and retention. Brainstorm some ways that you could create unexpected value from your product. For example, copy / pasting a grid of cells from Google Sheets into Google Docs automatically creates a table. This is a real time saver!

Once you’ve got a list of features that you think fall into these categories, you’ll need to run a Kano survey to double check you’re right, and to drive the prioritisation of those features for your minimum viable product.

A Kano survey can reveal 3 key bits of data that feed into your prioritisation:

Which category a feature is.
How strongly that feature sits in the category (a delighter might be delightful for a few people, or for everyone)
How much potential customer satisfaction a feature might drive

Now you can find the features with the strongest match to must-have and delighter categories, and the highest customer satisfaction. And that’s your MVP.

What are some tips to design the MVP of an idea?

Once you’ve used the Kano Model to decide which features you want to include in your MVP, you have to get creative in terms of how you deliver it - obviously you don’t want to build an all-singing, all-dancing fully polished final version. You’ve got to figure out how to create a minimum version of that must-have functionality.

One way to do this is with a concierge feature. This is where the front-end of the product looks like it works properly, but in the background there’s a manual process - ie. a human being does the hard work. A very simple example could be an app to apply HTML markup to a document. Maybe one day it would happen fully automatically through code, but at the beginning you could easily do this manually and then have the results surfaced back into the app for the user.

Another way is a fake door feature. This is a feature that appears like it’s going to do something but actually doesn’t. You can measure intent by seeing how many people interact with it. The feature must be convincing, it must look real until the user interacts with it, so you can really believe their intent was there.

A third way could be to simplify the core functionality to a single use case, removing any complex edge cases, applying constraints to any input or configuration, to narrow the problem space and make the feature much easier to build. An example could be an app to book a taxi - at first you could have only a single taxi supplier, in only a single location, and all for a fixed price. By reducing the variables the build is much easier and can still allow you to learn about the market response to your product.

What's the difference between MVP and minimum lovable product?

Some people have had a bad experience with minimum viable products. Perhaps the MVPs didn’t include full core functionality, or they didn’t include any delighter features. So those people’s impression of the MVP approach is that it is bad.

Instead they’ve created the idea of a minimum lovable product, or MLP. This is basically an MVP that is fun and satisfying to use and which creates delight and engagement rather than being an over-simplistic barebones version of just the core functionality.

In my view an MLP is actually the same as a good MVP. A good minimum viable product should include delightful features and be enjoyable to use. It should be complete (as in no missing parts that are important to the job being done), with the UX polished to a reasonable level that doesn’t hinder usability.

If you want to go further down the route of minimum lovable product, you can do so by adding more delighter features, and improving the quality of your performance features. This will make the product feel to a higher standard all round.

Performance features in the Kano model framework are where customer satisfaction goes up in line with the quality of the implementation of the feature. For example, let’s say you have an app which has a colour picker:

A very basic version might have 10 colours hardcoded which cannot be changed
A better version would have 50 colours hardcoded - now there’s much more variety and more chance that the user can find what they want
A better still version would have the ability to create new colours, perhaps through entering a specific hex code - now the user can create any colour they need
The best version would have all the above and a ‘sample’ tool which let you click on any area of the screen to sample the colour at the point and add it to your palette - now the user can copy colours and palettes from elsewhere much more easily and quickly than trying to guess at the hex codes

By improving the level of implementation of features, you’ll improve the overall satisfaction of your product. This can be one way to evolve your MVP into an MLP.