A few years ago, I created a visual and started incorporating it into presentations about agile and lean development:
This “car image” illustration quickly went viral. It’s been featured widely in articles, presentations, and even in Jeff Patton’s book, “User Story Mapping” – which I highly recommend. Many people find that this simple drawing effectively captures the core ideas of iterative and incremental development, lean startup principles, and the concept of an MVP (Minimum Viable Product). However, when taken out of context, some people misinterpret it, which is understandable. Some critique it for being too simplistic, and that’s a fair point. This “car image” is a metaphor, after all. It’s not literally about building cars; it’s about product development in general, using a car as a relatable visual analogy.
Given its widespread use, I felt it was time to explain the thought process behind this “car image” and clarify its intended message.
The Misconception: The “Not Like This” Approach
The top row of the illustration highlights a common misunderstanding of iterative, incremental product development, often associated with Agile methodologies.
Many projects unfortunately fail due to the “Big Bang” delivery approach – developing the entire product until it’s supposedly 100% complete and only then releasing it. I’ve witnessed countless project failures because of this all-or-nothing strategy. When Agile is presented as an alternative, some resist the idea of releasing a product that’s not fully finished. They might ask, “Who wants half a car?”. Imagine this scenario:
“Sir, here’s our first iteration: a front tire. What are your thoughts?”
The customer’s likely reaction is, “Why are you giving me a tire? I ordered a CAR! What am I supposed to do with just this?”.
(For clarity, I’m using “customer” broadly to represent product managers, product owners, and early-adopter users).
With each subsequent delivery, the product gets closer to completion, but the customer remains frustrated because they still can’t actually use the product. It’s still just a collection of car parts.
Finally, when the complete product is delivered, the customer might say, “Thanks! Finally! Why didn’t you just deliver this in the first place and skip all these useless partial deliveries?”.
In this simplified example, the customer is satisfied with the final car because it’s what they originally ordered. However, in reality, this is rarely the case. Significant time has passed without real user testing, so the final product is often filled with design flaws based on initial, and often incorrect, assumptions about user needs. Therefore, the smiley face at the end of this scenario is quite optimistic.
This first row, “Not Like This”, represents a distorted or “bastardized” version of agile. While it might technically be incremental and iterative in delivery, the lack of a genuine feedback loop makes it extremely risky and certainly not truly agile.
The Right Approach: The “Like This!” Method
Now, let’s examine the second row of the “car image” illustration, which demonstrates the preferred approach.
Here, we begin with the same starting point – the customer wants a car. But this time, we don’t simply aim to build a car directly. Instead, we prioritize understanding the customer’s core need. It turns out their fundamental need is “I need to get from point A to point B more efficiently,” and a car is just one potential solution. Remember, the car is a metaphor; this applies to any kind of custom product development.
So, the team focuses on delivering the smallest possible product that allows the customer to start testing and provide feedback. Some might call this an MVP (Minimum Viable Product), but I prefer the term Earliest Testable Product (more on this later).
You can call it whatever you like (some even refer to their first release as the “skateboard version” of the product, inspired by this very metaphor).
The customer is unlikely to be thrilled with this initial offering. It’s far from the car they envisioned. But that’s perfectly acceptable at this stage! Here’s the crucial point: our primary goal at this stage is not to make the customer immediately happy, but to learn. We might satisfy a few early adopters (or pragmatists in pain), but our main objective is to gather learning and validation. Ideally, this is clearly communicated to the customer upfront, managing expectations and minimizing potential disappointment.
However, unlike the front tire in the first scenario, the skateboard is actually a usable product. It helps the customer move from A to B, albeit not perfectly, but it’s a small improvement over nothing. We communicate to the customer: “Don’t worry, the project isn’t finished. This is just the first of many iterations. We are still working towards a car, but in the meantime, please use this skateboard and give us your feedback.” The principle is to think big, but deliver value in small, functional increments.
We might uncover surprising insights. Imagine the customer dislikes the skateboard and, when asked why, says, “I hate the color.” We might be surprised, but if the customer continues, “Yeah, make it blue! Otherwise, it’s fine!”. In this scenario, you’ve potentially saved a significant amount of resources by not building the car based on potentially flawed initial assumptions! While this color preference is a simplistic example, it highlights the power of early feedback.
The key question becomes: “What is the most affordable and quickest 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 core transportation problem? Maybe, maybe not entirely, but we will definitely learn something valuable by putting this solution in the hands of real users. Lean Startup provides a valuable framework for this, emphasizing the importance of formulating hypotheses about users and systematically validating or invalidating them through testing and feedback.
You don’t need to test on all users or build a fully functional product to gain valuable insights. Testing a prototype, even with just one representative user, will yield more learning than doing no testing at all.
But let’s return to the skateboard example.
After using the skateboard within the office, the customer provides feedback: “It’s kind of fun and gets me to the coffee machine faster. But it’s unstable. I fall off too easily.”
In the next iteration, we address this issue, or at least investigate it further to understand it better.
Now the customer can navigate the office more reliably without falling!
Is the customer completely satisfied? Not yet, they still desire that car. However, crucially, they are now actively using the product and providing ongoing feedback. Their primary complaint now is its limited range for longer distances, like traveling between buildings, due to the small wheels and lack of brakes. So, in the next iteration, the product evolves into something resembling a bicycle.
Now the customer can easily travel around the campus. Success!
Through this iterative process, we learn valuable insights. The customer enjoys the feeling of fresh air. Their transportation needs are primarily focused on moving between buildings on a campus.
The bicycle might actually be a superior solution to the originally envisioned car. In fact, through user testing, we might discover that the campus paths are too narrow for a car anyway. We’ve potentially saved the customer significant time and resources and delivered a more suitable product in less time!
You might be thinking, “Shouldn’t we have known this already through upfront analysis of the customer’s context and needs?” That’s a valid question. However, in most real-world product development scenarios I’ve encountered, regardless of the depth of upfront analysis, surprises inevitably emerge when the first real release is put in front of actual users. Many initial assumptions often prove to be inaccurate.
So, yes, conduct upfront analysis and gather as much information as possible before development begins. But avoid spending excessive time on it and don’t place too much faith in its absolute accuracy. Instead, prioritize prototyping and early releases. This is where the most valuable learning truly occurs.
Let’s continue the story. Perhaps the customer’s needs expand. Sometimes they need to travel to another city, and a bicycle is too slow and tiring for longer distances. Therefore, in the next iteration, we add an engine.
This iterative development model is particularly well-suited for software, due to software’s inherent flexibility. You can “morph” the product as you progress, unlike hardware where significant rebuilding is often required for each iteration. However, even in hardware projects, delivering prototypes to observe and learn from user interaction provides immense value. Iterations might be longer in hardware (months instead of weeks), but the principle remains. Even major car manufacturers like Toyota and Tesla heavily utilize prototyping (sketches, 3D models, full-scale clay models, etc.) before developing a new car model.
So, what’s next? Again, the customer might be perfectly happy 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, or identifying the simplest and most cost-effective way to solve the customer’s 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 iterating, 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 will gain vital insights along the way and arrive at a slightly different, and potentially better, final product. Like this:
The customer is overjoyed! Why? Because through the iterative process, we learned that they appreciate the feeling of fresh air, leading us to create a convertible. They did get a car after all – but a better car, more aligned with their actual needs, than originally planned!
Let’s take a step back and summarize.
What’s Your Skateboard?
The top scenario (delivering a front tire) is ineffective because we consistently deliver components that are unusable for the customer. If you have absolute certainty in your product – low complexity, minimal risk, and extensive prior experience building similar products – then the Big Bang approach might be acceptable. Build the complete product and deliver it when finished.
However, most product development endeavors are far too complex and risky for this approach. The Big Bang strategy frequently leads to costly and significant failures. Therefore, the crucial question is: What’s your skateboard?
In product development, one of the initial steps (after defining the problem you are solving and for whom) should be identifying your skateboard equivalent. Think of the skateboard as a metaphor for the smallest, most basic product you can place in the hands of real users to gather genuine feedback. Or, if “bus ticket” resonates better, use that metaphor.
This will establish the vital feedback loop, granting both you and the customer greater control over the project. You can adapt and refine based on real-world learning, rather than simply adhering to a plan and hoping for the best outcome.
Let’s explore some real-world examples to further illustrate this concept.
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 now a sophisticated and feature-rich product. But it didn’t begin that way. I was fortunate to be involved in the early stages of this incredible journey (and remain involved).
As a startup in 2006, Spotify was founded on several key assumptions: people would prefer streaming music over owning it, music labels and artists would be willing to license their music for streaming legally, and fast, reliable streaming was technically achievable. Remember, this was 2006, when music streaming (like Real Player) was often a frustrating experience, and pirated music was widespread. The core technical challenge was: “Is it even possible to create a client that streams music almost instantly when the Play button is pressed? Can we eliminate the annoying ‘Buffering’ progress bar?”
Starting small doesn’t limit big ambitions. Here’s an early concept sketch of their vision:
However, instead of spending years building the complete envisioned product and then validating their assumptions, the developers focused on creating a technical prototype. They loaded it with ripped music from their laptops and experimented extensively to optimize playback speed and stability. The primary metric was “How many milliseconds elapse between pressing Play and hearing music?”. The goal was near-instantaneous playback and smooth, uninterrupted streaming.
“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 not ready for public release. It was unpolished, lacked features beyond basic playback of a few pre-loaded songs, and had no legal agreements or monetization model. It was their skateboard.
But they boldly put this skateboard into the hands of real users – friends and family – and quickly received the crucial answers they needed. Yes, technically feasible. And yes, people absolutely loved the concept (or rather, the potential of the product)! Their core hypotheses were validated! This working prototype was instrumental in convincing music labels and investors, and the rest, as they say, is history.
Example 2: Minecraft
Minecraft is one of the most successful games in gaming history, especially considering its development cost. Minecraft is also a prime example of the release-early-and-often philosophy. The first public release occurred after just 6 days of coding by a single developer, Markus Persson! The initial version was very basic – a rudimentary, blocky 3D landscape where players could dig and place blocks to build simple structures.
This was their skateboard.
Despite its simplicity, early users were highly engaged. Developer-user communication primarily occurred via Twitter, which is quite remarkable. Among these early adopters were myself and my four children. Over a hundred releases followed in the first year alone. Game development is fundamentally about discovering the “fun factor” (some game companies use “Definition of Fun” instead of “Definition of Done”), and the most effective way to achieve this is to have real people play the game. In this case, thousands of users who had paid for early access had a personal incentive to contribute to the game’s improvement.
Gradually, a small development team formed around the game (primarily two people), and Minecraft became a global phenomenon. It’s hard to find a child anywhere who hasn’t played Minecraft. And in the past year, the game (or rather, the company formed around it) was acquired by Microsoft for $2.5 billion. A truly astonishing success story.
Example 3: Big Government Project
Around 2010, the Swedish Police initiated a large project, PUST (Polisens Utrednings STöd), aimed at enabling officers to spend more time in the field and less time at police stations. It was a fascinating project, and I was involved as a coach, later writing a book about our experiences and lessons learned (Lean from the Trenches).
The idea was to equip police cars with laptops and custom software to provide real-time access to necessary systems, for example, during suspect interrogations (this was before widespread tablet use).
Previous attempts to build similar systems had failed dramatically, largely due to Big Bang approaches. They shared that one prior attempt took seven years from project inception to the first release. SEVEN YEARS! By then, circumstances had drastically changed, and the project was ultimately a failure. This time, they aimed for a different approach.
The 60-person project (later known as “PUST Java”) was surprisingly successful, especially for a large government initiative (it even placed second in the CIO Awards “Project of the Year”). A key success factor was their decision to avoid building the entire system at once. They divided the project scope along two dimensions:
- By Region: Instead of nationwide rollout, they started by releasing to a single region.
- By Crime Type: Instead of supporting all crime types initially, they focused on supporting just one or two.
The initial 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 (a region in Sweden). Other crime types were handled using the old, paper-based methods – requiring officers to return to the station for paperwork. These officers were aware they were essentially guinea pigs and that the product was far from complete. However, they were enthusiastic about testing it because they knew the alternative. They had experienced the shortcomings of systems developed without early user feedback and now finally had the opportunity to influence a system during its development!
Their feedback was direct and honest. Many of our initial assumptions were challenged, and a significant dilemma arose concerning the carefully created Use Case specifications, which became increasingly irrelevant as real user feedback emerged (this was an organization with a waterfall development history and a tendency towards extensive upfront analysis).
In short, the early user feedback directly informed product improvements. As officers in Östergötland began to find the system valuable, they gradually added support for more crime types and expanded its regional deployment. By the time they reached the major release (1.4), with nationwide rollout and training of 12,000 officers, they were confident. Extensive releases and user testing provided such strong validation that the nationwide release was remarkably smooth.
Unfortunately, this success was short-lived. A follow-up project (PUST Siebel) mishandled the approach, reverting to waterfall thinking, likely due to ingrained habits. Two years of analysis and testing without any external releases or user testing, followed by a Big Bang release of the “next generation” product to all 12,000 officers simultaneously. It was a complete disaster, and after six months of significant problems, the entire project was shut down. The development cost was approximately €20 million, but internal studies estimated the cost to Swedish society (due to police inefficiency caused by the flawed system) to be around €1 Billion!
A very expensive lesson learned!
Example 4: Lego
I currently work at Lego, and I’m consistently impressed by their ability to release successful new product lines year after year. I hear many fascinating stories about their product development processes, and a recurring theme is prototyping and early user testing! I often see groups of children in the office, and designers regularly collaborate with local kindergartens, schools, and families to field-test the latest product ideas.
Here’s a recent example – Nexo Knights (released January 2016):
When they initially explored this concept, they created paper prototypes and tested them with young children. The children’s initial reaction was, “Hey, who are the bad guys? I can’t tell who’s good and who’s bad!”. Oops. So, the designers iterated, refining the designs and testing them again until they achieved a design that resonated with children. I’m sure you can easily distinguish the heroes from the villains in the image above…
While the exact skateboard equivalent isn’t explicitly detailed in this story, the core principle is clear – early feedback from real users! Don’t just design a product and build the entire thing based on initial assumptions. Imagine if they had produced Nexo Knights based solely on their initial design concepts and then discovered the problem after shipping thousands of boxes to stores globally!
Lego has also experienced its share of hard-learned failures. One example is Lego Universe, a massively multiplayer online Lego world. Sounds appealing, right? The problem was overambition. They aimed to build the entire game to perfection before releasing it to the public.
Approximately 250 people worked for 4-5 years on the project (due to constant scope creep driven by perfectionism). When it finally launched, the reception was… lukewarm. The finished game was visually impressive but lacked the expected fun factor, leading to its shutdown after just two years.
There was no skateboard!
Why not? Because skateboards aren’t “Awesome” (especially if you’re expecting a car), and Lego’s core culture is centered around delivering “Awesome” experiences! If you work at Lego HQ in Billund, Denmark, you pass this large mural daily:
It translates roughly to “Only the best is good enough.” This principle has been Lego’s guiding philosophy since its inception over 80 years ago and has contributed to its position as one of the world’s most successful companies. However, in the case of Lego Universe, this principle was misapplied. The pursuit of perfection delayed crucial user 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 iterating heavily – similar to the Minecraft developers. However, their releases were only internal. So, a skateboard, bicycle, and so on likely existed internally, but these prototypes never reached real users. This contradicts the intended use of Scrum.
It was a costly failure, but Lego learned from it and continues to improve its early testing and user feedback processes.
Improving on “MVP”
And that (deep breath…) brings me to the topic of MVP – Minimum Viable Product.
The underlying concept is excellent, but the term 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 ever get!”. Too often, teams deliver a so-called Minimum Viable Product and are then quickly reassigned to the next project, leaving the customer with a buggy, unfinished product. For some customers, MVP = MRC (Minimum Releasable Crap).
I acknowledge that this often stems from poor management rather than the term MVP itself, but the term still invites misunderstanding. “Minimum” and “Viable” are subjective and interpreted differently by different people, leading to problems.
So, here’s an alternative framework to consider.
First, replace “Minimum” with “Earliest.” The fundamental purpose of releasing an MVP is to obtain early feedback. By delivering an early product, rather than a fully complete one, we can gather feedback sooner.
Few customers desire “minimum,” but most appreciate “early”! So, our first adjustment:
Minimum => Earliest
Next, remove “Viable” as it’s too ambiguous. Your “viable” might be my “unacceptable.” Some define Viable as “something I can test and get feedback from,” while others interpret it as “something the customer can actually use.” Let’s be more precise and break it down into three distinct stages:
Earliest Testable Product is the skateboard or bus ticket – the very first release that allows customers to interact with and experience something tangible. It might not fully solve their problem, but it generates some form of feedback. We clearly communicate that learning is the primary objective of this release, with any user value being a bonus.
Earliest Usable Product is perhaps the bicycle. The first release that early adopters will willingly use. It’s still far from feature-complete and might not be particularly polished. However, it does offer a tangible improvement over the previous situation for the customer.
Earliest Lovable Product is perhaps the motorcycle. The first release that customers will genuinely love, recommend to others, and be willing to pay for. There’s still room for improvement, and we might ultimately evolve towards a convertible, a plane, or something else entirely. But we’ve reached a point where we have a truly marketable product.
I considered adding an even earlier stage, “Earliest Feedbackable Product,” which would represent the paper prototype or similar tool used to gather initial customer feedback. But four stages seemed excessive, and “Feedbackable” is a bit awkward. Nevertheless, that initial feedback stage is crucial. Some might consider a paper prototype as the Earliest Testable Product, but that depends on your definition of “Testable.” For deeper insights, explore Martin’s MVP Guide – it provides numerous concrete examples of how to gain early feedback with minimal investment.
While people can still misinterpret Earliest Testable/Usable/Lovable, it offers a more explicit and nuanced understanding than the often-vague Minimum Viable Product.
Key Takeaways
Okay, time to conclude. I didn’t expect this to become so lengthy, thank you for staying with me! Here are the key takeaways:
- Avoid Big Bang delivery for complex, innovative product development. Embrace iterative and incremental approaches. You likely knew this already, but are you consistently implementing it?
- Start by identifying your skateboard – the Earliest Testable Product. Aim high, but be humble and begin by delivering the skateboard.
- Be cautious with the term MVP. Opt for more precise language. Earliest Testable/Usable/Lovable is just one example; use terms that are least confusing to your stakeholders.
And remember – the skateboard/car drawing, the “car image” we discussed, is simply a metaphor. Don’t interpret it too literally! :o)
PS – Here’s an amusing story about how my children and I applied these principles 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 valuable feedback.
