Wednesday, 27 May 2015

Minimum Viable Product = Maximum Expensive Learning?

The title is quite provocative... Don't worry, I'll explain.

The reason for this post is that I think the concept of the MVP (Minimum Viable Product, as defined in The Lean Startup by Eric Ries - a great book, read it if you haven't) is, in my opinion, a bit misunderstood. I'd claim that validating your business assumptions with software is a very expensive alternative, and hence your least desirable alternative. But MVP is not bound to building software. A product is not only software. One definition of "product" is: something that is the result of a process. (Merriam-Webster). Thus, the result - the outcome - of something you do, might be seen as a product.

Let me explain my thoughts.

One image that floats around on twitter and in various presentations is this image (I think it's originally created by Henrik Kniberg for Spotify):
(Image source:

I know. It's just a metaphor, just an image. And it shouldn't be overinterpreted. But that's actually exactly what I'm going to do now :) Because I think it works for discussing some things, explaining my thoughts.

I'm not going to dwell on the fact that the top steps in the image is actually the wrong, however you'd approach anything. So, let me start by explaining the good parts of this image, and how I think it should be interpreted.

The image is to be seen as a way to start off small. Not building everything upfront. But better; iterate your way to the "final" (nothing is ever "final", right? But it fits the image) version. I assume, myself, that the assumption in the image is that someone needs the capability (it's always about capabilities, that's what business are working for - having a new (or improved) capability, e.g. the capability to fill a market need etc.) of going from point A to point B. Later on we discover more stuff; that it would be great to have a handle to hold on to. Then later the faster bike etc. And finally we end up with a car. And who knows what the next step is...

All great.


I also see potential problems here. This might actually be a very expensive approach. How?

Because software is an expensive way of iterating to a needed capability. Even if building software today is much cheaper than it was some time ago, most capabilities are not cheap enough.
And if your customers really needs cars - all the other steps were actually waste. And. You might end up in a "trap" of not ending up at that car at all.

Because, building a skateboard is not that cheap actually (if looking at it from a software perspective). Even if it's just a month or so for a couple of developers, that's still quite expensive. Of course, in some domains it might perhaps not be that much money, compared to other things, but still; not cheap. Then add all the other steps, the kickbike, the bike, the motorcycle. Expensive. Very. If compared to: asking the right questions. Getting to know your customers and market in other ways than through software. In this, simple, case all you'd have to do is ask a couple of quick questions:
- Where do you plan on going?
- Shopping, vacations, skiing etc.
- How fast would you like to get there?
- Well... couple of hours as a maximum.
- Do you often need luggage?
- Yes, like skies, groceries etc.
- How many people do you want to bring?
- Usually the entire family.
- Etc...
Only one option is now left; the car. Perhaps some other options could've been a horse with a carriage or a helicopter or something. But a rough idea of the cost and/or something else would easily solve that problem.

This is a much cheaper approach than to build all the intermediate steps in between. This is of course not always possible (and where the metaphor/image falls short) and then building these intermediate products is perhaps your only alternative.

But. There's another possible problem. About gathering information, gaining "knowledge", learning. The wrong kind.

In a more complex scenario, gathering data and learning from it is not that obvious. Using the image as an analogy, if we build and deliver skateboards to our customers. We might end up focusing on: people loving skateboards. Thus, we might end up getting feedback about how to improve the ball bearings or how to build a better shape on the board for various tricks etc. And we might lose the focus on our real valuable customers. And we might even lose those other customers (when improving on the "wrong" things) - the ones we really would like to target - those needing cars.

Thus, sometimes (or perhaps even most often?) the cheapest way to learn about your market and customers is to actually get out there. Get to know them. Marketing research and similar. Getting to know them by going straight for building and shipping software is not a cheap approach.

But, when eventually building that capability you need. Do not plan all the details up-front. Iterate.

Getting to know the "right" capability and iterating the details is cheaper than iterating your way to the "right" capability by building stuff. This goes against the idea of "The Lean Startup". But remember, Eric Ries writes in the book that the context is: extreme uncertainty. Things aren't always extremely uncertain. And if it actually is? Well go for it. But if you can ask a couple of questions (or similar activities) and gain similar knowledge - that's your option. Or, it's actually not a dichotomy. Do both. When needed. You know, that context stuff...

To finish off this post. I think this image is a better example on the evolution of an idea, as I see it:
(Image source:

This post in inspired by the story here:


  1. I think this is valid: "Because software is an expensive way of iterating to a needed capability."

    If you need a car, and you know you need a car, and the end product has to be a car, why bother building the other things? Clearly MVP isn't just a "best practice" that everyone should follow regardless of context.

    But that's really not what the conversation about Lean Startup or MVP is about.

    I would be happier with the skateboard/bike/motorcycle image if it stopped at bike. The real discussion should be about building a car when a bike is all that the customer really wants.

    The point of incremental development isn't to reach a predefined end result faster, but to stop when you find the part that makes the money. It prevents writing the 48% that is never used, or gold-plating a turd.

    Incrementalism is insurance against building more than is needed.
    It's not a recipe for faster/cheaper/quicker delivery of a known good.

    That difference shows a whole different set of underlying assumptions and an entirely different business model.

    Contract work presumes an end product, an end date, and that "productivity" will be progress toward that predefined end.

    Incremental work like lean startup is about learning what clients want you to build, and may very well have different end results and dates and scope (and market) than originally intended.

    It is better for product/customer development styles of work for "wicked problems"

    This is why I say that agile is sooner, not faster.

    It's also why we say that Lean Startup, Agile, and NoEstimates are not for everyone. It only works when experimentation, scope reduction, pivots, etc are fair game -- and that's largely a matter of specific prerequisite understandings and agreement between suppliers and customers.

  2. Though if you use the first image you can't really say that a skateboard is wrong IF the customers needed cars because if you evaluate the problem and come to the conclusion that they need cars, then a skateboard is not a minimal viable product anymore and thus wouldn't be on the picture.

    And you can't have 'car' as a need. You can only have what the car does as a need. What it does can be something that only a car can do, but it can't be 'be a car'.

    When you know what the car is supposed to do you can solve that problem and your first goal might be to end up with a car but during that time you discover that if you switch the wheels for tracks it would suit the customers need much more and suddenly the goal can change to making a personal tank.

    If the requirement is 'being sold in a car dealership to customers that want to buy a car' then most likely the only option is to make a car, but it might not be. It might be a really high end electric car and suddenly you change the world and become even more filthy rich. It might even be a car that hovers since you realise that the customers all live on small islands near the shore and that would be really helpful for them.

    The goal should not be 'a product' but a solution and if it is, then the first picture holds true.

  3. I found so many interesting stuff in your blog especially its discussion. Really its great article. Keep it up. 성인용품창업