A few years back, I created an illustration that began to circulate widely within agile and lean development circles. It looked like this:
Image: Visual metaphor illustrating the concept of Minimum Viable Product (MVP) using a car and its iterative stages, from skateboard to a complete car.
This simple depiction unexpectedly went viral, appearing in numerous articles, presentations, and even finding its way into Jeff Patton’s book, “User Story Mapping”. Many people have told me that this drawing effectively captures the core idea of iterative and incremental development, lean startup principles, and the essence of MVP (Minimum Viable Product). However, like any image taken out of context, it’s also been misinterpreted by some and criticized for being overly simplistic – which, in its nature as a metaphor, it is. It’s crucial to remember: this isn’t about actual car manufacturing; it’s a visual analogy, a “Car To Cartoon” representation of product development concepts.
Given its widespread use and the discussions it has sparked, I believe it’s time to delve into the thought process behind this “car to cartoon” metaphor and explain how it can help us better understand the often-misunderstood concept of MVP and iterative product development.
The Misconception: Delivering Car Parts
Let’s begin with what not to do. The top row of the image illustrates a common misunderstanding of iterative, incremental product development, often mistakenly labeled as “Agile”.
Many projects unfortunately stumble because they adhere to a “Big Bang” delivery approach. This involves building a product to completion, aiming for 100% functionality before the first release. The history of software and product development is littered with the remains of projects that failed due to this approach. When Agile methodologies are proposed as an alternative, some might resist the idea of releasing an “unfinished” product. They might think: “Who wants half a car?”. This leads to the flawed execution visualized in the top row. Imagine this scenario:
“Sir, for our first iteration, we present to you… a front tire! What are your thoughts?”
Image: Delivery of a tire as the first iteration, highlighting the unusable nature of isolated parts.
The customer’s likely reaction? “Why are you giving me a tire? I ordered a CAR! What am I supposed to do with this single tire?”
(Note: “customer” here is used broadly to represent product managers, product owners, early users, or anyone providing product feedback).
With each subsequent delivery, the product gets closer to being a complete car, but crucially, it remains unusable for the customer. It’s still just a collection of car parts, not a functional vehicle.
Finally, when the complete car is delivered, the customer might say, “Finally! Thanks! But why didn’t you just deliver this car in the first place and skip all these pointless intermediate deliveries?”.
Image: Final delivery of the complete car, after a series of unusable partial deliveries.
In this simplified example, the customer is depicted as happy with the final product because it’s what they initially ordered. However, in reality, this scenario is often far from the truth. Significant time has passed without real user feedback, making it highly likely that the final product is riddled with design flaws and incorrect assumptions about user needs. The smiley face at the end is, therefore, overly optimistic.
This top row illustrates a “bastardized agile” approach. While it might technically be incremental and iterative in delivery, the absence of a genuine feedback loop renders it highly risky and fundamentally un-agile. Hence, the “Not Like This” heading.
The Right Approach: Focus on the User’s Need
Now, let’s examine the second row of our “car to cartoon” metaphor, which represents the correct way to approach iterative development.
Here, we start with the same initial context: the customer wants a car. But this time, instead of directly building a car, we shift our focus to the underlying need the customer is trying to fulfill. It turns out the fundamental need isn’t necessarily a car itself, but rather, “I need to get from point A to point B more efficiently”. A car is just one potential solution among many. Remember, the “car” is just a metaphor; think of it as any customized product development scenario.
The team begins by delivering the smallest possible thing that allows the customer to start testing and providing feedback. This is what many call an MVP (Minimum Viable Product), but I prefer the term Earliest Testable Product (more on this later).
Image: First iteration delivering a skateboard as the Earliest Testable Product.
You can call it what you like – some even humorously refer to their first release as the “skateboard version” of the product, directly inspired by this “car to cartoon” analogy.
The customer is unlikely to be thrilled with a skateboard if they ordered a car. But that’s perfectly acceptable at this stage. The crucial point is: we’re not aiming for customer satisfaction at this initial stage. We might please a few early adopters or pragmatists who are experiencing a specific pain point, but our primary objective is to learn. Ideally, this is clearly communicated to the customer beforehand, managing expectations and minimizing disappointment.
Unlike the isolated front tire in the first scenario, the skateboard is actually a usable product. It does, to some extent, help the customer move from A to B, albeit not perfectly. We explain to the customer: “Don’t worry, the project isn’t finished. This is just the first of many iterations. We still plan to build a car, but in the meantime, please use this skateboard and give us your feedback.” The guiding principle is to think big (the car), but deliver in small, functionally viable increments (the skateboard).
We might uncover unexpected insights. Imagine the customer tries the skateboard and says, “I hate it because of the color!” We might be surprised and ask, “The color? Is that the main issue?”. And they might respond, “Yes! Make it blue! Other than that, it’s fine!”. In this (admittedly unlikely) scenario, you’ve avoided significant costs by not proceeding to build the entire car based on a potentially flawed initial assumption.
The key question becomes: “What is the quickest and cheapest way to start learning?” Could we deliver something even earlier than a skateboard? Perhaps a bus ticket?
Will a bus ticket solve the customer’s problem? Maybe, maybe not directly, but by offering it and observing the customer’s reaction, we will undoubtedly learn something valuable. Lean Startup methodology provides a robust framework for this, emphasizing the importance of articulating your hypotheses about users and systematically validating or invalidating them through real-world testing.
You don’t need to test on a massive user base, and you don’t even need a fully functional product to test a hypothesis. Testing a simple prototype with even a single user can provide more valuable insights than doing nothing at all.
But let’s return to the skateboard example.
After using the skateboard around the office, the customer provides feedback: “It’s fun and gets me to the coffee machine faster. However, it’s unstable. I fall off too easily.”
So, in the next iteration, we address this specific issue, or at least aim to learn more about it.
Image: Iteration delivering a scooter, addressing the stability issue of the skateboard.
Now, the customer can navigate the office without falling. Are they completely satisfied? Not yet, they still have the original car in mind. But in the meantime, they are actively using this product and providing valuable feedback. Their main complaint now might be that it’s challenging to travel longer distances between buildings due to the small wheels and lack of brakes. So, the next iteration evolves the product into something like a bicycle.
Image: Iteration delivering a bicycle, improving mobility and distance capability.
Now the customer can easily travel across the campus. Through this iterative process, we learn valuable things: the customer enjoys the feeling of fresh air, their transportation needs are primarily focused on moving between buildings on a campus.
The bicycle might even prove to be a superior solution to the originally envisioned car. During testing, we might discover that the campus paths are too narrow for a car anyway. We have potentially saved the customer significant time and money while providing a more suitable product in less time.
You might be thinking, “Shouldn’t we have known this through upfront analysis of the customer’s needs and context?”. That’s a valid point. However, in most real-world product development scenarios I’ve encountered, no matter how thorough your upfront analysis, you’ll still be surprised when real users interact with the first release. Many initial assumptions will inevitably be proven wrong.
So, yes, conduct upfront analysis to gather as much information as possible before development. But don’t over-invest time in it and don’t place excessive trust in its accuracy. Instead, prioritize prototyping and releasing early and often. That’s where genuine learning occurs.
Continuing our story, perhaps the customer’s needs evolve. They occasionally need to travel to another city, and the bicycle is too slow and tiring for longer distances. So, in the next iteration, we add an engine.
Image: Iteration delivering a motorcycle, adding engine power for longer distances.
This iterative model is particularly well-suited for software development because of software’s inherent flexibility. You can “morph” the product as you progress, unlike hardware, where each iteration might require significant rebuilding. However, even in hardware projects, delivering prototypes to observe and learn from user interaction is incredibly beneficial. Iteration cycles might be longer (months instead of weeks), but the principle remains. Even major car manufacturers like Toyota and Tesla heavily rely on prototyping (sketches, 3D models, full-scale clay models) before developing a new car model.
What’s next? Perhaps the customer is perfectly satisfied with the motorcycle. We could potentially conclude the project earlier than initially planned. Many products are burdened with unnecessary complexity and features that are rarely used. The iterative approach is fundamentally about delivering less, focusing on finding the simplest and most cost-effective way to solve the customer’s core problem. It’s about minimizing the path to delivering something truly valuable. A very Zen approach to product development.
Alternatively, the customer might choose to continue, possibly with adjustments to the initial requirements. We might even end up with the exact car originally envisioned. However, it’s far more likely that we gain critical insights along the way and create something slightly, but significantly, different. Perhaps something like this:
Image: Final iteration delivering a convertible car, a better solution than the original requirement by incorporating user feedback.
The customer is ecstatic! Why? Because through the iterative process, we learned that they appreciate fresh air. So, we ended up with a convertible. They got a car after all – but a better car, more tailored to their actual needs, than what was initially planned!
Let’s take a step back and summarize the key takeaways from this “car to cartoon” journey.
Identifying Your Skateboard
The top scenario (delivering isolated car parts) is ineffective because each delivery is unusable for the customer. If you are absolutely certain of your product requirements, if it involves minimal complexity and risk, and if you’ve built similar products countless times before, then a Big Bang approach might be acceptable. Build the entire product and deliver it when finished.
However, most product development endeavors are far too complex and risky for that. The Big Bang approach frequently leads to costly and significant failures. Therefore, the critical question is: What’s your skateboard?
In product development, one of the first steps, after defining the problem you’re solving and for whom, is to identify your skateboard equivalent. Think of the skateboard as a metaphor for the smallest, functional product you can put in the hands of real users to gather real feedback. Or, if it resonates better, use the “bus ticket” metaphor.
This establishes the crucial feedback loop, giving both you and the customer control over the project. You can learn, adapt, and make informed changes, rather than blindly following a plan and hoping for the best.
Let’s look at some real-world examples beyond our “car to cartoon” analogy.
Real-World Examples of Skateboard MVPs
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 now a sophisticated and feature-rich product. But its beginnings were much simpler. I was fortunate to be involved early in its remarkable journey.
As a startup in 2006, Spotify was built on several key assumptions: people would prefer streaming music over owning it, music labels and artists would agree to legal streaming, and fast, stable streaming was technically achievable. Remember, this was 2006 when music streaming (like Real Player) was often a frustrating experience, and music piracy was widespread. The core technical challenge was: “Is it even possible to create a client that streams music instantly when you press ‘Play,’ eliminating the dreaded ‘Buffering’ progress bar?”.
Starting small doesn’t limit big aspirations. Here’s an early sketch of their broader vision:
However, instead of spending years building the complete envisioned product and then testing their assumptions, the developers focused on creating a technical prototype. They loaded it with ripped music from their laptops and experimented relentlessly to achieve fast and stable playback. Their primary metric was “how many milliseconds from pressing ‘Play’ to hearing music?”. The goal was near-instantaneous playback without 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 a functional prototype, they began testing it internally, with family, and friends.
This initial version was far from release-ready. It was unpolished, lacked most features beyond basic playback of a few hardcoded songs, and had no legal agreements or monetization model. It was their “skateboard” – the Earliest Testable Product.
But they boldly put this skateboard in the hands of real users – friends and family – and quickly got the answers they needed. Yes, instant, stable streaming was technically feasible. And yes, people were enthusiastic about the product’s potential! Their core hypotheses were validated! This working prototype became instrumental in convincing music labels and investors, paving the way for Spotify’s subsequent success.
2. Minecraft
Minecraft is one of the most successful games in history, especially considering its development cost. It also exemplifies the “release early and often” philosophy. The first public release came after only 6 days of coding by a single developer, Markus Persson! The initial version was extremely basic – a rudimentary, blocky 3D landscape where users could dig up and place blocks to build simple structures.
This was the “skateboard” of Minecraft.
Despite its simplicity, users were incredibly engaged. Early developer-user communication primarily happened on Twitter, which is quite remarkable in retrospect. Among the early users were myself and my four children. Over a hundred releases were made within the first year. Game development is fundamentally about discovering the “fun factor” (some game studios use the term “Definition of Fun” instead of “Definition of Done”). The most effective way to achieve this is by having real people play the game. In Minecraft’s case, thousands of users who had paid for early access had a direct incentive to help improve the game.
Gradually, a small development team formed around the game (initially just two people), and Minecraft became a global phenomenon. It’s hard to find a child anywhere who doesn’t play Minecraft. And last year, the game (or rather, the company behind it) was acquired by Microsoft for $2.5 billion. A truly remarkable success story originating from a humble “skateboard” MVP.
3. Swedish Police PUST Project
Around 2010, the Swedish Police initiated a major project called PUST (Polisens Utrednings STöd), aiming to equip officers with technology to spend more time in the field and less at police stations. It was a fascinating project I was involved in as a coach, and I later documented our experiences and lessons learned in my book, “Lean from the Trenches“.
The core idea was to equip police cars with laptops and custom software, providing real-time access to essential systems while officers were in the field (this was before tablets became common).
Previous attempts to build similar systems had failed dramatically, largely due to “Big Bang” thinking. They recounted a prior project that took seven years from inception to initial release! By that time, technology and policing needs had evolved so much that the project was essentially a failure upon launch. This time, they aimed for a different approach.
The 60-person “PUST Java” project was surprisingly successful, particularly for a large government initiative (it even won second place in the CIO Awards “Project of the Year“). A key success factor was avoiding building the entire system at once. They divided the project scope along two dimensions:
- By Region: Instead of a nationwide rollout, they started with a single region.
- By Crime Type: Instead of supporting all crime types initially, they focused on just 1-2.
Version 1.0 was their “skateboard.”
It was a limited system, supporting only a few crime types and field-tested by a small group of officers in Östergötland, Sweden. For other crime types, officers had to revert to the old paper-based processes at the station. These officers were aware they were “guinea pigs” and that the product was far from complete. But they were happy to participate because they understood the alternative. They had experienced the pitfalls of systems developed without early user feedback and now had a chance to influence the system’s development as it was being built!
Their feedback was direct and honest. Many initial assumptions were invalidated. A major challenge was adapting to user feedback and dealing with pre-written Use Case specifications that became increasingly irrelevant as real-world user insights emerged (this was an organization with a waterfall development history and a tendency for extensive upfront analysis).
In short, early user feedback drove product improvements. As officers in Östergötland began to appreciate the system, they gradually added more crime types and expanded to other regions. By the time they reached the major 1.4 release, involving nationwide rollout and training for 12,000 officers, they were confident. Extensive releases and user testing meant they could rest easy on the nationwide launch day.
Unfortunately, this success was short-lived. A subsequent project (PUST Siebel) repeated past mistakes, reverting to waterfall thinking, likely due to ingrained habits. Two years were spent on analysis and testing without any external releases or user testing, followed by a Big Bang release of the “next-generation” system to all 12,000 officers simultaneously. It was a complete disaster. After six months of severe operational problems, the project was shut down. The development cost was around €20 million, but internal estimates suggest the cost to Swedish society (due to police inefficiency caused by the flawed system) was in the order of €1 Billion!
A very expensive lesson in the importance of iterative development and avoiding the “Big Bang.”
4. Lego
I currently work at Lego, and I’m consistently impressed by their ability to release new hit product lines year after year. I’ve heard many stories about their development processes, and a common theme is prototyping and early user testing! It’s common to see groups of children in the office, and designers regularly collaborate with local kindergartens, schools, and families to test new product ideas.
A recent example is Nexo Knights (released January 2016):
When initially exploring this concept, Lego designers created paper prototypes and tested them with young children. The children’s immediate reaction was: “Hey, who are the bad guys? I can’t tell who’s good and who’s bad!”. Oops. The designers iterated and tested until they arrived at a design that resonated with children. Even in the picture above, it’s likely clear to you who are the heroes and villains.
While the exact “skateboard” in this process isn’t explicitly defined, the principle of early feedback from real users is central. Imagine if they had developed the entire product line based on their initial design assumptions and discovered this fundamental problem after shipping thousands of boxes to stores worldwide!
Lego also has its share of hard-learned lessons. One example is Lego Universe, a massively multiplayer online Lego world. Sounds appealing, right? The problem was overambition. They tried to build the perfect, fully-featured game before releasing it to the public.
Approximately 250 people worked for 4-5 years (due to constant scope creep driven by perfectionism). When it finally launched, the reception was… lukewarm. The finished game was visually impressive, but not as engaging or fun as expected. Lego Universe was shut down after just two years.
There was no “skateboard” for Lego Universe!
Why not? Because skateboards aren’t “Awesome” (especially if you’re expecting a car), and Lego’s culture is deeply rooted in delivering “Awesome” experiences! At Lego HQ in Billund, Denmark, you see this large mural every day:
It translates roughly to “Only the best is good enough.” This principle has guided Lego for over 80 years, contributing to its global success. However, in the case of Lego Universe, this principle was misapplied. The pursuit of perfection delayed crucial feedback, leading to flawed assumptions about user preferences. This is the opposite of the Minecraft approach.
Interestingly, the Lego Universe teams were actually using Scrum and iterative development – similar to the Minecraft team. However, their releases were only internal. There likely was a skateboard, bicycle, and so on, but these iterations never reached real users. This is not the intended use of Scrum.
Lego Universe was a costly failure, but Lego learned from it and continues to improve its early testing and user feedback practices.
Beyond MVP: Earliest Testable, Usable, and Lovable
This brings us to the concept of MVP – Minimum Viable Product.
While the underlying principle is excellent, the term “MVP” itself often creates confusion and anxiety. I’ve encountered customers who react with, “No way do I want an MVP delivery – that sounds like the last delivery I’ll get!”. Too often, teams deliver a so-called Minimum Viable Product and are then immediately reassigned to the next project, leaving the customer with a buggy, incomplete product. For some customers, MVP = MRC (Minimum Releasable Crap).
I understand that this is often a result of poor management rather than a flaw in the MVP concept itself. However, the term itself invites misinterpretations. “Minimum” and “Viable” are subjective and mean different things to different people, leading to communication breakdowns.
Therefore, let’s explore an alternative framework.
First, replace “Minimum” with “Earliest.” The core purpose of releasing an MVP is to gather early feedback. By delivering an early product, rather than a complete one, we can get feedback sooner.
Few customers desire “minimum,” but most value “early”! So, our first change:
Minimum => Earliest
Next, let’s clarify “Viable,” as it’s too ambiguous. Your “viable” might be my “terrible.” Some interpret “Viable” as “something I can test and get feedback from,” while others see it as “something the customer can actually use.” Let’s be more specific and break it down into three distinct stages:
Earliest Testable Product (ETP) is like the skateboard or bus ticket – the very first release that allows customers to interact with something tangible. It might not fully solve their problem, but it generates initial feedback. We emphasize that the primary goal of this release is learning, with any customer value being a bonus.
Image: Reiteration of the skateboard as an example of Earliest Testable Product.
Earliest Usable Product (EUP) is perhaps represented by the bicycle. This is the first release that early adopters will willingly use. It’s still far from complete and might not be very polished or delightful, but it genuinely improves the customer’s situation compared to the previous state.
Image: Reiteration of the bicycle as an example of Earliest Usable Product.
Earliest Lovable Product (ELP) is akin to the motorcycle. This is the first release that customers will truly love, recommend to others, and be willing to pay for. There’s still room for improvement, and we might still evolve towards a convertible, a plane, or something unexpected. But at this stage, we have a genuinely marketable product.
Image: Reiteration of the motorcycle as an example of Earliest Lovable Product.
I considered adding an even earlier stage, “Earliest Feedbackable Product,” which would be analogous to a paper prototype or similar tools for initial feedback gathering. However, four stages seemed excessive, and “Feedbackable” is somewhat awkward. Nevertheless, this initial feedback step is crucial. Some might consider a paper prototype as the Earliest Testable Product, but this depends on your definition of “Testable.” For more concrete examples of early feedback techniques with minimal investment, I recommend checking out Martin’s MVP Guide.
Of course, people can still misinterpret Earliest Testable/Usable/Lovable, but it offers a more explicit and nuanced framework than the often-vague Minimum Viable Product.
Key Takeaways
To summarize and wrap up this rather lengthy discussion – thank you for reading this far! Here are the key takeaways regarding MVP and iterative product development, visualized through our “car to cartoon” metaphor:
- Avoid Big Bang Delivery: For complex and innovative product development, steer clear of the Big Bang approach. Embrace iterative and incremental delivery. You likely already know this, but are you truly practicing it?
- Start with Your Skateboard: Begin by identifying your “skateboard” – the Earliest Testable Product. Aim high, but humble yourself and start with the most basic functional iteration.
- Rethink “MVP”: Consider moving beyond the term “MVP.” Be more precise about what you’re actually aiming for. Earliest Testable/Usable/Lovable is just one alternative framework; use whatever terminology resonates best and minimizes confusion with your stakeholders.
And finally, always remember – the skateboard/car drawing is just a “car to cartoon” metaphor. Don’t interpret it too literally! It’s a simplified, visual representation to aid understanding, not a rigid blueprint for product development.
PS – For a fun, real-world example of applying these principles, check out the story of how my kids and I used iterative development to win a Robot Sumo competition :o)
Thanks to Mary Poppendieck, Jeff Patton, Alistair Cockburn, Anders Haugeto, Sophia, colleagues from Crisp, Spotify and Lego, and everyone else who provided invaluable feedback.
