Making sense of MVP (Minimum Viable Product)

a couple of years ago Henrik Newberg drew this picture and started using it in various presentations about agile and lean development since then the drawing has gone viral it shows up all over the place in articles and presentations and even in a book by Jeff Patton called user story mapping many people say that the drawing really captures the essence of iterative and incremental development Lean Startup and MVP thinking however some misinterpreted which is quite natural when you take a picture out of its original context some criticized it for oversimplifying things which is true the picture is however 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 Henrik figured it was time to explain the thinking behind it so here is an extract from Hendrix blog first example not like this the top row illustrates a common misconception about iterative incremental product development also known as agile many projects fail badly because they do BIGBANG delivery they build a thing until it's 100% done and deliver it right at the very end I've lost count of the number of failed projects I've seen because of this however when agile is presented as an alternative people sometimes balk at the idea of delivering an unfinished product I mean who wants half a car imagine this yes sir here's our first iteration a front tire what do you think customer will be like why the heck are you delivering a tire to me I ordered a car what am I supposed to do with this either way I'm using the term customer here as a generic term to represent people like product managers product owners and even 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 Marshall car and finally when the product is done the customer is like Thanks finally why didn't you just deliver this to me in the first place and skip all the other useless deliveries in this example he's happy with the final product because it's exactly 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 and 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 but the absence of an actual feedback loop makes it very risky and differently 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 at 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 the car is just one possible solution to that remember the car is just a metaphor think of any kind of customized product development scenario so the team delivers the smallest thing that they can think of that will get the customer testing things and giving feedback some might call it an MVP or a Minimum Viable Product but I prefer to call it the earliest testable product you can call it whatever you like in fact some people even like to call their first release the skateboard version and that's based on this metaphor the customer is unlikely to be happy with us it's nowhere near the car that he ordered but that's okay here's the kicker we're not trying to make the customer happy at this point we might make a few early adopters happy but our main goal at this point is just to learn ideally the team explains this clearly to the customer in advance so that 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 isn't finished this is just the first of many iterations and we're still aiming to build a car but in the meantime please try this and give us as much feedback as possible 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 asked why and he says I hate the color we're like the color that's all and the customer says yeah make it blue either the net it's fine so you've just saved a lot of money not building a 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 customers 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 these 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 actually test something testing a prototype on even a single user or teach you more than nothing but okay back to the skateboard example after playing around with it in the office the customer says ok this is kind of fun and it does get me to the coffee machine faster but it's unstable and I fall off too easily so the next iteration we try to solve that problem or at least learn more about it the customer can now get around the office without falling off happy not really he still wanted that car but in the meantime he's actually using this product and giving us even more feedback his biggest complaint is that it's hard to travel longer distances like between buildings due to the small wheels and lack of brakes so next release the product morphs into something more like a bicycle now the customer can zoom around campus yeehaw we learn some things along the way the customer likes the feeling of fresh air on his face the customers 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 that was originally envisioned in fact while testing out this product we may learn that the pods 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 by the upfront analysis of the customers context and needs good point but in most real-life product development scenarios I've seen no matter how much upfront analysis you do you're still surprised when you put the first real release into the hands of real users and many of your assumptions turn out to be way off so yes do some upfront 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 a bit sweaty so next iteration we add an engine this model is especially suitable for software's and software's well soft you can morph the product as you go as opposed to hard way 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 your customer uses your product it's just that the iterations tend to be a bit longer even actual car companies like Tesla and Toyota do a lot of prototyping before developing a new car model so what now 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 ready a way of delivering less or finding the simplest and cheapest way to solve the customers problem minimize the distance to awesome varies in or again the customer could choose to continue without modifications 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 and 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 the thing a hundred times before and go ahead and just do a big bang build the thing and deliver it when it's 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 the problem you are trying to solve and whom you're trying to solve it for 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 for you this will give you the vitally needed feedback loop and will give both you and your customer control over the project you can learn and make changes instead of just following the plan and hoping for the best

Channel: The CRM Team

Views: 244,534

Rating: 4.9102659 out of 5

Keywords: MVP, the crm team, henrik kniberg, skateboard methodology, agile, scrum, Minimum Viable Product

Id: 0P7nCmln7PM

Length: 11min 47sec (707 seconds)

Published: Mon Aug 01 2016

Reddit Comments

[u/swfanatic717]

Imagine promising to deliver the best damn space car ever, taking 2.5 years to deliver a skateboard, and discovering the only thing you ever need to deliver is a gigantic lazy susan that creaks and groans as it struggles to spin about its center going nowhere while your customers stand on top circlejerking each other to blissful satisfaction

[u/jk_scowling]

But developing an MVP requires focus, something CIG don't have.

Although you could argue that the MVP was quite early as they just needed a way to keep selling ships, the real product. The rest of development is just to keep people dreaming about the vapouware game product and its possibilities, which will never be delivered.

[u/CMDR_Agony_Aunt]

This video needs more pipelines.

[u/Ashgur]

The issue is that the cult is so strong they they LOVE the 1st iteration of a tire. they say it's amazing because no other game make a tire like that.

[u/FluffyGarchomp]

So, I'm an extremely junior software developer, so you might want to take what I have to say with a nice big bag of salt, but even if this is what CIG wants to do with Star Citizen, I don't think they're doing it very well.

This is all just going off my general experience on a few larger software products, but it's not experience as management or as a product/design lead, it's as a lower level implementation specialist.

My experience of "Minimum Viable Product"/"Minimum Lovable Product" has generally been different. With an MVP, you cut features early so you can focus so that you narrow down your focus to a single core deliverable base, and then you start to build things back into your structure.

The other really big thing is that these decisions aren't made by consumers, they're made by product owners, the people who the product is being delivered to, and who have the final say on if something is good enough for now.

I'm not sure what that MVP for Star Citizen would be, since so many different things were promised on release, but in my mind, it would look something like this:

1. We will have a great big empty area in space with a spaceship you can fly around.
2. We will have a great big empty area in space that can allow multi-player up to "9999" players in a given area.
3. We'll add a second spaceship type, and this spaceship will allow multiple players to crew it and fire guns and whatnot, via a menu that lets you select roles (Gunner, Captain, Repairs) or something. You still don't have an actual spaceship interior or whatever yet. But you've at least built up the framework to have spaceships with multiple players, and to have massive multi-player.

I guess past this point is where things get really messy, because Star Citizen promised so much. Based on feedback, maybe your next step would be to focus on internally crewed ships with areas to walk around in them. Maybe it would be to focus on ship looting. But even that would again end up being incremental. What is loot? How much loot can be carried? Okay, now that we've got that out of the way, how do you actually grab it?

I guess the key point I'm trying to make here though, is that you don't try to do everything, and you don't try to do it all at once. You don't just pump in ships that the game can't support, and if you've promised a massively multiplayer online game, you don't let networking take the back end. You don't focus on ship explosions and art, if the ships you already have don't work.

I honestly don't love the skateboard analogy presented here, because in some ways, I think it gives the wrong impression of how agile works. The skateboard to car metaphor is good for thinking in terms of product functionality, like the difference in speed, automation, control, safety, and and user effort required, but it's not great in terms of deliverable. The complexity of making a skateboard and the complexity of making a car are incredibly different. You're using different materials, components, and designs, and there's very little you can re-use from the skateboard into making the car.

[u/HumbrolUser]

I dislike this video, or rather, I dislike the ideas presented. It really seems like 'people pleasing', not what I would want from game development.

So.. they way I see it, as a dev, you better have a vision, and some backbone, because second guessing, or making shit up as you go, really seems like utter mediocrity to me.

I guess an ideal "MVP" for me, as a specator/backer, would be largely something that has lots of features, but less content, but I susupect CIG is on the "less features" and "more content", as if they don't really trust their game to be interesting in the end without lots of content. Which might imo be indicative, if so, that their game/endgame mechanics is weak or funcamentally lacking.

I also think, CIG might perhaps be illiterate, or being a bunch of dyslexics that fear putting things into writing. A personal theory of mine. :) I guess the most likely thing is that they are "big business" now and is prone to cutting corners, as if driven by pragmatism, but not the artistic angle.

Added: I would think that, things have changed from the old games, where pixelated graphics was ok, because the games were dynamic and interesting that way. However with greater fidelity, I think it should be obvious to developers, that old games relied on gimmicks and not immersion, and so, to frame games today off 'gimmicks' and not immersion, is imo a big mistake. Any 'set dressing' mentality, for sake of it being just set dressing, is imo something that can only go wrong because one probably just don't take the task of working with immersion-into-the-game-world serious enough, leaving design upto individual artists to implement random stuff, and probably without being supported by gameplay depth.