(French translation, Spanish translation, Japanese 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.
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).
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?
Hi Jamie, I think it’s very big of you to own up to your past criticism, which may be very well founded. But it appears that you’re being just a tad too literal. The metaphor is great and easily understood if one keeps in mind that it is meant to be a guide. We all know that, but then again, it can be one of those things that we know, but fail to use/do/implement.
I do believe that both of you has a fair point here. BUT (obviously, there is a but.. :)) I lean towards more to Stan to agree with.
So the journey for the end-user is valid. She wants to go from A to B as fast as possible. True. Taking from the cost perspective this problem is harder. Do I want to develop first a prototype and a second one and a third one, etc. and as it evolves these protos are getting more and more complex.
take this MVP concept in consideration and you will understand what i am talking about:
https://qph.fs.quoracdn.net/main-qimg-cc4568fbfb82ddfc040423f850650919
I almost bought the concept, but I believe that this is not lean.
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….
Hi Stan,
I found at this post http://kfginternational.com/blog/your-startup-needs-an-mvp-2/
very interesting statement: “Validation and feedback are always more important than tweaking design features and playing with a new idea.”
Do you agree with this statement?
Thanks in advance!
In agile product development we don’t start with the solution (building a car) we start with a problem to solve (be able to go to work, get 3 kids home, in less than X time, even when its rainy, [add what ever constraints you have]).
It leave space for the best solutions which are not in one genius mind but as a lot more changes to be the fruit of collective intelligence.
Here’s another real-life example, which happens to match exactly your analogy:
Better Place – https://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. gogoro – https://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.
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.
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).”
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.
Really enjoyed this piece, Henrik – clear, thorough, and great examples. Thanks for sharing!
Thank you for this article!
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!!!
Fernando is correct. The MVP (as conceived by Steve Blank and Eric Ries) does not need to be anything that the custmoer can actually use. The methodology described here is Agile. Not Lean.
The fact that he considered including “Earliest Feedbackable Product” but decided against it means that he decided against the Lean methodology and went for Agile. I asked Steve Blank (co-inventor of Lean) this exact question at a presentation he gave my organisation just a few hours ago.
Lean startup, to be precise
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 !
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.
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
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 !!!
Great article! Thanks, Henrik 😉
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!!
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.
This is the best explanation of the MVP idea i have heard. Totally agree, and thanks for the practical examples. Amazing!
Fantastic article and explanation of concepts using visual helpful examples.
And so the ETULP concept was born, and quickly replaced the MVP… 🙂
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!
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”)
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!
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!
The definition of Earliest is key in software delivery!
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).
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.
The balance of delivering the mvp and quality aspirations are an emotional balance that takes confidence and commitment. Great article.
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!
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.
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
Hi, feel free to use the image.
Thank Henrik for amazingly valuable article!
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/
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!
Great post! Clear, great analogy and love the new names.
One question, how might this help with replacing an existing car?
I guess it would only help if you could foster a collaborative relationship with some early users of the new system while others kept the old system (car) running until they were happy with the features.
The ‘replacing an existing car’ is where I struggle with this concept. I think there are 2 options here.
1. As you say, fostering a collaborative relationship with early users is great if its something that is feasible. In this scenario I suppose you may have an Earliest Replaceable Product – the point at which the ‘old car’ can be retired.
2. Where it is not feasible to have an early adopter (e.g. replacing a processing system) you will be able to get the skateboard as your Earliest Testable Product but no matter how good you skateboard then scooter etc is, until it is better than my rusty old car then it isn’t usable. In this case I actually think delivering the tyre is better. As long as I can put the tyre on my old car. If we take this approach the Earliest Testable Product may become a wooden square tyre rather than a skateboard. Followed by wooden round tyre, rubber round tyre, rubber round tyre with alloy wheels……
Like everyone else that’s posting though, I think this is a great article and I am assigning MVP to the bin and replacting it with ETP & EUP (using point 1 above ;).
Great article! It is clear so much.
I love it.
Thank you.
Thank you for your article. Totally agree with you. I want to share with you an article https://softwaredevelopment.ae/complete-must-start-product/ I hope you will find more useful information.
Like music to my ears 🙂
Great piece of information!
It was worth reading this blog focussing on MVP techniques – thanks for such an educative share. Also, the illustrations used are extremely powerful and engaging to demonstrate the genuine concept of MVC.
Thanks for an awesome article! I love how you writing and the way you nailed the text. I found at this post ( http://kfginternational.com/blog/your-startup-needs-an-mvp-2/ ) very interesting statement: “Validation and feedback are always more important than tweaking design features and playing with a new idea.”
Do you agree with this statement?
Thanks in advance!
The best post about MVP! Thank you so much.
I have also written about another MVP concept, it is called: “Fake door — The MVP before the MVP”, you can rwadread about it here:
https://medium.com/dennis-nerush/fake-door-the-mvp-before-the-mvp-61197ed264a3
Great piece of content Henrik, I have one blog related to MVP. Share some thoughts on that, link: https://www.alphalogicinc.com/mvp-unfolding-the-roadmap-to-success-for-your-startup/
MVP and Beta Version Example
This article is in reference to the article “Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable” from the website – https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp by “Henrik” in Crisp’s blog
Henrik’s article is very informative and an excellent job by the writer; and though the example quoted is just a metaphor and should not be considered as a verbatim, I think the example of skateboard, scooter etc., misleads the perspective of MVP (or Alpha Version). I think you could have taken an alternative metaphor say for example “A Wedding Cake” instead of a car. Below is my view on MVP and Beta:
(Please Note – I don’t have very good artistic skills to draw the pictures properly, but I hope I made a sense on what I wanted to say)
1st Example – Like this!! Below are the key points:
1. In each stage of delivering a piece of code, I can get feedback on whether it meets the expectation or not (Eg: fluffiness of the cake, sweetness, flavor of the icing etc.,) and customer will still be happy with this as we are heading in a direction and delivering what customer is actually looking for.
2. In each progressive iterations, the piece of code that is delivered is according to the requirement of the customer (Eg: 1st layer of Vanilla, 2nd layer of strawberry, 3rd layer of chocolate etc.,)
3. In each stage or iteration I will try to incorporate the changes as per the feedback
4. For MVP there won’t be any surprises to the customer on the product delivered
5. As MVP is characterized by minimalism (min. set of features that makes the product verifiable and saleable), in the 4th stage the stacked cake that is delivered has minimum decoration to it.
6. As a Beta version is almost the final product with all the features and characteristics (i.e., a polished and ready to go product), it has all the decorations and additional materials.
2nd Example – Not Like This!!
Points to be considered:
1. In this example, I cannot get relevant feedback from a customer at each stage of delivery.
2. Here I might have a risk of whether the product delivered meets customer expectation. Eg: I would have delivered a “Layer cake” (as shown in the last image) instead of a “Stacked Cake” (which customer has expected as a Wedding cake)
Images and full article is available on LinkedIn :
https://www.linkedin.com/pulse/mvp-beta-version-example-himaja-madineni/?published=t
Good Blog post sir… A good way to explain a prospective customer as well
The first way of building things (products) has been followed historically.
We (humans) managed to make a wheel first, a ‘thing’ which moves without much friction. Second, we connected a pair of a couple of wheels and we managed to create a carrier. Later, we figured out that we can enhance the carrier and make it more ‘beautiful’ and usable. At last, we figured that we can add an engine to the whole system which makes it move without physical effort.
Saying all this, we all ‘know’ the best way to build things but it is more of the execution at the moment of time which defines your journey.
I will question the business change impact of this metaphor. In the first example as bad as it looks when showing the customer various car parts (which in my opinion is not necessary but it is exaggerated in this metaphor), atleast the customer is happy doing his day to day business and will plan around getting ready when he gets the car (he needs to learn driving, get licence, arrange finances etc). In the second approach, we are giving them other means of transports where he had asked for a car. Remember, now along with him doing his daily business, which I am sure is keeping him busy, we are asking him to learn how to skateboard, learn how to cycle (and maybe invest money on buying cycling gear), buy a motorbike for few months (and learn to get licence for the same), and finally do all this for the car. If I am a customer, would I be happy in doing all those things which in the end are of no value (ok I have more skills now in case I have to skateboard again). I wanted a car, please give me a car.
This is true for real life projects as well. Agile works if it meets business needs and if the time they are investing in for interim products is actually useful for the final product. customer’s time is valuable, so we need to treat it with respect. The examples you gave actually supports that all interim products, Swedish police e.g., made sure that all the learnings of first iteration (i.e. one type of crime and fewer customers) are not wasted in the final product.
I fully believe that this is what you mean by Agile, but the metaphor on its own without a whole article is misleading and ignores the fact that customer has a day job as well and is not available to keep learning how to use your interim products all the time.
Hi Henrik,
I would like to ask if there are restrictions (terms of use) in using your image (‘Making-sense-of-MVP-.jpg’) in a post of our company’s blog.
Kind regards
Andre
Feel free to use this or any other of my material, with due reference.
Hi Henrik,
I really love your picture about lean and agile development and would like to know, if I could use it in a presentation of the German Savingsbanks Group.
I would refer to you as the owner of the idea, of course.
Kind regards
Ulrike
Sure, feel free to use it, with due reference.
Thanks for the article, and all the comments are really helpfull
Very helpful! This provides some good guidance to move clients, who cringe at the term Agile, away from the waterfall trap. It’s so important to set expectations and show them that you have a long term plan. Very very helpful!
I really appreciate you taking the time to write this, being honest and open about your experiences. Very inspirational,Keep up the killer work!
Great post Henrik. I refer to this diagram a lot when working with teams. It expresses the purpose of early customer engagement really nicely.
Recently I was shown a similar cartoon where the top car was the same as the bottom car and the smiles were the same magnitude. If you google MVP cartoon you’ll find them. It’s unfortunate that this interpretation has emerged as it seems to suggest you can take either route and get the same results.
Yeah, I’ve seen that other version. Guess everyone has a right to their own interpretation of things 🙂
Hmmm. I was confronted with this Illustration of MVP twice within one week. To be honest, I didn’t got it.
In my understanding agile product development should help us incrementally create a product. By frequently releasing it and asking user for feedback, we are able to make adjustments a learn about the users needs. In my world a MVP would be an early version of my product, with only the most essential features.
The first time I saw the “skateboard”, I immediatly thought: hey that’s a prototype. I learn a lot About user expectations, but it has no single part in common with the final product. In fact, in the skateboard example the development starts 3 times from scratch. We learned a lot, we made nothing. Having made the bicycle, what would I answer when the car is ready? Don’t know, not even started doing it.
I think it’s a good example of fail fast or prototyping, not for MVP.
What can I learn from this:
If I don’t properly write down my acceptance criteria, I will get a skateboard instead of a car.
Hmmm. I was confronted with this illustration of MVP twice within one week. To be honest, I didn’t got it.
In my understanding agile product development should help us incrementally create a product. By frequently releasing it and asking user for feedback, we are able to make adjustments a learn about the users needs. In my world a MVP would be an early version of my product, with only the most essential features.
The first time I saw the “skateboard”, I immediatly thought: hey that’s a prototype. I learn a lot About user expectations, but it has no single part in common with the final product. In fact, in the skateboard example the development start 3 times from scratch. We learned a lot, we made nothing. Having made the bicycle, what would I answer when the car is ready? Don’t know, not even started doing it.
Perhaps I may miss one or two points, but what I learn is:
If I don’t phrase my acceptance criteria properly, I would get a skateboard instead of a car.
A MVP should be some starting point for incremental completion of the final product. If everything needs to be re-done / thrown away, than it was a prototype / fake / fail only.
Hi,
this is a super useful update to your model, and the term “early” is much more palatable for senior stakeholders. I just don’t understand why anyone does big bang and/or avoids user feedback. Release early, get user feedback and evolve the product based on the feedback.
Great article. Thank you.
I addressed the same issue from a slightly different angle: https://www.linkedin.com/pulse/mvp-dont-focus-m-ken-pemberton/
Hmmm. I was confronted with this illustration of MVP twice within one week. To be honest, I didn’t got it.
In my understanding agile product development should help us incrementally create a product. By frequently releasing it and asking user for feedback, we are able to make adjustments a learn about the users needs. In my world a MVP would be an early version of my product, with only the most essential features.
The first time I saw the “skateboard”, I immediatly thought: hey that’s a prototype. I learn a lot About user expectations, but it has no single part in common with the final product. In fact, in the skateboard example the development start 3 times from scratch. We learned a lot, we made nothing. Having made the bicycle, what would I answer when the car is ready? Don’t know, not even started doing it.
Perhaps I may miss one or two points, but what I learn is:
If I don’t phrase my acceptance criteria properly, I would get a skateboard instead of a car.
A MVP should be some starting point for incremental completion of the final product. If everything needs to be re-done / thrown away, than it was a prototype / fake / fail only.
Hi Henrik,
I would like to use the image for a presentation here at Fluor. I will name you as the source. May I use it?
Sure!
emergent design….
That’s probably the best explanation of an MVP concept I’ve seen so far.
Some startups adopt MVP model to excuse their poor quality half-ready product. It shouldn’t work like this! On each stage, the product should be usable and deliver true value! Flexibility, constant communication with your direct customer- this is the key to a successful product!
Think of some world-class marketplaces like Uber or Airbnb. https://clockwise.software/blog/how-to-build-an-online-marketplace/
They have started with only the basic functionality and ugly design. But their users have recognized the value! And now these are two of the most expensive companies worldwide!
Hello Henrik,
Thank you for a very thoughtful article. I loved it; it was very helpful- it’s obvious why it is so popular. You made it easy to understand. Thank you!
Hi Henrik,
your picture visualises the idea of MVP in a very simple and easy to understand way. Therefore I would like to use the picture in a chapter of a book I am currently writing. Of course you will find it with due reference. Is that ok for you?
KR Frank
sure, feel free to do so.
Hi Henrik,
I would like to use your “Not like this… Like this!” diagram in a report I am writing on the purpose of iteration. May I have your permission to do so? I would of course do so with attribution to you.
David
Sure, feel free!
Thank you, Henrik!
I would like to use your “Not like this… Like this!” diagram in a report I am writing on the purpose of iteration. May I have your permission to do so? I would of course do so with attribution to you.
Hi, feel free to use any of my material as long as you reference the source.
Henrik, This is an awesome guide. Very informative and thoughtful article!
Hi Henrik,
I also would like to use your graphic for the discussion on the sense of a MVP and it is far the best and easiest to understood visualization I’ve ever seen. I would of course place a link to this blog post and refer to you as the author of the drawing.
Is this ok for you?
Hi, feel free to use any of my material as long as you reference the source.
Henrik, you’ve changed the world with this image. Thank you so much for it! I’d also like to use it in a book I’m writing on entrepreneurship. May I use it referencing you and this blog post as the source? Thanks in advance.
Will
Hi, feel free to use it with due reference.
Hi Henrik,
I just wanted to say that I’ve just re-read this article again – I reckon I do it twice a year every year – and have sent it on to the new founder I’m working with to help try and explain what we’re trying to achieve by working the way we do, and get him contributing to the process instead of lamenting the lack of the “dream” product that exists in his head.
This is still a fantastically useful article, so I wanted to say thanks for sharing!
Thanks for the feedback, glad you like it!
Henrik, your diagram is an incredible game-changer. Would you mind it if I use it in a book I’m writing for first-time entrepreneurs, The Startup Playbook?
Thanks in advance!
Hi, feel free to use any of my material as long as you reference the source.
After years in IT industry and dealing with Scrum projects I switched myself to real estates industry as a house developer. I wonder how do you think which project management metodology is the best one for that industry?
So:
What’s the cost in terms of rework for transforming a scooter into a bike, or a motorcycle into a car.
You need a better analogy.
Hi Henrik,
would like to use your graphic for a blog post in my company, as it explains the MVP very well. Can I use it, of course with a reference to the original blog post?
Sure, no problem!
Good afternoon Henrik! Really like this model, it connects with people very well. I would like to seek permission to use this in some internal materials for our Design and Innovation teams. Would, of course, reference your blog with proper attribution!!
Hi, feel free to use any of my material with due reference.
Hi, feel free to use any of my material as long as you reference the source.
Hi Henrik, really like this model! I connects very well with people. I would like to use this image in some internal materials for our Design and Innovation teams (will proper attribution of course). Thanks!!
Justin
Sure, as long as you reference with proper attribution.
A nice and informative article. It was a great read on MVP techniques. Thanks
Thanks for the thoughtful article and for sharing it.
Hi Henrik, I would like to use the image for a Linkedin post on Iterative development. Could I use the image?
I will be sure to reference this you and this post in the caption.
Sure!
A nice article. Thanks for sharing.
Thanks for working at giving more definition around this problem – I think the observations of customer sentiment are spot on.
I feel Eric Ries is extremely emphatic that the method of using Agile *Discovery* (and the backing “innovation accounting” methodology that proves progress) – is not applicable to “Well Known” problem domains which generally have Well Known Solutions. He even advocates mainstreaming Lean Startup products into regular accounts as they become part of the “well known” problem / solution landscape of a market.
To summarize how this affects this article: “Someone comparing 10 cars to your car will feel the same toward the skateboard as they feel to the ‘wheel’. Why? Because cars are a “Well Known Problem Domain”. In well known problem domains, agile discovery can be wasteful because it is seeking to define the already well defined.
When companies build “genre defining” products (unknown problem domains) – customers don’t know what they want (or IF they want anything) and builders don’t know what to build – so the expensive Agile Discovery and it’s Innovation Accounting are the most productive way forward.
Agile **Build** methods (versus discovery) can be used to build things in both well known and unknown problem domains – but in well known problem domains there will be a cost to not spiking efforts to get to de facto market expectations (well known solutions) as quickly as possible. One of those is a lack of interest in engaging as an early adopter to give feedback – as pointed out in this article.
Hi Henrik / Mattias,
Can we please reuse this image in a BCS Publishing, book with full reference..?
Thanks,
Ian
Sure!
Hi Henrik, Mattias,
May I use the main MVP image above in a BCS Publishing book with full acknowledgement please?
Thanks,
Ian
Absolutely!
Thanks!!!
hi. i have a question.
how much MVP should be like final product? 25% or 40%?
I would like to ask if there are restrictions (terms of use) in using your image (‘Making-sense-of-MVP-.jpg’) in a post of our company’s blog.
Feel free to use the image, as long as you reference the source.
Hi, feel free to use any of my material as long as you reference the source.
This article is absolutely profound and insightful. Especially in the part of what clients actually feel about MVP and what fears and pains they experience. And these great real-life examples are very helpful to clear up their doubts
Thanks for sharing nice article.
A MVP in this case is that I can walk, what more do I need, well to make me lazy but do things faster than I would do with my two hands and legs. And so on…
The author has a nice picture of a product development or Software Life Cycle (evolution of a project). The second picture that author concentrates is after the first was the aim, but not sure how to. Its like computers 10 or 20 years ago and now what they can do. A few KB disc drives to terrabyte storage drives that are much smaller.
An effort is an effort, and an MVP is a usable product that could not be compromised at any cost.
Clearly you’re not a motorcycle rider or you would understand the one fatal flaw with the progression of happiness in your drawing.
😀
Hi Henrik,
What is the best way to build things, but it is much more the in-the-moment execution that defines your trajectory…I’d like to understand if I can use it in a lean and agile presentation.
I love your image about agile and lean moving forward and would like to understand if I can use it in a presentation of the Savings Bank Set.
Best regards
The analogy of skateboard to car suggests that a car is better and is the best solution which is flawed as a city full of traffic congestion can be better navigated with all of the other transport modes.
Reality is:
Skateboard 🙂
Scooter 🙂
Bicycle 🙂
Motorbike 🙂
Car 🙁
The concept of iterative development is not lost, none-the-less the example is at odds with reality.
Hey Henrik,
Such a nice post.
I wanna add that 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 a 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
Henrik, thank you! Brilliant article!
I have thought so many times of entering the blogging world as I love reading them. I think I finally have the courage to give it a try. Thank you so much for all of the ideas!
The information here is very helpful about skateboard. Knowing these makes it much easier to use. I am very happy to know that. It was nice to see all the information come together in one place. This
blog is too good. Specially the information about best skateboard are too good. All this are looking too good
Thanks for the insightful blog post. MVP and customers’ pains are described with precision. The models of cooperation are crucial here. Cause sometimes if you chose the wrong option, even MVP could become not so affordable.
Sometimes you know the idea and you see it in your dream, but something stop you to achieve it, when you find someone take your hand show you the way, you feel happy. thanks for the valuable knowledge, information and for the way of thinking.
Hi Henrik,
First-time reader here.
I love the enormous value you provide.
I’m so glad to have found the author of the wonderful image that agile practitioners keep putting in front of me. It’s ok – only just that its the bicycle that is the most perfect way to get from a to b…
Wow. This post is really interesting. I enjoy reading this a lot. Thanks for sharing this blog.
“Some might call it an MVP (Minimum Viable Product), but I prefer to call it Earliest Testable Product (more on that further down).”
Back in the 1970s, and through my career, we referred to this as Ugly Version First… Its very old…
when i employed this at my last job, and a ancilary project failed, and the management decided to put everyone aside hoping losing corporate intelligence, cohesion, and such would be better… though they never did get rid of the problem which was an overeducated (harvard yale) management who looked down on everyone… and listened to no one.. even if they came from a high school with 8 nobel prizes, fields medals, etc..
Given they were soooo in on crisis, they did not notice my work. then came time to fire me, and all my projects were suddenly mission critical and the guys at the top could not figure out how i did that…
I said Ugly Version First…
they liked a very ugly screen that did what they want and got improvements over time… it ended up lean and mean… and produced over 900 reports on demand, and delivered them to email inboxes just before they arrived at work….
managment prior to that did this with a manual sustem that lost reports, dropped them, etc…
Too bad for them
I am now doing similar for DOD contracting..
I wont say what eventually happened to them
but at least i moved, got a house, increased my salary, etc.
And yet. Harvard and Yale think laying off a really good programmer with 40 years experience spanning mainframes, medical research, etc.. in favor of complacent job jockies who dont program when they leave work…
is some form of punishment…
how so?
I’d love to print the main image in an 8×10 and give it to my team as a gift before I leave them in a few months. Is there a place I can get a print out or would you mind sharing the higher res version so I could print it myself? Will of course include attribution.
Thanks!
Hi Henrik,
I’m grateful. Thanks for sharing Wonderful article!
Hey, It’s actually pretty amazing to read such a detailed post on MVP. It will add much value to my knowledge. Glad to visit and especially this post.
Hey Henrik,
This article is beneficial. Thank you so much. I also shared this with my team and business partners to explain an anology.
Spotify invests tens of millions of dollars into a microservice architecture that results in much smaller codebases and a higher degree of modularity. The end result is feature development can be significantly different then traditional enterprise/monorepo setups at the cost of large devops teams orchestrating these services together.
Minecraft was in Alpha/Beta for a very long period of time and as (originally) a offline-game used a client based architecture versus the traditional client/server architecture of many software projects.
For these reasons, and more, those example aren’t really supporting the premise of the article. I actually largely agree with some of the overarching themes, but these are cherrypicked examples that don’t survive scrutiny.
This a nice article. Thanks for sharing.
Nice article
Thanks for sharing your thoughts on MVP and introducing the concept of Earliest Testable/Usable/Lovable. It’s a refreshing perspective that emphasizes the importance of delivering value, usability, and even delight from the earliest stages. Shifting the focus from a minimalistic approach to a more user-centered one resonates strongly with me. Looking forward to more insightful content from you!