There’s a lot of talk these days in Software as a Service (SaaS) about renaming MVP. It’s a mistake.
The problem isn’t with the label.
It's with the definition of what a Minimum Viable Product actually is.
The Problem
The current straw man (no, it’s not intentional - but that doesn’t change what it is):
Nobody wants to use an unfinished product.
It’s exploitative to take customer money in order to learn.
MVPs are often abandoned and users are left holding the proverbial bag.
MVPs are terrible.
We need to stop using the term MVP and replace it with something else. Maybe, SLP (super loveable product) or something.
If that’s what you’re doing and calling it an MVP, I kind of agree that you should probably stop.
But that’s the problem.
What people are describing as an MVP is not *actually* an MVP. It’s a cousin to labeling an undisciplined development process as “agile” (that’s a different topic for a different day).
To understand why this is not an MVP, we have to understand where the concept of an MVP originated.
Steve Blank and the foundations of the modern Software MVP
In 2006, Steve Blank wrote The Four Steps to the Epiphany. The book is a summation of his previous 25 years as a technology entrepreneur and professor. It’s a self-published work in which he shares his Stanford University entrepreneurship course materials with the rest of us. The most foundational concept in the book is “Customer Development”.
It’s this concept that fundamentally differentiates an *actual* MVP from what people are currently calling an MVP.
You should really read the book but, here’s the point.
No MVP starts with software.
It starts with getting outside the building and talking to *potential* customers. Here's a quote from page 30 of Steve's book:
…the goal of Customer Development in a startup is to find a market for the product as spec’d, not to develop or refine a spec based on a market that is unknown.
There’s an entire page devoted to the process of creating, testing, and validating (or invalidating) various hypotheses.
Customer Development in marketing leads to Customer Validation in sales.
There’s no shortcut to understanding who the customer is and why they would buy our solution BEFORE we build a product.
An MVP that’s an experiment simply isn’t an MVP. That’s not a naming problem, it’s a leadership problem.
That doesn’t mean we don’t have the ability to experiment, it just means that if the first release is designed to get feedback or validate customers, we’re going to burn a whole lot of capital (human and financial) for learning that we could have gained a different way.
Since the CEO's primary job is to properly allocate capital, burning it in the wrong place is a miss.
Eric Ries - The builder of the modern software MVP principles
Eric Ries was one of Steve Blank’s proteges. He went on to amplify Steve Blank’s concepts in The Lean Startup. This is the book that launched the entire concept of an MVP. Here's an insightful statement from page 20:
The goal of a startup is to figure out the right thing to build–the thing customers want and will pay for–as quickly as possible.
It’s a LEAN process.
The goal isn’t to spec the entire ecosystem of product driven value BEFORE building something. The goal is to balance planning and building. It’s an Agile Manifesto type of moment.
while there is value in the items on the right, we value the items on the left more.
In light of Blank’s Customer Development and Validation models, Ries doesn’t throw out planning, he just asks his team to ask these 4 basic questions (p.64) BEFORE they start:
Do consumers recognize that they have the problem you are trying to solve?
If there was a solution, would they buy it?
Would they buy it from us?
Can we build a solution for that problem?
The common tendency of product development is to skip straight to the fourth question and build a solution before confirming that customers have the problem.
I have seen it over and over again.
Product teams and senior leaders answer yes to all four of the questions without validating their hypothesis.
They believe what they believe. Why WOULDN'T they buy it from us if we build it?
They do it because they need to go fast. First mover advantage, right?
Well, maybe. But there’s an adage about pioneers and settlers - pioneers (more often than not) meet an ignominious end…
How to build an actual software MVP
So what’s the solution?
Answer: Customer development and validation BEFORE product development.
There’s a fantastic customer development story about a software engineer who needs to deposit a check at the bank.
The problem is that there’s a huge line wrapped around the building. Progressively, the engineer asks each new “role” he meets to explain the problem. None of them know until he gets to the bank president. There, he finds this person has already spent money on solutions but none of them are working.
It turns out that the engineer knows how to solve the problem for the bank president. He hasn’t built the solution yet but, when he describes it, the bank president is ready to buy.
The amazing thing here is that there is alignment between the product the engineer wants to build and the product the bank president wants to buy. There’s no “can you build it like this and then I’ll buy”.
Product market fit, right?
Wrong.
Our proverbial engineer is faced with a choice. If the bank is a big enough customer so that the amount they pay allows the engineer’s business case to work, it might be a great fit. That’s a custom solution for a single customer.
It’s not an MVP.
Our engineer now travels from bank president to bank president and presents *the solution he wants to build*. If a bank president says “yes, I want to buy the solution you have designed”, they’re a validated customer prospect.
If they say “I like it, can you build it THIS way instead?”, our engineer says “no” - and keeps track of the feedback. This bank president is *not* a validated customer prospect.
This is the key:
The engineer has the seed of an MVP once he has identified enough prospective, validated customers to make the business case work based on the product he wants to build.
Product market fit is when there's a large number of early adopters (the market) who want the thing (the product) you intend to build in the way you intend to build it (the design). More on this in a minute...
Experimentation is in the *how* the engineer builds it - not in the *what* he builds.
The MVP meets the customer needs and they are willing to pay money for it. As long as this set of customers has this need, and the software meets it, there will continue to be a market for the product.
It's true that the product team needs to continue innovative work. As Ries points out elsewhere in the book, a stagnant product will eventually die.
If the company botches the implementation, the market demand is still there. A challenger will solve the same problem in a different way.
This is an actual MVP.
And, there’s no need to change what we call it.
Assuming we’ve done the work required.
A word about pivots and software MVPs
What about pivots?
A pivot is a fantastic thing.
Eric Reis’s book has an entire chapter dedicated to it. I’m willing to bet that few people who talk about pivots have actually read the authoritative source. Here’s what Eric wrote on page 154:
A pivot requires that we keep one foot rooted in what we’ve learned so far, while making fundamental change in strategy in order to seek even greater validated learning.
That’s embedded in a story about an early stage company that made a series of different pivots.
Initially, that company made what Ries called a “zoom in” pivot.
They didn’t toss the MVP and leave all the paying customers out in the cold. They saw that the adoption numbers weren’t what they thought they would be. Based on that learning, they figured out a place to focus even more tightly. Guess what?
The numbers improved and people started getting more value out of the solution.
It wasn't enough though. They had to make a series of other pivots - some of them were major changes.
The company didn't abandon the users, leaving them with useless software (remember that from the strawman arguments?)
Who is a software MVP built for?
Earlier, we were discussing product market fit.
Ries summarizes Marc Andreessen's definition with this lead in:
Marc Andreessen...coined the term product/market fit to describe the moment when a startup finally finds a widespread set of customers that resonate with its product...
It's crucial to recognize something about the market here.
The market for an MVP is *not* the early or late majority.
Customers want different things at different stages. This is a central point to understand about the technology adoption curve Geoffrey Moore describes in Crossing The Chasm.
Innovators (less than 3% of people) and early adopters (another 10-15%) buy things that they expect will change.
Guess where MVPs live?
MVPs are built for the earliest adopters in the technology curve.
Can you guess where product market fit lives? Here's a hint if it's not obvious - it's not to the left of the chasm Moore's work showed us.
These are the people who are "taking a flyer".
They're the people deeply motivated by being first - even if a thing doesn't work out. It's ok!
They get the:
status of being first and part of the "inner circle",
joy of trying new things, and
opportunity to help and shape something
They're buying a feeling and contribution as much as they are paying for a service.
This calls for extreme amounts of empathy. If you're not a person who signs up for the alpha version of something new, it's going to be *really* difficult to understand why anyone else would. But they do - and, they're 100% right to do it. Even if it means "they're just throwing their money away".
Simply put? Pivots during an after MVP are not unkind.
They're not a bait-and-switch when done with transparency and a clear headed set of hypotheses from the people building them.
They're expected and an incredibly healthy part of the process. They are the engine that carries a startup to product market fit - that magical place where the marketing and sales starts to flip from push to pull.
Next steps
So, what’s to be done here?
Let’s be honest about what we’re doing (with ourselves, and with our early customers of an MVP).
Let's be clear about who it is for, and when.
Let's be informed about the time it will likely take a particular team's value proposition to make the transition from idea to market adoption.
Let’s invest in understanding our terms and the actual efforts that result from doing things a particular way.
It’s a LOT of work to undertake customer development, customer validation, and product development. It’s entirely possible to do this meaningful work in a lean and agile way.
If we are looking to improve the success rate of net income positive startups (vs. unicorn path startups that rely on investment vs. cashflow), perhaps we should return to the first principles of customer development, lean software development, and agile as a mindset.
Let’s do the work instead of just changing the label.
Paravelle offers executive coaching services to founders and CEOs with big growth goals. It's a crucial support structure that helps leaders avoid the negative results that come from being lonely at the top.
We might be a good fit to work together if you're:
at the create (<1M ARR), build ($1-3M ARR), or grow ($3-5M ARR) stage,
curious and looking for ideas and answers, and
ready to invest in working with a collaborator that brings a co-founder's perspective (without losing half your equity).
Let's chat!
