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

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

(French translation)

A couple of years ago I drew this picture and started using it in various presentations about agile and lean development:

Since then the drawing has gone viral! Shows up all over the place, in articles and presentations, even in a book (Jeff Patton’s “User Story Mapping”  – an excellent read by the way). Many tell me the drawing really captures the essence of iterative & incremental development, lean startup, MVP (minimum viable product), and what not. However, some misinterpret it, which is quite natural when you take a picture out of it’s original context. Some criticize it for oversimplifying things, which is true. The picture is a metaphor. It is not about actual car development, it is about product development in general, using a car as a metaphor.

Anyway, 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). I’ve lost count of the number of failed projects I’ve seen because of this (scroll down for some examples). 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?. Imagine this:

“Here sir, here’s our first iteration, a front tire. What do you think?”

Customer is like “Why the heck are you delivering a tire to me? I ordered a CAR! What am I supposed to do with this?”

(By the way, I’m using the term “customer” here as a generic term to represent people like product managers, product owners, and early adopter users).

With each delivery the product gets closer to done, but the customer is still angry because he can’t actually use the product. It’s still just a partial car.

And finally, when the product is done, the customer is like “Thanks! Finally! Why didn’t you just deliver this in the first place, and skip all the other useless deliveries?”.

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.  So that smiley face at the end is pretty idealistic.

Anyway, the first row represents “bastardized agile”. Technically it might be incremental and iterative delivery, but the absence of an actual feedback loop makes it very risky – and definitely not agile.

Hence the “Not Like This” heading.

Second example – Like this!

Now for the second row.

Here we take a very different approach. We start with the same context – the customer ordered a car. But this time we don’t just build a car. Instead we focus on the underlying need the customer wants fulfilled. Turns out that his underlying need is “I need to get from A to B faster”, and Car is just one possible solution to that. Remember, car is just a metaphor, think any kind of customized product development situation.

So 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).

Call it what you like (some even call their first release the “the skateboard version” of the product, based on this metaphor….).

The customer is unlikely to be happy with this. This is nowhere near the car he ordered. But that’s OK! Here’s the kicker – 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. Ideally, the team explains this clearly to the customer in advance, so he isn’t too disappointed.

However, as opposed to the front wheel in the first scenario, the skateboard is actually a usable product that helps the customer get from A to B. Not great, but a tiny bit better than nothing. So we tell the customer “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“. Think big, but deliver in small functionally viable increments.

We might learn some really surprising things. Suppose the customer says he hates the skateboard, we ask why, and he says “I hate the color”. We’re like “uh…. the color? That’s all?”. And the customer says “Yeah, make it blue! Other than that, it’s fine!”. You just saved *alot* of money not building the car! Not likely, but who knows?

The key question is “What is the cheapest and fastest way we can start learning?” Can we deliver something even earlier than a skateboard? How about a bus ticket?

Will this help solve the customer’s problem? Maybe, maybe not, but we’ll definitely learn something by putting this into the hands of real users. Lean Startup offers a great model based on listing your actual hypotheses about the users and then working systematically to validate or invalidate them.

You don’t need to test the product on all users, and you don’t need to build a product to test something. Testing a prototype on even a single user will teach you more than nothing.

But OK, back to the skateboard example.

After playing around with it in the office, the customer says “OK, kind of fun, and it does get me to the coffee machine faster. But it’s unstable. I fall off too easily”.

So the next iteration we try to solve that problem, or at least learn more about it.

Customer can now get around the office without falling off!

Happy? Not really, he still kind of wants that car. But in the meantime he is actually using this product, and giving us feedback. His biggest complaint is that it’s hard to travel longer distances, like between buildings, due to the small wheels and lack of breaks. So, next release the product morphs into something like a bicycle.

Now the customer can zoom around campus. Yiihaaa!

We learn some things along the way: The customer likes the feeling of fresh air on his face. The customer is on a campus, and transportation is mostly about getting around between buildings.

The bicycle may turn out to be a much better product than the car originally envisioned. In fact, while testing out this product we may learn that the paths are too narrow for a car anyway. We just saved the customer tons of time and money, and gave him a better product in less time!

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.

So yes, do some up-front analysis, discover as much as you can before starting development. But don’t spend too much time on it and don’t trust the analysis too much – start prototyping and releasing instead, that’s when the real learning happens.

Anyway, back to the story. Perhaps the customer wants more. Sometimes he needs to travel to another city, and the bike ride is too slow and sweaty. So next iteration we add an engine.

 

This model is especially suitable for software, since software is, well, Soft. You can “morph” the product as you go, as opposed to hardware where you essentially have to rebuild every time. However, 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). Even actual car companies like Toyota and Tesla do a lot of prototyping (sketches, 3d models, full-scale clay models, etc) before developing a new car model.

So now what? 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. Minimize the distance to Awesome. Very Zen.

Or, again, the customer could choose to continue, with or without modifications to the requirements. 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. Like this:

The customer is overjoyed! Why? Because we learned along the way that he appreciates fresh air in his face, so we ended up with a convertible. He did get a car after all – but a better car than originally planned!

So let’s take a step back.

What’s your skateboard?

The top scenario (delivering a front tire) sucks because we keep delivering stuff that the customer can’t use at all. If you know what you’re doing – your product has very little complexity and risk, perhaps you’ve built that type of thing hundreds of times before – then go ahead and just do big bang. Build the thing and deliver it when done.

However, most product development efforts I’ve seen are much too complex and risky for that, and the big bang approach all too often leads to huge expensive failures. So the key question is What’s your skateboard?

In product development, one of the first things you should do (after describing what problem you are trying to solve for whom) is to identify your skateboard-equivalent. Think of the skateboard as a metaphor for the smallest thing you can put in the hands of real users, and get real feedback. Or use “bus ticket” if that metaphor works better.

This will give you the vitally needed feedback loop, and will give both you and the customer control over the project – you can learn and make changes, instead of just following the plan and hoping for the best.

Let’s take at some real-life examples.

Example 1: Spotify music player

“With over 75 million users, it’s hard to remember a time without Spotify. But there was. A time when we were all mulling the aisles of Target for new CDs. A time in our lives where we all became thieves on Napster. A time when iTunes forced us to buy songs for $2/piece. And then came Spotify.”Tech Crunch

Spotify is a pretty fancy product now. But it didn’t start that way. I was lucky to be involved pretty early in this amazing journey (and still am).

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, and pirate-copied music was pretty much the norm. The technical part of the challenge was: “Is it even possible to make a client that streams music instantly when you hit the Play button? Is it possible to get rid of that pesky ‘Buffering’ progress bar?”

Starting small doesn’t mean you can’t think big. Here’s one of the early sketches of what they had in mind:

But instead of spending years building the whole product, and then finding out if the assumptions hold, 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 driving metric was “how many milliseconds does it take from when I press Play to when I hear the music?”. It should play pretty much instantly, and continue playing smoothly without any stuttering!

“We spent an insane amount of time focusing on latency, when no one cared, because we were hell bent on making it feel like you had all the world’s music on your hard drive. Obsessing over small details can sometimes make all the difference. That’s what I believe is the biggest misunderstanding about the minimum viable product concept. That is the V in the MVP.” -Daniel Ek, co-founder and CEO

Once they had something decent, they started testing on themselves, their family, and friends.

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 – and they quickly got the answers they needed. Yes, it was technically possible. And yes, people absolutely loved the product (or more like, what the product can become)! The hypotheses were validated! This running prototype helped convince music labels and investors and, well, the rest is history.

Example 2: Minecraft

Minecraft is one of the most successful games in the history of game development, especially if you take development cost into consideration. Minecraft is also one of the most extreme examples of the release-early-and-often mindset. The first public release was made after just 6 days of coding, by one guy ! You couldn’t do much in the first version – it was basically an ugly blocky 3d-landscape where you can dig up blocks and place them elsewhere to build crude structures.

That was the skateboard.

The users were super-engaged though (most developer-user communication happened via Twitter, pretty funny). Among the early users were me and my four kids.  Over hundred releases were made during the first year. Game development is all about finding the fun (some game companies I’ve worked with use the term “Definition of Fun” instead of “Definition of Done”), and the best way to do that is by having real people actually play that game – in this cases thousands of real people who had actually paid to try the early access version and therefore had a personal incentive to help improve the game.

Gradually a small development team was formed around the game (mostly 2 guys actually), and the game became a smash hit all over the world. I don’t think I’ve met any kid anywhere who doesn’t play Minecraft. And last year the game (well, the company that was formed around the game) was sold to Microsoft for $2.5 billion. Quite amazing.

Example 3: Big Government Project

Around 2010 the Swedish Police started a big initiative to enable police to spend more time in the field and less time at the station – PUST (Polisens Utrednings STöd). A fascinating project, I was involved as coach and wrote a book about what we did and what we learned (Lean from the Trenches).

 

The idea was to put laptops in the cars, and customized software to give police access to the systems they need in real-time, for example while interrogating a suspect (this was the pre-tablet age).

They had tried to build similar systems in the past and failed miserably, mainly because of Big Bang thinking. They told me that one of their previous attempts took 7 years from inception to first release. SEVEN YEARS! By then of course everything had changed and the project was a total failure. So this time they wanted to do it differently.

The 60-person project (later referred to as “PUST Java”) succeeded surprisingly well, especially for being a big government project (it even came second in CIO Awards “Project of the Year”). 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.

 

The first version, 1.0, was their skateboard.

It was a small system, supporting just a couple of crime types, and it was field-tested on a handful of cops in Östergötland (a region in Sweden). Other crime types had to be dealt with the old way – drive to the station and do paperwork. They knew they were guinea pigs, and that the product was nowhere near finished. But they were happy to test it, because they knew the alternative. They had seen what kind of crappy systems come out of processes that lack early user feedback, and now they finally had a chance to influence a system while it was being built!

Their feedback was harsh and honest. Many of our assumptions flew out the window, and one of the big dilemmas was what to do with all the carefully crafted Use Case specifications that were getting less and less relevant as the real user feedback came in (this was an organization with a waterfall history and a habit of doing big upfront analysis).

Anyway, long story short, the early feedback was channeled into product improvements and, gradually, as the those cops in Östergötland started liking the product, we could add more crime types and spread it to more regions. 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. We had done so many releases, so much user testing, that we slept well on the night of the nationwide release.

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, but Internal studies estimate that the cost to Swedish society (because the police were handicapped by the horrible system) was on the order of €1 Billion!

Pretty expensive way to learn!

Example 4: Lego

I’m currently working at Lego, and I’m amazed by their ability to deliver new smash-hits, year after year without fail. I hear lots of interesting stories about how they do this, and the common theme is prototyping and early user testing! I often see groups of kids in the office, and designers collaborate with local kindergartens and schools and families to field-test the latest product ideas.

Here’s a recent example – Nexo Knights (released Jan 2016):

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!”. Oops. So the designers kept iterating and testing until they found a design that worked with the kids. I bet even you can see who’s good and who’s evil in the picture above…

Not sure exactly where the skateboard is in this story, but you get the idea – early feedback from real users! Don’t just design the product and build the whole thing. Imagine if they had built the product based on their original design assumptions, and learned about the problem after delivering thousands of boxes to stores all over the world!

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.

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.

There was no skateboard!

Why not? Because skateboards aren’t Awesome (at least not if you’re expecting a car), and Lego’s culture is all about delivering Awesome experiences! If you work at Lego HQ in Billund, Denmark you walk past this huge mural every day:

Translates roughly to “Only the best is good enough”. It has been Lego’s guiding principle ever since the company started 80+ years ago, and has helped them become one of the most successful companies in the world. But in this case the principle was misapplied. The hunt for perfection delayed vital feedback, which meant mistaken assumptions about what the users like and don’t like. The exact opposite of Minecraft.

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. So there was most likely a skateboard, and a bicycle, and so on, but those products never reached real users. That’s not how Scrum is intended to be used.

It was an expensive failure, but Lego learned from it and they are constantly getting better at early testing and user feedback.

Improving on “MVP”

And that (deep breath…) brings me to the topic of MVP – Minimum Viable Product.

The underlying idea is great, but the term itself causes a lot of confusion and angst. I’ve met many customers that are like “No Way do I want an MVP delivery –  that’s the last delivery I’ll get!” All too often teams deliver the so-called Minimum Viable Product, and then quickly get whisked away to the next project, leaving the customer with a buggy, unfinished product. For some customers, MVP = MRC (Minimum Releasable Crap).

I know, I know, this comes down to bad management rather than the term MVP, but still… the term invites misunderstanding. “Minimum” and “Viable” mean different things to different people, and that causes problems.

So here’s an alternative.

First of all, replace the word “Minimum” with “Early”. The whole idea behind releasing an MVP is to get early feedback – by delivering a minimum product rather than a complete product, we can get the feedback earlier.

Few customers want “minimum” but most customers want “early”! So that’s our first change:

Minimum => Earliest

Next, remove the word “Viable” since it’s too vague. Your “viable” is my “horrible”. Some people think Viable means “something I can test and get feedback from”, others think it means “something the customer can actually use”. So let’s be more explicit and split it into three different things:

 

 

Earliest Testable Product is the skateboard or bus ticket – the first release that customers can actually do something with. Might not solve their problem, but it generates at least some kind of feedback. We make it very clear that learning is the main purpose of this release, and that any actual customer value will be a bonus.

 

Earliest Usable Product is perhaps the bicycle. The first release that early adopters will actually use, willingly. It is far from done, and it might not be very likeable. But it does put your customers in a better position than before.

 

Earliest Lovable Product is perhaps the motorcycle. The first release that customers will love, tell their friends about, and be willing to pay for. There’s still lots to improve, and we may still end up with a convertible, or a plane, or something else. But we’ve reached the point where we have a truly marketable product.

I considered adding an even earlier step “Earliest Feedbackable Product”, which is basically the paper prototype or equivalent that you use to get your first feedback from the customer. But four steps seems too many, and the word Feedbackable….. ugh. But nevertheless, that is also an important step. Some would call a paper prototype the Earliest Testable Product, but I guess that comes down to how you define Testable. Check out Martin’s MVP Guide to learn more – he’s got plenty of super-concrete examples of how to get early feedback with minimum investment.

Of course people can still misinterpret Earliest Testable/Usable/Lovable, but it’s at least one step more explicit than the nebulous Minimum Viable Product.

Takeaway points

OK time to wrap it up. Never thought it would get this long, thanks for sticking around! Key takeaways:

  • Avoid Big Bang delivery for complex, innovative product development. Do it iteratively and incrementally. You knew that already. But are you actually doing it?
  • Start by identifying your skateboard – the earliest testable product. Aim for the clouds, but swallow your pride and start by delivering the skateboard.
  • Avoid the term MVP. Be more explicit about what you’re actually talking about. Earliest testable/usable/lovable is just one example, use whatever terms are least confusing to your stakeholders..

And remember – the skateboard/car drawing is just a metaphor. Don’t take it too literally :o)

PS – here’s a fun story about how my kids and I used these principles to win a Robot Sumo competition :o)

Thanks Mary Poppendieck, Jeff Patton, Alistair Cockburn, Anders Haugeto, Sophia, colleagues from Crisp, Spotify and Lego, and everyone else who gave tons of useful feedback.

78 Comments

  • 1
    Stan
    2016-01-25 - 16:32 | Permalink

    Hey Henrik,
    Firstly, thanks for this article and explanation. You made a great job on this and I would like to thank you.
    Secondly, I am from those who critique your metaphor and here is why:
    1) There is another image with a completely wrong sense. You can find it here: https://www.linkedin.com/nhome/updates?topic=6093258891330609152 (also, there you can find some comments, why personally I don’t like). Its a shame, that the version I shared in this link is more popular than the original image (yours). As you can compare both images, there is a big differences in user’s emotions in the bottom line of the product development (in that replica user is happy with the skate, which is wrong). So this moment creates a huge misunderstanding.

    2) You found the worst possible metaphor ever! Really! If our target is to build a car, why we are not watching how other people drive cars? OK, I like your bus ticket way more better, but in your example we speak about cars. How bus ticket can move me closer to the car production? (sure it will take me closer, but more to the bus creation or travel experience, rather than to the car).

    • 2
      2016-01-27 - 11:07 | Permalink

      Hi Stan
      My take on your second point is that if we take it back tot he idea of User Stories we wouldn’t be defining the end result of ‘I want a car’. This method wouldn’t aim to engineer the solution. For example when you questioned the user more deeply their ultimate goal might be I want to be able to travel from A to B as quickly and easily as possible rather than ‘build me a car’. So the metaphor works in terms of how can we come up with the best way to get from A to B. The first iteration may not be the best but it achieves the result. The feedback and iterations then lead to the end result which may be a car. It may evolve beyond a car to some kind of flying machine perhaps a. Why do we have to stop when we have built a car?

    • 3
      2016-02-09 - 17:41 | Permalink

      Hi Stan, may be you did not get the intention of this article: the target was’t to build a car! The user/customer need was to travel from A to B. Depending on the context/discovered needs you either end up with a bike, motorbike, cabrio, or even a bus….

  • 4
    2016-01-25 - 17:01 | Permalink

    Here’s another real-life example, which happens to match exactly your analogy:
    Better Placehttps://en.wikipedia.org/wiki/Better_Place who attempted to build a battery-swap electric car, with a matching network of battery swap stations, and famously stated that “they won’t start selling cars until the whole network of charging stations is operational”, at least that’s how it was stated in Israel, vs. gogorohttps://www.gogoro.com/ who built an electric scooter, using the exact same concept, but started by deploying it only in Taipei City. The former burned through 1.5 Billion US Dollars of investors money, and crashed. The latter seems to be on the path to success, is now looking to expand beyond Taipei.

  • 5
    2016-01-25 - 19:28 | Permalink

    […] article by Henrik Kniberg (@henrikkniberg) where he tries to explain the concept of MVP as well: http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp.  I personally love his analogies to ‘Earliest Testable Product’, ‘Earliest Usable […]

  • 6
    2016-01-26 - 10:50 | Permalink

    Very good article. What is your experience regarding feedback from users? Is it usually beta users of some sort in order to collect the feedback? This is one of the tricky parts in my experience, getting the actual feedback from sufficient amount of users.

  • 7
    2016-01-26 - 15:10 | Permalink

    […] Image: Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable by Henrik […]

  • 8
    Shayne
    2016-01-26 - 21:25 | Permalink

    Stan, the metaphor is not about building a car. The metaphor is about getting the person from point A to point B. Henrik could have added a sixth step, beyond the car, which was a Star Trek transporter, to solve said problem. Or maybe even a seventh step of bending space itself so that a portal now exists between A and B and it is as simple as walking through a door. These latter two steps would be examples of “the user was expecting a solution of (this), but it turns out he was better off with (that).”

  • 9
    2016-01-26 - 22:25 | Permalink

    In my life I did only one real MVP product. And it is a success. All other tries failed, because creating MVP is difficult. In my opinion most of us – IT boys&girls – love to create a domain, a specification, a acceptance tests scenarios, etc.

    I described this one success on my blog: cfp.help – my first real MVP project. I hope you find it interesting.

  • 10
    2016-01-27 - 23:46 | Permalink

    […] Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable […]

  • 11
    2016-01-28 - 07:19 | Permalink

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

  • 12
    Dalmar Hussein
    2016-02-01 - 01:19 | Permalink

    Really enjoyed this piece, Henrik – clear, thorough, and great examples. Thanks for sharing!

  • 13
    2016-02-02 - 08:51 | Permalink

    Thank you for this article!

  • 14
    Fernando
    2016-02-05 - 03:03 | Permalink

    Great (and long) article!

    I still think that your image does not explain very well what a MVP is. It is not accurate if you read the definition on Lean Startup. I think the problem is the P. It stands for product but in the book it does not say it has to be a product. Two examples: your bus ticket example and Dropbox’s first video.

    If I am not mistaken, it is clear that the FIRST MVP to build a car should not be a skate, a wheel or any other part of a vehicle. I understand the idea of the image but misleads the definition of the MVP.

    Regards!!!

  • 15
    2016-02-05 - 03:37 | Permalink

    […] a great job breaking down his graphic and his preference for Earliest Testable/Usable/Lovable in “Making sense of MVP,” which I highly recommend you read and add to your agile […]

  • 16
    Jayaprakash
    2016-02-07 - 10:20 | Permalink

    Excellent Article !

    2 questions that I had on mind
    1. Skateboard to Car, does it make sense?
    2. Few products that I worked don’t get MVP soon in first few sprints, what do I call them ?

    Both are answered nicely. Thanks for sharing !

  • 17
    2016-02-07 - 15:08 | Permalink

    […] behind it. So if you’re interested in the idea behind this famous visualization, read the original article. In this blog post I’ll only share some of the highlights I’ve taken from the long […]

  • 18
    2016-02-08 - 12:50 | Permalink

    YES! YES! YES! I am totally up for replacing MVP with Earliest Testable Product, for MMP being replaced by Earliest Usable Product, and Earliest Lovable Product to call out the stage that many clients consider their ‘viable’!

    I even had one ‘coach’ (I use that in its loosest sense) tell me to give up using MVP as you describe because “everyone uses MVP to mean the minimum product that they are happy to release”. Since then I’ve felt like I’m beating my head against a wall. So, no more MVP for me; it’s Earliest Testable Product all the way.

    Phew, I can give up the MVP crusade.

  • 19
    2016-02-08 - 14:15 | Permalink

    […] out by someone in order to explain the differences and benefits. I love Kniberg’s drawing as an explanation of MVP (or ‘Earliest Testable Product’ as I agree it should be renamed), but I don’t think […]

  • 20
    2016-02-08 - 23:54 | Permalink

    Very informative article. The analogy is great and I agree it breaks down when taken too literally. Yet it moves the reader into a good frame of mind to understand MVP and useful iteration.

    My experience with new-to-the-world products is that the team is somewhat protected from the “wanting a car” analogy because they never heard of a car before. It’s a bit easier to focus on the problem being solved and the cost of not solving the problem when the prospect can not name the solution.

    I think the article would be slightly more effective were the idea of “ordered a car” dropped and the article subsequently focused on “getting from Point A to Point B”.

    DTL

  • 21
    2016-02-10 - 06:32 | Permalink

    […] From: http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp […]

  • 22
    2016-02-10 - 10:42 | Permalink

    […] Kniberg (Agile/Lean coach en Spotify y Lego) ha escrito un interesante post donde contrapone el concepto de Producto Mínimamente Viable (MVP por sus siglas en inglés) al de […]

  • 23
    Sprouty
    2016-02-10 - 15:34 | Permalink

    I really enjoyed reading this and I also have made the comment about what an MVP means to different stakeholders and customers, they all have their “view”.
    The hadest thing to do is to get a waterfall organisation to identify the most basic thing you can produce and get it out there, then at least you have something to get feedback on !!

    If it’s crap, let them tell you why !!!! Learned=money well spent

    Let them tell you what would be better and when you get to the point of good enough, expose “it” more until each iteration improves “something” this could be the thing or other things which are not always visible to the end user i.e. performance

    I will be using your example and the words “earliest testable product” from now on !!!

  • 24
    2016-02-12 - 13:26 | Permalink

    […] I came across this article by Henrik Kniberg that does a fantastic job of summarizing and refreshing the now-famous […]

  • 25
    2016-02-12 - 15:43 | Permalink

    Great article! Thanks, Henrik 😉

  • 26
    2016-02-12 - 20:50 | Permalink

    […] Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable […]

  • 27
    Kristine Berry
    2016-02-15 - 14:32 | Permalink

    Thank you for this article!! I help coach teams and I plan to use this metaphor when talking about MVP = earliest testable/usable/lovable product.

    Some questions:
    1. Does this idea apply to products that have been in the marketplace for years? To use the metaphor, what happens with the next release of the car? Do you go back and deliver an MVP of Car 2.0?
    2. How does this apply to products that must be “perfect” on the day they release? Like a security system or medical device, where there is a lot of risk to customers if they are not perfect?

    Thanks!!

  • 28
    2016-02-16 - 09:28 | Permalink

    […] comenta Henrik Kniberg, los problemas de entender el MVP y vienen ya del propio nombre… ¿Qué es Mínimo y qué es […]

  • 29
    2016-02-17 - 09:36 | Permalink

    […] alle buone pratiche di Henrik Kniberg e ad un suo esempio che è diventato virale e che trovate qui, nella sua forma […]

  • 30
    Danish mistry
    2016-02-26 - 11:07 | Permalink

    Thanks for this excellent post Henrik.

    As a product manager, the concept of MVP is one that i’ve always struggled with. I think the term as you say is a by word for releasing rubbish out to the customer, and I believe that these should always be used as learning milestones.

    What I wanted to get your feedback on, was two things. First you mention that you MVP or ETP doesn’t necessarily solve the customers problem, but isn’t that the point of this first phase iteration, to essentially understand whether or not the problem is painful enough for the customer to adopt your product? Secondly, there is a thought that unless you make your ‘MVP/ETP’ too lean, users will not engage with it, and you will never yield the results that you are truly looking for, which in turn then creates a cycle for scope creep. How do you convince stakeholders and senior management that you are releasing for testing and learning purposes. it would be interesting in hearing your thoughts about how you draw the line between an MVP/ETP and delivering something which is engaging enough to give you evidence that you are on the right track to product delivery.

  • 31
    Kevin Pedersen
    2016-02-29 - 23:41 | Permalink

    This is the best explanation of the MVP idea i have heard. Totally agree, and thanks for the practical examples. Amazing!

  • 32
    Anna Keavney
    2016-03-02 - 23:18 | Permalink

    Fantastic article and explanation of concepts using visual helpful examples.

  • 33
    arnaud
    2016-03-06 - 20:43 | Permalink

    And so the ETULP concept was born, and quickly replaced the MVP… 🙂

  • 34
    2016-03-11 - 15:45 | Permalink

    Hi Henrik, I really like this post! Informative and great examples (with great potential to learn from and apply).

    I learned from this that the 2 most important points in any product development effort (regardless if developed in Agile or Waterfall mode) are:

    1) Focus on the underlying need the customer wants fulfilled
    2) Create early feedback loops (and keep them going)

    Thanks for delivering my daily learning point!

  • 35
    Mihael Yank
    2016-03-18 - 10:18 | Permalink

    That info available to the understanding of even the teenager, love it! Thank you. I like this kind of content.
    Want to add some little bit info http://mlsdev.com/en/blog/50-types-of-mvp (briefly reveals the essence of the concept of “types of mvp”)

  • 36
    2016-03-18 - 16:13 | Permalink

    […] else? Jon is an advocate of Henrik Kniberg’s more nuanced version of the Minimum Viable Product idea. Henrik talk’s about the concept of a […]

  • 37
    Ayoka Kaiser
    2016-04-01 - 13:27 | Permalink

    WOW, thank you!!!
    This came to me JUST at the right moment – in the early stages of developing my first online course. 🙂
    I already have some beautiful testers lined up but thought I would deliver snippets of content to them to get feedback and then bundle it into a LMS on a website.
    After reading your article I decided to go ahead and set up a free WP site with an LMS plugin and put stuff on there for them to try it out.
    That way I get feedback on content and on tech issues and can then decide if I want to upgrade my site or if a simple site is my perfect bicyle… 😉

    Great writing style and lovely imagery – I thoroughly enjoyed reading and will check out your other posts for sure!

    Thanks again!

  • 38
    2016-04-06 - 03:37 | Permalink

    […] a literal application of Henrik Kniberg’s famous Not Like This, Like This comic to a screen-based software […]

  • 39
    2016-04-09 - 16:59 | Permalink

    […] There are a ton of websites that can teach you this with theory and case studies, but a picture says a thousand words, right? Here’s my favorite interpretation of a minimum viable product, courtesy of Henrik Kniberg: […]

  • 40
    2016-04-18 - 02:38 | Permalink

    […] Making sense of MVP (Minimum Viable Product) at blog.crisp.se Many projects fail badly because they do Big Bang delivery (build the thing until 100% done and deliver at the end). I’ve lost count of the number of failed projects I’ve seen because of this (scroll down for some examples). 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? […]

  • 41
    2016-04-28 - 22:09 | Permalink

    […] picture is made by Henrik Kniberg and described in this blog. Henrik is also stating that his picture is used often, and not always in the right context. So why […]

  • 42
    2016-04-29 - 13:39 | Permalink

    This is an absolutely wonderful article. I have been doing a lot of research on DevOps and you have given some very easy to understand practical examples. Thank you!

  • 43
    2016-04-29 - 17:42 | Permalink

    […] MVP related resources: Making sense of MVP (Minimum Viable Product) Specification by […]

  • 44
    Bart Van Mulders
    2016-05-01 - 13:07 | Permalink

    The definition of Earliest is key in software delivery!

  • 45
    Miles Thomas
    2016-05-05 - 17:33 | Permalink

    Would be good to have your analysis of where the Sinclair C5 micro-car (and other historical micro-cars–UK, German, Japanese, even US model T) fit into the skateboard/car spectrum and approach (why some worked and some didn’t.

    And how to avoid getting feedback from users that they really wanted a faster horse (the famous not-quote from Henry Ford).

  • 46
    2016-05-08 - 23:33 | Permalink

    […] Henrik Kniberg’s post on MVP: Making sense of MVP (Minimum Viable Product) […]

  • 47
    Martin Christensen
    2016-05-09 - 20:52 | Permalink

    Miles, I can try answering the second question since I’m the Crisp resident User Researcher. 🙂

    When I hear people describe what they want, I’ll ask them why they want it, what they would get out of having it. I try to listen for needs and motivators when they answer. When it comes to the not-quote, it’s easy, they want to go faster. When digging i.e. asking why, I bet they would have answered that they needed to transport both themselves and others faster between cities so that they could spend less time travelling for services / with goods. So, they would need several faster horses that could carry more weight. What the solution for this might be, well, Ford was probably lucky or he did a lot of experiments (i.e. MVP’s) we don’t know about.

  • 48
    2016-05-11 - 22:15 | Permalink

    The balance of delivering the mvp and quality aspirations are an emotional balance that takes confidence and commitment. Great article.

  • 49
    2016-05-25 - 04:28 | Permalink

    Hi Henrik,

    Really great article! I love the illustration. It is so powerful to explain the concept of MVP.

    When you are working with a client, it’s quite useful to use the metaphor to manage expectations about the first release.

    Thank you!

  • 50
    2016-05-25 - 13:55 | Permalink

    […] this article Kniberg explains that he has gone off the term “minimum viable product” as it can […]

  • 51
    2016-05-25 - 14:04 | Permalink

    […] this article Kniberg explains that he has gone off the term “minimum viable product” as it can give the […]

  • 52
    2016-05-25 - 14:05 | Permalink

    […] this article Kniberg explains that he has gone off the term “minimum viable product” as it can give the […]

  • 53
    2016-05-25 - 14:12 | Permalink

    […] this article Kniberg explains that he has gone off the term “minimum viable product” as it can give the […]

  • 54
    2016-05-25 - 14:46 | Permalink

    […] this article Kniberg explains that he has gone off the term “minimum viable product” as it can […]

  • 55
    2016-05-25 - 16:24 | Permalink

    […] this article Kniberg explains that he has gone off the term “minimum viable product” as it can give the […]

  • 56
    2016-05-25 - 21:02 | Permalink

    […] this article Kniberg explains that he has gone off the term “minimum viable product” as it can give the […]

  • 57
    2016-05-25 - 22:12 | Permalink

    […] this article  Kniberg explains that he has gone off the term “minimum viable product” as it can give the […]

  • 58
    2016-05-26 - 09:55 | Permalink

    […] this article Kniberg explains that he has gone off the term “minimum viable product” as it can give the […]

  • 59
    2016-05-26 - 19:57 | Permalink

    […] this article Kniberg explains that he has gone off the term “minimum viable product” as it can give the […]

  • 60
    2016-06-01 - 13:48 | Permalink

    […] http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp […]

  • 61
    2016-06-01 - 21:53 | Permalink

    […] Well, according to Henrik Kniberg, the person that drew this picture, “we [should] focus on the underlying need the customer wants to be fulfilled. Turns out that his underlying need is ‘I need to get from A to B faster,’ and a car is just one possible solution to that. “The iterative approach is really a way of delivering less, or finding the simplest and cheapest way to solve the customer’s problem. Minimize the distance to Awesome.” […]

  • 62
    2016-06-15 - 14:10 | Permalink

    […] a great article on understanding what the MVP is. So many people seem to want to finish a project without any sort […]

  • 63
    2016-06-29 - 19:30 | Permalink

    Does this change a little if we are coming off a desktop product, and migrating to the cloud? In a sense, we’ve already done these iterations, gotten the feedback, and are ready to jump in.

  • 64
    2016-06-29 - 21:03 | Permalink

    […] in reading more about how to approach the definition of what an MVP should be, I recommend reading Making sense of MVP by Henrik […]

  • 65
    2016-07-01 - 11:18 | Permalink

    […] The first version should be a proper Earliest Lovable Product (see here and here) […]

  • 66
    2016-07-22 - 16:58 | Permalink

    Hi Henry,

    Loved this post, came across your post a few days back. As I was writing a post on “Top misconceptions about Agile methodologies adoption”, I have connected to your link. Also would like to seek your permission to use “Making-sense-of-MVP-23.jpg” image with proper credit to your blog.

    Thanks
    Abhishek

  • 68
    2016-07-23 - 06:07 | Permalink

    […] So the division of the MVP has to be driven from that perspective. Henrik Kniberg‘s blog post Making sense of MVP (Minimum Viable Product is a must read if you really would like to get a grasp of MVP from grounds […]

  • 69
    2016-08-01 - 15:28 | Permalink

    […] http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp […]

  • 70
    2016-08-03 - 07:43 | Permalink

    […] Recently I found this article: http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp […]

  • 71
    2016-08-19 - 09:56 | Permalink

    […] http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp […]

  • 72
    2016-08-21 - 18:05 | Permalink

    […] In his blogpost Henrik Kniberg talks about how ‘many projects fail badly, because they do Big Bang delivery (build the thing until 100% done and deliver at the end).’ The idea is to not work on delivering the product a 100%, but to ‘focus on the underlying need the customer wants fulfilled’. For example: if a customer wants to get from A to B, a car is just one possible solution, the minimum to fulfill the customers need in this case is not the car, but a skateboard (see picture below). This is also called the Minimum Viable Product or Earliest Testable Product (read the full article here). […]

  • 73
    2016-08-30 - 05:53 | Permalink

    […] Liebesdiener entschärfen. Ich möchte entwerfen, wie man schnell und günstig und im Sinne eines MVP die unendliche Sehnsucht der Menschen stillen könne. Ohne Religion, ohne Drogen, ohne Yoga, ohne […]

  • 74
    2016-09-01 - 13:00 | Permalink

    […] Viable Product (MVP) is a commonly misunderstood term. This video is adapted from Crisp’s blog by Henrik Kniberg explaining his, now famous, MVP drawing. His drawing shows up all over the place, in articles and […]

  • 75
    2016-09-13 - 06:01 | Permalink

    […] 4Henrik explains the diagram in detail here:in the blog post “Making Sense of MVP (Minimum Viable Product)—and Why I Prefer Earliest Testable/Usable/Lovable” (http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp). […]

  • 76
    Alexandr Semichin
    2016-09-16 - 09:40 | Permalink

    Thank Henrik for amazingly valuable article!

  • 77
    2016-10-04 - 10:06 | Permalink

    Great examples!

    It’s really creative approach and great thing about those MVPs is that you don’t have to develop an App or build any sophisticated product to test your assumptions.

    Once, I sold a piece of paper with a map to validate my idea 🙂 -> https://brainhub.eu/blog/2015/12/24/what-is-mvp/

  • 78
    2016-10-26 - 16:45 | Permalink

    Good article!
    I really enjoyed this blog on MVP resources and methodology – thanks for sharing!
    Your inspired us to take one step back and write a post on How Much Does It Cost to Make an App? You can check it.
    Might be worth adding to your article?
    Either way, keep up the great work!

  • Leave a Reply

    Your email address will not be published. Required fields are marked *