A few years ago, I created an illustration that has since become quite popular in agile and lean development circles. It’s often used in presentations and articles, and even made its way into Jeff Patton’s book, “User Story Mapping.” People tell me it effectively captures the essence of iterative and incremental development, lean startup principles, and the Minimum Viable Product (MVP) concept.
The popular illustration depicting iterative product development, often referred to as the “MVP car” metaphor.
However, like any metaphor taken out of context, it’s sometimes misinterpreted or seen as oversimplified. It’s crucial to remember that this is a metaphor – it’s not literally about building cars. It’s about product development in general, using vehicle construction as a relatable analogy. Given its widespread use and occasional misunderstandings, I want to explain the thinking behind this “Bike Car” metaphor and how it applies to building successful products.
The Pitfalls of “Not Like This” Iteration
The top row of the image illustrates a common misconception about iterative and incremental product development, often mistakenly labeled as “Agile.”
Many projects fail because they follow a “Big Bang” delivery approach: building the entire product to 100% completion before delivering anything. I’ve witnessed countless projects derailed by this approach. When Agile is presented as an alternative, some resist the idea of delivering an “unfinished” product. They might think, “Who wants half a car?”. Imagine this scenario:
“Sir, here’s our first iteration – a front tire. What are your thoughts?”
A single tire is delivered as the first iteration, highlighting the lack of usability in this approach.
The customer’s likely reaction? “Why are you giving me a tire? I ordered a CAR! What am I supposed to do with this?”
(For simplicity, I use “customer” here as a general term for product managers, product owners, and early users.)
With each delivery, the product gets closer to completion, but the customer remains frustrated because they can’t actually use anything. It’s still just a collection of car parts.
More car parts are delivered in subsequent iterations, but still no functional vehicle.
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 the useless partial deliveries?”
The complete car is delivered at the end, but significant time has passed without user feedback.
In this overly optimistic example, the customer is satisfied with the final product because it matches their original order. However, in reality, this is rarely the case. Significant time has passed without real user testing, increasing the likelihood of design flaws based on incorrect assumptions about user needs. That final smiley face is often far from reality.
This first row represents a flawed, or “bastardized,” version of agile. While technically it might be incremental and iterative delivery, the absence of a genuine feedback loop makes it incredibly risky and far from truly agile. Hence the “Not Like This” heading.
Embracing “Like This” Iteration: From Bike to Car
Now, let’s examine the second row, which illustrates a more effective approach.
Here, we start with the same context: the customer wants a car. But instead of focusing solely on building a car, we focus on the underlying need the customer wants to fulfill. It turns out their core need is “I need to get from point A to point B faster.” A car is just one possible solution to this need. Remember, the car is a metaphor for any customized product development scenario.
The team delivers the smallest possible thing that allows the customer to start testing and provide feedback. Some call this an MVP (Minimum Viable Product), but I prefer the term Earliest Testable Product (more on that later). In the context of vehicles, it’s like starting with a skateboard.
A skateboard is delivered as the first iteration, providing basic mobility and a platform for feedback.
Call it what you will – some even call their initial release the “skateboard version” of their product, drawing directly from this metaphor.
The customer might not be thrilled with a skateboard when they ordered a car. This is perfectly acceptable! The crucial point here is: we are not aiming for customer delight at this stage. We might satisfy a few early adopters, but our primary objective at this point is to learn. Ideally, this is communicated clearly to the customer upfront, managing expectations and preventing disappointment.
Unlike the front tire in the first scenario, the skateboard is a usable product that helps the customer move from A to B. It’s not ideal, but it’s better than nothing. We explain to the customer, “Don’t worry, the project isn’t finished. This is just the first of many iterations. We still aim to build a car, but in the meantime, please try this and give us your feedback.” Think big, but deliver in small, functional increments.
We might uncover surprising insights. Imagine the customer dislikes the skateboard and says, “I hate the color.” We might be surprised, but if color is their main concern, we’ve saved significant resources by not building a full car! While this specific example is simplistic, it highlights the potential for early feedback to drastically alter development paths.
The key question becomes: “What’s the quickest and cheapest way to start learning?” Could we deliver something even simpler than a skateboard initially? Perhaps a bus ticket?
A bus ticket is presented as an even earlier iteration, focusing on the core need of transportation.
Will a bus ticket solve the customer’s problem? Maybe, maybe not. But we will undoubtedly learn something by putting it in the hands of real users. The Lean Startup methodology emphasizes formulating hypotheses about users and systematically validating or invalidating them.
Testing even a basic prototype with a single user can yield more valuable insights than extensive planning without real-world feedback.
Let’s return to the skateboard example.
After using it around the office, the customer might say, “It’s fun and gets me to the coffee machine faster, but it’s unstable. I fall off easily.”
In the next iteration, we address this issue, or at least gain a deeper understanding of it. We upgrade the skateboard to a scooter, providing more stability.
A scooter is delivered as the next iteration, addressing stability issues identified in the skateboard feedback.
Now the customer can navigate the office without falling! Are they completely satisfied? Not yet; they still desire a car. But they are actively using this product and providing feedback. Their main complaint now is the limited range for longer distances, like traveling between buildings, due to the small wheels and lack of brakes. So, the next iteration transforms the product into a bicycle.
A bicycle is delivered, offering improved range and speed for campus mobility.
Now the customer can efficiently move around campus. We’ve learned valuable information along the way: the customer enjoys the feeling of open air, and their transportation needs are primarily focused on moving between buildings on a campus environment.
The bicycle might actually be a superior solution to the originally envisioned car. Through user testing, we might discover that campus paths are too narrow for a car anyway. We’ve potentially saved the customer significant time and money, delivering a better product in less time!
You might think, “Shouldn’t we have already 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, no matter how much upfront analysis you conduct, you’ll still encounter surprises when real users interact with the first release. Many initial assumptions often prove inaccurate.
Yes, conduct upfront analysis to gather as much information as possible before development. But don’t over-invest time in it and don’t rely too heavily on its accuracy. Prioritize prototyping and releasing early. That’s where genuine learning occurs.
Back to our story. Perhaps the customer’s needs evolve. Sometimes they need to travel to another city, and a bicycle is too slow and tiring. So, in the next iteration, we add an engine, transforming the bicycle into a motorcycle.
A motorcycle is delivered, adding speed and range for longer commutes.
This iterative model is particularly well-suited for software development because software is inherently flexible. Products can be “morphed” as development progresses, unlike hardware where significant rebuilding is often required for each iteration. However, even in hardware projects, delivering prototypes for user observation and feedback is immensely beneficial. Iteration cycles might be longer (months instead of weeks), but the principle remains valid. Even major car manufacturers like Toyota and Tesla heavily rely on prototyping (sketches, 3D models, full-scale clay models) before developing new car models.
What happens next? The customer might be perfectly satisfied with the motorcycle. We could potentially conclude the project earlier than initially planned. Many products are overloaded with features that are rarely used. The iterative approach is essentially about delivering less, or finding the simplest and most cost-effective solution to the customer’s core problem. It’s about minimizing the path to “awesome.” Very Zen.
Alternatively, the customer might choose to continue iterating, with or without modifications to the initial requirements. We might ultimately arrive at the originally envisioned car. However, it’s far more likely that we’ll gain crucial insights along the way, leading to a slightly different, and often better, final product. Perhaps something like this:
A convertible car is delivered as the final iteration, incorporating user feedback and evolving needs.
The customer is thrilled! Why? Because we learned throughout the process that they appreciate the feeling of open air. We delivered a car, but a convertible – a better car than originally planned!
Let’s recap.
Identifying Your “Skateboard” (or “Bike”)
The “Not Like This” scenario (delivering a front tire) fails because each iteration delivers something unusable. If you have absolute certainty about your product – low complexity, low risk, and extensive prior experience – then a Big Bang approach might be acceptable. Build it completely and deliver it when finished.
However, most product development endeavors are too complex and risky for that. The Big Bang approach often leads to expensive and significant failures. Therefore, the crucial question is: What’s your “skateboard” or, perhaps more appropriately in this context, your “bike”?
In product development, after defining the problem and target audience, one of the first steps is to identify your “skateboard” or “bike” equivalent. Think of it as the simplest vehicle, the smallest thing you can place in the hands of real users to gather genuine feedback. This could be a skateboard, a bike, or even a bus ticket, depending on the context.
This establishes a vital 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 outcome.
Let’s examine some real-world examples, moving from simpler “bike” equivalents to more complex “car” scenarios.
Example 1: Spotify Music Player – Starting with a “Bike” Experience
“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 product. But it didn’t begin that way. I was fortunate to be involved early in its development.
In 2006, Spotify started as a startup based on key assumptions: people would stream music rather than own it, labels and artists would permit legal streaming, and fast, stable streaming was technically achievable. Remember, in 2006, music streaming (like Real Player) was often a poor experience, and pirated music was prevalent. The technical challenge was: “Can we create a client that streams music instantly when ‘Play’ is pressed, eliminating the ‘Buffering’ progress bar?”
Starting small doesn’t limit ambitious goals. Here’s an early sketch of their vision:
Instead of spending years building the complete product, they focused on a technical prototype. Developers experimented intensely with ripped music on their laptops to achieve fast, stable playback. The core metric was: “How many milliseconds from ‘Play’ to hearing music?” The goal was near-instant playback, free of 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 tested it internally, with family and friends.
This initial version was far from release-ready. It lacked polish and features, only playing a few hard-coded songs, with no legal agreements or monetization model. It was their “bike” – a functional but basic experience.
However, they boldly put this “bike” in the hands of real users – friends and family – and quickly got crucial answers. Yes, it was technically feasible. And yes, people loved the concept (and its potential). Their core hypotheses were validated! This working prototype helped secure agreements with music labels and attract investors, and the rest is history.
Example 2: Minecraft – A Blocky “Bike” to a Global Phenomenon
Minecraft is one of the most successful games ever, especially considering its development cost. It’s also a prime example of the release-early-and-often approach. The first public release came after just 6 days of coding by one person! The initial version was very basic – an unrefined, blocky 3D world where players could dig and place blocks to build simple structures.
The initial version of Minecraft, a basic “bike” experience focused on core gameplay mechanics.
That was their “bike” – a very rudimentary vehicle.
But users were highly engaged. Early user communication happened mainly through Twitter. Among the early users were my children and myself. Over a hundred releases followed in the first year. Game development is about finding the “fun factor” (some game companies even use “Definition of Fun” instead of “Definition of Done”). The best way to do this is to have real players interact with the game. In Minecraft’s case, thousands of users who paid for early access had a vested interest in helping improve the game.
A small development team gradually formed (primarily two people), and Minecraft became a global phenomenon. I haven’t met many kids who haven’t played Minecraft. Eventually, the company (Mojang) was sold to Microsoft for $2.5 billion. An incredible success story.
Example 3: Swedish Police Project – Iterating from a “Bike” in a Large Organization
Around 2010, the Swedish Police launched a major initiative to enable officers to spend more time in the field and less at stations – PUST (Police Investigation Support). It was a fascinating project, and I was involved as a coach, documenting our learnings in the book “Lean from the Trenches.”
The goal was to equip police cars with laptops and custom software for real-time access to necessary systems, such as during suspect interrogations (this was before tablets were common).
Past attempts to build similar systems had failed spectacularly, mainly due to Big Bang approaches. One previous attempt took seven years from inception to the first release! By then, everything had changed, and the project was a complete failure. This time, they aimed for a different approach.
The 60-person project (later called “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 avoiding building everything at once. They broke down the project along two dimensions:
- By Region: Instead of 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 “bike” – a basic, functional system.
It was a limited system, supporting only a few crime types, field-tested by a small group of officers in Östergötland, Sweden. Other crime types were handled using the old, paper-based methods. These officers knew they were “guinea pigs” and that the system was far from complete. But they were happy to test it because they understood the alternative. They had experienced the failures of systems developed without early user feedback and finally had a chance to influence the system’s development.
Their feedback was direct and honest. Many initial assumptions proved wrong. A major challenge was managing the disconnect between detailed Use Case specifications (a legacy of their waterfall approach) and the evolving user feedback.
Ultimately, early feedback drove product improvements. As officers in Östergötland began to find value in the system, they gradually added more crime types and expanded to more regions. By the time they reached the major release (1.4), with nationwide rollout and training for 12,000 officers, they were confident. Extensive releases and user testing meant they were well-prepared for the large-scale deployment.
Unfortunately, this success was short-lived. A follow-up project (PUST Siebel) reverted to waterfall thinking. Two years of analysis and testing without real releases or user testing preceded a Big Bang “next generation” release to all 12,000 officers. It was a disaster. After six months of severe issues, the project was shut down. The development cost was around €20 million, but internal studies estimated the cost to Swedish society (due to police inefficiency caused by the flawed system) was around €1 Billion!
A very expensive lesson learned.
Example 4: Lego – Building “Bike” Prototypes for Blockbuster Products
I currently work at Lego, and I’m consistently impressed by their ability to create new hit products year after year. A common thread in their process is prototyping and early user testing. I frequently see groups of children in the office, and Lego designers collaborate with kindergartens, schools, and families to test new product ideas.
A recent example is Nexo Knights (released January 2016):
Early in the Nexo Knights concept development, they used paper prototypes and tested them with young children. The children’s initial reaction was, “Who are the bad guys? I can’t tell who’s good and who’s bad!” Oops. Designers iterated and tested until they found a design that resonated with children. Even in the image above, it’s easy to distinguish good from evil.
While the exact “bike” prototype isn’t explicitly detailed, the principle of early feedback from real users is clear. Imagine if Lego had developed the product based solely on their initial design assumptions and discovered this critical issue after distributing thousands of boxes worldwide!
Lego has also experienced failures. Lego Universe, a massively multiplayer online Lego world, is one example. They became overambitious, aiming for perfection before release.
Approximately 250 people worked for 4-5 years on Lego Universe (due to scope creep driven by perfectionism). When it finally launched, the reception was lukewarm. The game was visually stunning but not as fun as expected, leading to its closure after two years.
Lego Universe lacked a “bike” approach.
Why? Because “bikes” aren’t inherently “Awesome” (especially if you expect a “car”), and Lego’s culture is centered on delivering “Awesome” experiences. At Lego HQ in Billund, Denmark, a large mural declares:
Roughly translated, it means “Only the best is good enough.” This guiding principle has driven Lego’s success for over 80 years, making it a global leader. However, in the case of Lego Universe, this principle was misapplied. The pursuit of perfection delayed crucial feedback, leading to inaccurate assumptions about user preferences. The result was the opposite of Minecraft’s success.
Interestingly, the Lego Universe teams used Scrum and iterated extensively – similar to the Minecraft developers. However, their releases were internal only. “Bikes,” “scooters,” and perhaps even “motorcycles” were likely built, but these prototypes never reached real users. This deviates from the intended use of Scrum.
Lego Universe was an expensive failure, but Lego learned from it and continues to improve its early testing and user feedback processes.
Moving Beyond “MVP”: From Testable to Lovable Vehicles
This brings us to the concept of MVP – Minimum Viable Product.
The core idea is excellent, but the term itself often causes confusion and anxiety. Many customers react negatively to “MVP,” fearing it means receiving a minimal, inadequate product. Too often, teams deliver a so-called MVP and then move on, leaving customers with a buggy, incomplete product. For some, MVP = MRC (Minimum Releasable Crap).
While this is often due to poor management, the term “MVP” itself contributes to misinterpretations. “Minimum” and “Viable” are subjective and lead to different expectations.
Here’s an alternative approach, focusing on clarity and user value.
First, replace “Minimum” with “Earliest.” The purpose of an MVP is to get feedback early. By delivering an earliest product, rather than a minimum one, we achieve this goal sooner.
Few customers desire “minimum,” but most value “early”! So, the first change:
Minimum => Earliest
Next, remove “Viable” as it’s too ambiguous. Your “viable” might be my “unusable.” “Viable” can mean “testable for feedback” or “actually usable by customers.” Let’s be more specific and break it down into three distinct stages, progressing from simpler vehicles to more complete ones:
Earliest Testable Product (ETP), like a skateboard or bus ticket, is the first release that allows customers to interact with something tangible. It might not fully solve their problem, but it generates initial feedback. The primary goal is learning, and any user value is a bonus. Think of it as a basic “bike” frame.
Earliest Usable Product (EUP), perhaps a bicycle, is the first release that early adopters will willingly use. It’s not complete or polished, and might not be delightful, but it offers tangible value and improves the customer’s situation. This is a functional “bike”.
Earliest Lovable Product (ELP), potentially a motorcycle, is 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 still evolve to a convertible or even something entirely different. But we’ve reached a point with a truly marketable product. This is a desirable “bike” or perhaps a basic “car”.
I considered adding an even earlier stage, “Earliest Feedbackable Product,” representing paper prototypes or similar methods for initial feedback. But four stages seem excessive, and “Feedbackable” is awkward. However, this initial feedback stage is crucial. Some might consider a paper prototype as the Earliest Testable Product, depending on the definition of “Testable.” For more concrete examples of early feedback methods, see Martin’s MVP Guide.
While “Earliest Testable/Usable/Lovable” can still be misinterpreted, it’s a more explicit and user-centric approach than the vague “Minimum Viable Product.”
Key Takeaways: Ride Towards Success
In conclusion, and if you’ve made it this far, thank you! Here are the essential takeaways:
- Avoid Big Bang delivery for complex, innovative product development. Embrace iterative and incremental approaches. This isn’t new, but are you truly practicing it?
- Start by identifying your “bike” – the Earliest Testable Product. Aim high, but begin humbly with a functional “bike” to get rolling.
- Consider moving beyond “MVP.” Use clearer terms that resonate with stakeholders. Earliest Testable/Usable/Lovable is one option; choose terminology that minimizes confusion.
And remember, the “bike car” illustration is a metaphor. Don’t take it too literally!
PS – Here’s a fun story about how my kids 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.
