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: http://www.uxbooth.com)

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.

But.

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: http://uxpodcast.com)

This post in inspired by the story here: http://www.infoq.com/articles/lean-startup-killed

Capabilities (or why IT projects fail)

When you (as a company/organization/department/whatever) have an idea or a need or a problem you want to solve you may not have the ability to materialize the idea or solve the need/problem. You then need an ability to do it - a capability. That's the definition of "capability" I'd like to use when it comes to software (or IT in general).

If a company have an idea/problem/need that might result in them wanting some kind of capability that requires software.

Now, they want to know what that capability (via software) is going to cost them to get and maybe they need it at a specific date or at least when to expect to have their new capability ready. Nothing strange, who wouldn't?

The software is built. It might unfortunately be over budget (underestimated obviously), late (underestimated obviously) or it didn't provide the capability they needed.
But, I say it really doesn't have to matter. At least why it is a "fail". Maybe it's on (or below?) budget, on time (or maybe early?) and the right capability was provided and it still is a "fail". Why? Because the idea wasn't that good or the need wasn't really something someone actually had or solving the problem didn't really mattered.

So, how can you know before you have the capability? Well, you can't. The only way to know is to actually have it. But. There's a mind shift here. (Some are actually already doing this) Validate. At the end of the day it's all about learning. You want to learn that your idea is good or that the need is actually a need someone has or that solving a problem is worthwhile. And eventually you *will* learn (or not, if you choose not to do it).
And you can only *assume* that the capability will give you that learning.

Now, you can either start thinking about it (analyzing) or you can start acting, creating. That's the mind shift. I'm not saying: Stop thinking! Stop analyzing! But instead of "Let's postpone this to next meeting" (or whatever), think "What can we do today/tomorrow that will bring us learning about this? Is there anything small we can start doing?". I.e. how can we try - and validate - this assumption we have? Anything? Think "small". Think "learn". Think "validate".

If I take it to the extreme, I basically think they have two options (according to The Rule of Three they should have three options and not two, because 1 option is a trap, 2 is a dilemma, 3 is a choice :-) - heard through George Dinwiddie and Jerry Weinberg. But I'll let you ponder on that third option yourself. Or let all the "gray zones" in between these two extremes be those options).

1. Assume there's a software project ahead and start defining it. Gathering requirements, start planning, estimating etc.
2. Assume there's something small that can be started now (or as soon as possible). With the focus on validating that the assumptions are correct. Maybe we can continue iterating from there or at least we are more confident (validated) that the capability will make a difference and can go to point 1 above.

I'm not saying some (most?) companies aren't doing this already. But this is my experience, and the customers/companies I've met don't have much of this mindset. Your experience may differ.

And I suggest that if you have validated that the basic idea or need or problem will "pay off" it might not matter that much if project is over-budget and/or late? It's never something good, I admit that, but we might not consider it a "fail"?

But then again, it feels good being able to "blame" the IT project (and probably the "supplier" - someone else!) for being the "failure" instead of trying to change your own behaviors, seeing your own responsibility..?