(2016-01-25) Kniberg Skateboard Making Sense Of Mvp Minimum Viable Product And Why I Prefer Earliest Testable Usable Lovable

Henrik Kniberg: Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable

A couple of years ago I drew this (skateboard/car) picture and started using it in various presentations about agile and lean development

with all this buzz, I figured it’s time to explain the thinking behind it.

First example – Not Like This

The top row illustrates a common misconception about iterative, incremental product development (a.k.a Agile).

Many projects fail badly because they do Big Bang delivery (build the thing until 100% done and deliver at the end).

However, when Agile is presented as an alternative people sometimes balk at the idea of delivering an unfinished product – who wants half of a car?

In this example he’s happy with the final product, because it’s what he ordered. In reality, that’s usually not true. A lot of time has passed without any actual user testing, so the product is most likely riddled with design flaws based on incorrect assumptions about what people need

Second example – Like this!

the team delivers the smallest thing they can think of that will get the customer testing things and giving us feedback. Some might call it an MVP (Minimum Viable Product), but I prefer to call it Earliest Testable Product (more on that further down).

we’re not trying to make the customer happy at this point. We might make a few early adopters happy (or pragmatists in pain), but our main goal at this point is just to learn

don’t worry, the project is not finished, this was just the first of many iterations. We’re still aiming to build a car, but in the meantime please try this and give us feedback

The bicycle may turn out to be a much better product than the car originally envisioned

Now you may be thinking “but shouldn’t we already have known that. via up-front analysis of the customer’s context and needs?” Good point. But in most real-life product development scenarios I’ve seen, no matter how much up-front analysis you do, you’re still surprised when you put the first real release into the hands of a real user, and many of your assumptions turn out to be way off.

even in hardware projects there is a huge benefit to delivering prototypes to observe and learn from how the customer uses your product. It’s just that the iterations tend to be a bit longer (months instead of weeks).

Again, maybe the customer is happy with the motorcycle. We could end the project earlier than planned. Most products are riddled with complexity and features that nobody uses. The iterative approach is really a way of delivering less, or finding the simplest and cheapest way to solve the customer’s problem

We may in fact end up with the exact same car as originally envisioned. However it is much more likely that we gain vital insights along the way and end up with something slightly different.

What’s your skateboard?

Think of the skateboard as a metaphor for the smallest thing you can put in the hands of real users, and get real feedback

Let’s take at some real-life examples.

Example 1: Spotify music player

As a startup in 2006, Spotify was founded on some key assumptions – that people are happy to stream (rather than own) music, that labels and artists are willing to let people do so legally, and that fast and stable streaming is technically feasible. Remember, this was 2006 when music streaming (like Real Player) was a pretty horrible experience

the developers basically sat down and hacked up a technical prototype, put in whatever ripped music they had on their laptops, and started experimenting wildly to find ways to make playback fast and stable

The initial version couldn’t be released to a wider audience, it was totally unpolished and had basically no features except the ability to find and play a few hard-coded songs, and there was no legal agreement or economic model. It was their skateboard.

But they shamelessly put the skateboard in the hands of real users – friends and family

Example 2: Minecraft

The first public release was made after just 6 days of coding, by one guy !

Over hundred releases were made during the first year

Example 3: Big Government Project

The idea was to put laptops in the cars, and customized software to give police access to the systems they need in real-time

One of the main success factors was that they didn’t try to build the whole thing at once – they split the elephant along two dimensions: By Region. We don’t need to release to ALL of Sweden at once, we could start by releasing to just one region; By Crime type. We don’t need to support ALL crime types initially, we could start by just supporting 1-2 crime types.

By the time we got to the big release (1.4), with nationwide rollout and training of 12000 police, we weren’t all that worried.

Unfortunately the victory was short-lived. A follow-up project (PUST Siebel) botched it and went back to waterfall-thinking, probably due to old habit. 2 years of analysis and testing without any releases or user-testing, followed by a big-bang release of the “next generation” of the product to all 12,000 police at once. It was an absolute disaster, and after half a year of hemorrhaging they shut the whole thing down. The development cost was about €20 million

Example 4: Lego

Here’s a recent example – Nexo Knights

common theme is prototyping and early user testing

When they first started exploring this concept, they did paper prototypes and brought to small kids. The kids’ first reaction was “hey, who are the bad guys? I can’t see who’s good and who’s bad!”.

Negative: Lego Universe

About 250 people worked for 4-5 years (because of constant scope creep due to perfectionism), and when the release finally came the reception was… lukewarm. The finished game was beautiful, but not as fun as expected, so the product was shut down after 2 years

Interestingly enough the Lego Universe teams were actually using Scrum and iterating heavily – just like the Minecraft guys did. But the releases were only internal.

Improving on “MVP”

Lego also has it’s share of hard-earned failures. One example is Lego Universe, a massively multiplayer online Lego world. Sounds fun huh? Problem is, they got overambitious and ended up trying to build the whole thing to perfection before releasing to the world.

I’ve met many customers that are like “No Way do I want an MVP delivery – that’s the last delivery I’ll get!”

So here’s an alternative

First of all, replace the word “Minimum” with “Early”.

Few customers want “minimum” but most customers want “early”!

Next, remove the word “Viable” since it’s too vague

So let’s be more explicit and split it into three different things:

• Earliest Testable Product is the skateboard or bus ticket
• Earliest Usable Product is perhaps the bicycle. The first release that early adopters will actually use, willingly
• Earliest Lovable Product is perhaps the motorcycle. The first release that customers will love, tell their friends about, and be willing to pay for.
  • (Minimum Lovable Product is more widely used)

Takeaway points