Minimum in 'minimum viable product' doesn't mean minimal, persé (+ how to learn without coding)

Great short discussion with Salim Virani today on twitter. Started by this blogpost by Seth Godin. It's about testing the viability of products that need scale to work. Could you test big projects on small scale?

It daunted me that it's very easy to misinterpret the term ’minimum’ in the term ’minimum viable product’.

Minimum is something I quickly connect to 'less' and in some way this nails the term. It's about speed. But your goal is learning, not releasing.

The question you need to ask yourself: ’what do we need to do in our first learning activities?’. The combination of these activities is a version of your minimum viable product. And it's different for every product.

A startup that has to do with the financial or legal space could have significant higher up front cost than a simple solution you can provide to developers.

While a MVP of another startup might not look minimal to us, it could be to them and the market they are after. If it looks or feel bloated, it doesn't mean it is not the minimum they need to start learning.

What will be build and when will we call it finished. The best MVP's I've seen weren't coded in the first learning cycles at all. Design practices play a significant role to reach your MVP.

One of the MVP models I particularly like is the so called 'concierge' model. This is where the founders of the company directly work with their first customers without the most important parts of their product being build.

The inner works of the product is provided to the customers by hand. This could be any aspect of the service you want to test.

I like this because you turn your first actions in a big qualitative research process. And it connects with a lot of the 'lean thinking' principles. Like reviewing where value is lost in the processes your customers use your product.

Look for the best ’touch points’ with your customers. Where are they experiencing the most pain? When are they interested in hearing about your solution?

If you execute the concierge MVP well you will be able to:
1. Learn which other loss of value you might be able to prevent with your solution
2. Learn when and where people are best perceivable for your product
3. Quickly adapt your assumptions based upon these loose signals
4. Built your first close relations with potential customers, if you do it right you will be able to keep in touch with them
5. Learn which parts of your product are most important and need to be build first

Executed correctly, the concierge approach will keep you flexible and brings you important information to learn from.

It helps to keep your 'MVP' minimal as possible.