As pointed out by Eric Ries, a minimum viable product is that version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort through a cycle of build, measure, learn; that is the foundation of the lean startup methodology.
- The origin story of the lean startup movement
- The birth of the Customer Development Manifesto
- A glance at the lean startup methodology
- What is not an MVP?
- Demo > Sell > Build: Tweaking the classic lean startup loop
- Validating the market with a bottom-up approach to flip upside-down the product-market fit problem
- The leaner MVP approach is about finding whether the “commercial time window” is right
- When does an MVP become too risky?
- Enter the Exceptional Viable Product Methodology
- Connecting the dots between MVP, Leaner MVP, and EVP
- Microniches and Minimum Viable Audiences
- FourWeekMBA Business Toolbox
- What is minimum viable product in Agile?
- What makes a good MVP?
- What is an EVP?
The origin story of the lean startup movement
However, the origin story started in the late 1990s.
Steve Blank, a retired serial entrepreneur had the time to think through what he had missed in terms of business frameworks, during the years, as he started several high-tech companies.
He had noticed that the only tool available at the time was the business plan.
However, not only the business plan was a static document that didn’t survive the first contact with the real world.
That document also has plenty of untestable and untested assumptions.
The patterns he noticed would be all gathered into what became a manifesto and the foundation for the lean startup movement.
This manifesto would be called Customer Development Manifesto, which moved along 17 principles.
It started with a definition of a startup that moves along those lines:
A Startup Is a Temporary Organization Designed to Search for A Repeatable and Scalable Business Model
The interesting part of this definition is – I argue – the “search for” part.
The iteration process to find a business model is as challenging as the iteration process of humans searching for meaning.
The birth of the Customer Development Manifesto
The Customer Development Manifesto moved around 17 principles:
- There Are No Facts Inside Your Building, So Get Outside
- Pair Customer Development with Agile Development
- Failure is an Integral Part of the Search for the Business Model
- If You’re Afraid to Fail You’re Destined to Do So
- Iterations and Pivots are Driven by Insight
- Validate Your Hypotheses with Experiments
- Success Begins with Buy-In from Investors and Co-Founders
- No Business Plan Survives First Contact with Customers
- Not All Startups Are Alike
- Startup Metrics are Different from Existing Companies
- Agree on Market Type – It Changes Everything
- Fast, Fearless Decision-Making, Cycle Time, Speed and Tempo
- If it’s not About Passion, You’re Dead the Day You Opened your Doors
- Startup Titles and Functions Are Very Different from a Company’s
- Preserve Cash While Searching. After It’s Found, Spend
- Communicate and Share Learning
- Startups Demand Comfort with Chaos and Uncertainty
And the introduction of new tools and frameworks to use as an entrepreneur (Business Model Canvas and all its variations)
A glance at the lean startup methodology
The lean startup methodology aims at creating a scientific, repeatable process for product development that allows the startup to build products and deliver them fast.
In other words, the lean startup moves around three stages:
This process of build > measure > learn will need to be repeated over and over, thus creating a feedback loop.
The primary purpose is to initially come up with a minimum viable product (MVP), which is a critical aspect of the lean startup model.
A Minimum Viable Product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
The MVP will be the foundation to build a successful company.
What is not an MVP?
As Ash Maurya pointed out, the definition of MVP got overtime simplified with “the smallest thing you can build that lets you quickly make it around the build/measure/learn loop.”
This kind of simplification brings flaws and mistakes that can also lead to significant failures.
Demo > Sell > Build: Tweaking the classic lean startup loop
When I spoke to Ash Maurya, author of Running Lean and Scaling Lean, we discussed how building a solution before validating it might be the basis of one of the most dangerous biases for entrepreneurs: the innovator’s bias.
As he pointed out, “one of the biases that that that many entrepreneurs fall run into is this premature love of the solution. Like the first principles in science, you almost have to deconstruct an idea. We have to start with the basics. In this case, when we look at our business, we have to break it down into customers and problems.”
And he continued, “If you don’t have the right customers who are trying to get sorted and problem solved, and no matter what solution you build, it doesn’t matter because we know that unless you’re solving a problem, customers are not going to use it.
They’re not going to pay money. Even if you can reach them. Even if you have a patent or an unfair advantage, it doesn’t matter at the end of the day because your customers don’t care. So that is the way we logically break it down, but that innovator’s bias is one of those sneaky things.”
Ash Maurya proposed a slightly different approach:
We might start with the demo. We might first go and find customers, see if we can reach them, even talk to them. Because if you can talk to customers, we can sell them anything. We start with the end in mind and then we deconstruct our way back to the beginning and start validating at a bottom-up level. That generally is how we overcome the innovator’s bias toward a solution.
As Ash Maurya pointed out, “build a demo first, sell that demo, and if you can sell the demo, then don’t even build the product.”
This process helps to validate the market clearly, thus eliminating most of the risks associated with a company’s failure (people do not need or want that product).
This MVP approach flips upside-down the product-market fit problem. Where in a product-market fit scenario, we build a product first, and we iterated times and times again to find this magic moment, called “market fit.”
In this leaner MVP approach, we validate the market first, then build a product.
Of course, that doesn’t mean success is guaranteed. We just moved the market risk away, and now the whole pressure is on the feasibility of the product we demoed.
A great example of this approach is how Tesla pre-sells its cars, by demoing them first, before going in large-scale production:
While the demoed product already has all the aesthetic and most of the features the final product might have.
For a car company, one thing is to build a single car; another is to produce it at scale.
On a much smaller scale, a demo might be a simple landing page with a mock-up of the product you want to build.
Once again, this process will help us validate the market first.
From there, it will be more of a problem of feasibility.
Of course, the more a product is technically challenging the more the feasibility risk will be high, later on.
However, that also means we saved massive financial resources.
As to producing that product and making it go to market, we would have spent time, money, and other people’s capital and yet build something people do not want.
The leaner MVP approach is about finding whether the “commercial time window” is right
We might argue that the whole concept of leaner MVP is entirely new.
However, companies innovated in their fields have used this approach (or at least the innovative units within those companies).
When I interviewed Alberto Savoia (he was among the engineering team of Google in the early years and before its IPO), he explained how back in the 1980s, IBM thought, “we want everyone to have personal computers.”
IBM thought there was no way that most people would use computers as they would not be predisposed to learn how to use a keyboard (an assumption proved wrong).
How to test this assumption?
IBM thought to tackle the market with a speech-to-text technology that enabled people to talk to computers and get that translated into text.
They figured a mechanism to convert speech into text would make a computer a potential mass-market product.
In short, people would dictate to computers instead of typing on a keyboard.
Yet, instead of focusing on building the product first (it would have taken years and many billion dollars), IBM devised an intelligent experiment.
The IBM team brought people into a room, they gave them a microphone, and there was a screen in front of that microphone and told them, “Look, this a new way of running a computer, there’s no keyboard, you just speak to it, and give it a shot and tell us what you think.”
Therefore, people talk, and the computer translates that into text.
However, it wasn’t the final product, not even close. In the room next door, a human being got the input through the headphone and typed it on a keyboard.
The effect was that the users in the experiment thought the IBM speech-to-text was a working prototype, but it wasn’t.
With this simple experiment, IBM collected valuable data that told them a few things they were completely wrong about.
First, people would not talk to computers for long, as they got a sore throat.
Also, in an office environment, everyone talking loudly will not be viable (especially if you need to input into the computer confidential information).
Those data points alone made IBM stop prioritizing the speech-to-text experiment.
And this would save them years of R&D, lost focus, and financial resources.
A third assumption would be proved wrong after a few years.
Indeed, keyboards would eventually become mass-adopted and efficient to use computers at scale! (and it still is today).
Voice-enabled devices are going into mass-production only now (Alexa, Google Home, Cortana, Siri).
However, this is a much different technological environment compared to the 1980s.
Thus, if at all, this leaner MVP approach can tell us an extremely valuable piece of information on whether the commercial use case timing is right! (that for sure represents a good chunk of the product’s success in the first place).
It’s important to clarify that this approach will not tell us whether a product or technology will ever be successful in the future.
Neither whether this technology will be successful with another commercial use case.
In short, IBM thought the speech-to-text would be an alternative to the keyboard, and this assumption was wrong for the time being.
Would that be proved right if they thought of another commercial use case? Maybe.
But for what they needed back then (make PCs scale and become a mass product), text-to-speech wasn’t the right project to prioritize.
When does an MVP become too risky?
If you are just starting up, you don’t have an established brand, and your reach is limited, the MVP might be the way to go.
That’s because the risk of failure and the cost of branding are very, very limited.
That is where the Exceptional Viable Product definition given by Rand Fishkin (founder of Moz and SparkToro) comes in handy.
I believe it’s often the right choice to bias to the EVP, the “exceptional viable product,” for your initial, public release.
Fishkin suggests creating an MVP but not releasing it until that is exceptional. At that point, you do release it to the public.
Thus, the exceptional viable product (EVP) methodology requires an iteration of the product “in-house,” tested with your team and maybe a few selected customers.
Companies like Apple have been following this approach all along. Apple has been building its hardware products by testing them internally as much as possible.
There are two main reasons to opt for this approach:
- Brand risk: if you have an established brand, a new product released to your audience is way too risky. As this might compromise the whole brand equity gained over the years.
- Competitive risk: when you release a product to the market, even to a smaller subset, you’re enabling competitors to gain access to the new product you’re launching, thus giving away valuable information that will give them a competitive edge, to quickly improve on what you’re doing.
As Fishkin suggests, only when you’re sure the product is exceptional can you launch to a broader audience.
The EVP methodology allows more established brands to avoid failures that can lead to an irrecoverable loss of reputation.
Enter the Exceptional Viable Product Methodology
My proposal is that we embrace the reality that MVPs are ideal for some circumstances but harmful in others, and that organizations of all sizes should consider their market, their competition, and their reach before deciding what is “viable” to launch. I believe it’s often the right choice to bias to the EVP, the “exceptional viable product,” for your initial, public release.
Rand Fishkin also added:
Depending on your brand’s size and reach, and on the customers and potential customers you’ll influence with a launch, I’d urge you to consider whether a private launch of that MVP, with lots of testing, learning, and iteration to a smaller audience that knows they’re beta testing, could be the best path.
In other words, he takes into account two main variables. On the one hand, you have the attention, customers, and evangelism.
On the other hand, you have the product quality.
The greater the attention, customer base, and ability to evangelize, the more you’ll need to have a solid product before its launch.
In Rand Fishkin’s vision, an EVP has to have two minimum features:
- Have decent exposure.
- And be truly impressive, at least at one must-have – identified – feature customers are looking for.
He learned that lesson at Moz when trying to build a new tool to identify spammy links. As Rand Fishkin recounted:
Our research had already revealed what customers wanted. They wanted a web index that included all the sites Google crawled and indexed, so it would be comprehensive enough to spot all the potential risky links. They wanted a score that would definitively say whether a site had been penalized by Google. And they wanted an easy way of knowing which of those spammy sites linked to them (or any other site on the web) so they could easily take that list and either avoid links from it or export and upload it to Google Search Console through a disavow file to prevent Google from penalizing them.
That would be anexceptionalproduct.
But we didn’t have the focus or the bandwidth to build the exceptional product, so we launched an MVP, hoping to learn and iterate. We figured that something to help our customers and community was better than nothing.
I think that’s my biggest lesson from the many times I’ve launched MVPs over my career. Sometimes, something is better than nothing. Surprisingly often, it’s not.
Connecting the dots between MVP, Leaner MVP, and EVP
A core part of the lean startup methodology is the MVP.
As we’ve seen throughout the article, an MVP is the classic mode of experimentation for startups.
It has been a very powerful shift as it enabled companies to gain customers’ feedback early in the product development cycle.
Yet, as we move toward the leaner MVP approach has taught us that we can use an even more bottom-up approach by demoing the product even before we’ve built it to see if people want it.
This approach moves from build > measure > learn to demo > sell > build.
The leaner MVP approach will work well to remove market risk away while putting more pressure on the feasibility risk.
And yet, it will help us save valuable time and resources.
Both an MVP and leaner MVP approach become risky when it comes to an established brand with a wide audience and reach, where a new product release, also if circumscribed to a small audience, can spread quickly.
In that case, an EVP approach will help, as it will focus on iterating the new product with specific units within the company and with only a few selected customers.
Microniches and Minimum Viable Audiences
Another couple pieces of the puzzle to be added to build a valuable product from scratch are microniche and minimum viable audience.
In other words, on a very crowded web with an app for anything, the best way to create options to scale is by targeting a microniche.
A microniche is such a small sub-segment of a market, which, though, can be extremely valuable as you can gain:
- Honest feedback: as a small audience (sometimes comprising also a few dozen of people), they will be so motivated to deal with someone who takes the time to talk to them (compared to existing prominent players that, due to scale, have mostly automated interactions with their customer base) that you’ll get a lot of honest feedback. Having this kind of feedback is extremely valuable.
- Clear value proposition: those small audiences will know what they want, and they will help you in crafting a unique value proposition.
- Faster iteration loops: that will make it possible for you to build faster loops of iterations to quickly improve the product.
From the above, you can identify your minimum viable audience.
As in those microniches, you’ll discover truths that have the potential (over time) to also help you develop a whole new market!
That’s what makes the Blue Sea Strategy so counterintuitive.
By narrowing down (substantially) the market today, you create options to scale tomorrow!
Today’s microniche might be tomorrow’s huge industry, potentially eating up existing/major industries!
FourWeekMBA Business Toolbox
Other business resources:
- Types of Business Models You Need to Know
- The Complete Guide To Business Development
- Business Strategy: Definition, Examples, And Case Studies
- What Is a Business Model Canvas? Business Model Canvas Explained
- Blitzscaling Business Model Innovation Canvas In A Nutshell
- What Is a Value Proposition? Value Proposition Canvas Explained
- What Is a Lean Startup Canvas? Lean Startup Canvas Explained
- What Is Market Segmentation? the Ultimate Guide to Market Segmentation
- Marketing Strategy: Definition, Types, And Examples
- Marketing vs. Sales: How to Use Sales Processes to Grow Your Business
- How To Write A Mission Statement
- Growth Hacking Canvas: A Glance At The Tools To Generate Growth Ideas
Handpicked business models:
- How Does PayPal Make Money? The PayPal Mafia Business Model Explained
- How Does WhatsApp Make Money? WhatsApp Business Model Explained
- How Does Google Make Money? It’s Not Just Advertising!
- How Does Facebook Make Money? Facebook Hidden Revenue Business Model Explained
- Marketing vs. Sales: How to Use Sales Processes to Grow Your Business
- The Google of China: Baidu Business Model In A Nutshell
- Accenture Business Model In A Nutshell
- Salesforce: The Multi-Billion Dollar Subscription-Based CRM
- How Does Twitter Make Money? Twitter Business Model In A Nutshell
- How Does DuckDuckGo Make Money? DuckDuckGo Business Model Explained
- How Amazon Makes Money: Amazon Business Model in a Nutshell
- How Does Netflix Make Money? Netflix Business Model Explained
What is minimum viable product in Agile?
As pointed out by Eric Ries, a minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort through a cycle of build, measure, learn; that is the foundation of the lean startup methodology.
What makes a good MVP?
A great MVP is something that delivers enough value to potential customers, thus ready to be launched and as result gather feedbacks from those potential customers to improve it fast.
What is an EVP?
As Rand Fishkin pointed out: “MVPs are ideal for some circumstances but harmful in others, and that organizations of all sizes should consider their market, their competition, and their reach before deciding what is “viable” to launch.” Thus EVP, or “exceptional viable product,” might be the most suited choice for an initial, public release.