Why Every Startup Needs an MVP
SaaS startups need an MVP, and after reading this post, you’ll understand why. When we think about software products, our minds typically turn to the products we love and use daily. Google Workspace, Slack, Facebook, LinkedIn, and others are excellent examples that make up the backbone of our daily, ever-expanding time online.
It’s tempting, then, to consider these products as aspirational examples when considering developing our own products. The image of our “big idea” that we hold in our mind’s eye is often a polished, fully-featured product loved and used by many.
However, what we might forget is that each of these products has its own unique, often cringe-worthy, origin story full of examples of failure, embarrassingly bad early products, and existential crises. In that context, why should we expect anything different from our own product ideas?
The truth is, building software is uniquely difficult given the“squishy” nature of customer needs and undiscovered use cases for our products. If we were to try and build the full-featured, polished version of our products first, we would find the process to be prohibitively expensive and very, very likely to fail.
These facts leave us with a pretty big problem to solve. How can we get started with our product idea in a way that doesn’t break the bank and that allows for fast learning and iteration?
Enter the minimum viable product or MVP.
What is an MVP?
When I talk with founders about their MVP, I like to use a simple, easy-to-understand description coined by Ash Maurya:
“A Minimum Viable Product is the smallest thing you can build that delivers customer value (and as a bonus captures some of that value back).”
Ash Maurya
Much has been written about the MVP since it was first introduced by Eric Reis in his seminal book, The Lean Startup. Opinions about what is and is not an MVP (and even whether or not the MVP is dead…more on that later) abound and, to some extent, they’re all usually at least partially correct.
But there’s one thing I want to drive home that absolutely has to be true for all MVPs: An MVP is a learning tool, not a revenue driver.
You will not make your first million with your MVP, nor should you. Instead, your MVP should help you learn what you’re getting right, what you’re getting wrong, and what your customers really want or need so that you can continue to iterate your way toward a successful product.
Now that we have that out of the way, let’s return to Ash Maurya’s definition and break it down a bit.
The smallest thing you can build
Scope creep, or the tendency of the scope of a project to grow unchecked over time is one of the most dangerous risks for early products. Even in the era of low and no-code products, the software is still pretty expensive to build.
Founders, especially first-time founders, often have lofty expectations of what their product “must” have and what it can do without. In almost all of those cases, these assumptions are wrong and, in the worst-case scenarios, deadly for the product and the company.
For that reason, MVPs should be small by design. When I say small, I mean really small. The only requirement is that the MVP should be robust enough to deliver on a single value proposition.
Speaking of value propositions…
That delivers customer value
Theoretically, you could build an MVP that only consists of a sign-up flow. It would be small and it would be feature complete for that discrete part of the product.
But would it deliver any value? No, it likely would not.
It is essential that your MVP delivers customer value. Without that, you can’t learn anything from your customer. Remember, our MVP should help us understand if our customer is able to understand and derive value from our product. And to make small changes over time that gets us closer and closer to nailing that value delivery.
Our MVP, then, should be designed to deliver value. However, most product visions encompass several value propositions to be created. So how do we decide which one to focus on first?
This is where your discovery, market research, and positioning experiments come in. You should be engaging in all of these efforts as well as prototyping before you begin to build your MVP. That way, you have a highly-educated guess as to which value proposition resonates strongest with your prospective customers. And this is what you should focus on with your MVP.
To recap, when it comes to MVPs, keep them small and deliver on a single value proposition to start with.
And as a bonus, captures some of that value back
This is my favorite part of this definition of an MVP. In my professional opinion, what distinguishes the learning obtained from an MVP versus a prototype is the exchange of value. While Maurya adds the value capture element as a bonus in his definition, I would argue that it is the element of an MVP that allows it to deliver the highest quality learning.
An MVP, at its core, is a learning tool. The learning we’re primarily concerned with is whether or not our product delivers enough value that a customer is willing to part with something of value in order to obtain our product. In most cases, that something of value is cash, but it can be other things, too.
Email addresses (attention), referrals (reputation), and sharing (social proof) are all acceptable representations of value in the early days of testing an MVP. However, as they say, cash is king. This is why I recommend that all builders of MVPs consider how they can monetize them in a simple, low-friction way.
Before we go further, I want to reiterate and reinforce one thing. Your MVP is not a revenue driver.
A customer paying for your MVP is a data point that contributes to your learning and the evolution of your product. For that reason, you should price your MVP well below market value. You should price your MVP in a way that makes it a “no-brainer” for any prospective user.
The act of paying for a product, even a single dollar, is an incredible data point for any product. Think about it, to pay for a product a user must:
- Be willing to create an account
- Be willing to enter a credit card or other form of payment
These data points are what we’re after when it comes to charging for our MVP. The amount that we charge is secondary to this learning.
How to Build an MVP
Hopefully, I’ve convinced you of the necessity of building an MVP for your product’s initial version. Now you’re probably wondering how to go about building one. I have good news for you. You have several surprisingly simple and affordable options to build your MVP.
However, I want to start with the most common way to build an MVP, writing code to build a functional software product.
Functional Software
Building software is expensive, period. No matter what you do, you will be spending a lot of money or a lot of time (probably both) building your MVP.
This is problematic because there are two things that are critical to startup success: momentum and capital efficiency. Spending a lot of time and money on an MVP works directly against both of these goals.
The good news is that you can build a functional MVP with software quickly and (relatively) cheaply if you’re willing to make some tradeoffs and be scrappy. I mentioned low and no-code tools earlier in this post and I want to revisit them here.
In the increasingly platform-dependent world, we live in, there’s no point in building many of the core features of new applications from scratch. Someone has likely already built the feature you’re considering and is willing to let you use their product (for a fee, of course).
Email, SMS, payments, SSO, maps, security…the list goes on and on. All of these features and more have been built and you can integrate these solutions directly into your product without having to bother coding them from scratch.
Furthermore, you can build entire applications using low or no-code tools like Bubble, Adalo, and Retool. These services offer drag-and-drop functionality and deep integrations with many of the features mentioned above to help you create functional software experiences quicker and easier than ever.
If you absolutely must have functional software as your MVP, I encourage you to research the low and no-code tools and platforms available to help you build your MVP quickly and cheaply.
The Concierge MVP
Counterintuitively, you do not have to use functional software to deliver your product’s MVP. In many cases, the software is simply trying to replace or automate manual processes. The value proposition, then, is that a previously manual process is now automated saving the user time and money.
Given that value proposition, what we’re wanting to test is whether or not someone will pay to have a given manual process done for them. The simplest way to test this is by…doing the manual process for them!
We call this the Concierge MVP. A great example of the concierge MVP in action is Katrina Lake’s experience building Stitch Fix.
Stitch Fix is a personal shopping service that gathers information from you about your size, preferences, and budget and sends you curated boxes of new clothing on a preset schedule. You can try the clothes on, keep and pay for what you like and return the rest.
When Lake was building Stitch Fix, she went to some of her friends and offered to be their personal shopper. She gathered their information by interviewing and measuring them. Lake did the shopping herself using her personal credit cards to make purchases. She delivered the clothing to her friends, charged them for what they kept, and returned what they didn’t like.
She did all of these things manually before she ever embarked on building the software to automate the process. This was certainly time-consuming and carried a bit of risk using her own credit cards. But it allowed her to validate the value proposition of Stitch Fix quickly and cheaply before investing in a software.
When thinking about your own product, consider if you might be able to deliver the core value proposition manually to test the value proposition before you begin building anything.
The Wizard of Oz MVP
A Wizard of Oz MVP (WOO) takes the Concierge MVP one step closer to a digital solution by creating a digital front end for the customer. But still performing the basic tasks manually behind the scenes (like the man behind the curtain…you get it).
Sticking with our Stitch Fix example, Katrina Lake might have decided to create a simple website with a signup form. After signup, Katrina might have delivered the customer a questionnaire from something like SurveyMonkey or Typeform. This is a good way to collect the information she had previously collected in person.
Lake could then complete the shopping, pack each item, and ship it to her friends. They would still keep what they wanted and return the rest directly to Lake. She could then send each customer an electronic invoice for the items that they decided to keep. And return everything else for a refund to her personal card.
The value delivery here is fundamentally the same, but the user experience has shifted. In this hypothetical example, Lake might have learned that customers don’t prefer invoices after the fact and that they would prefer to be billed automatically. She might have also found that the hassle of packing rejected items back up and returning them created a poor user experience.
While the Concierge MVP provided Lake with validation that the core value proposition was well received, the WOO MVP allowed Lake to learn something important about how her customers experienced the delivery of value via an online interface.
The Piecemeal MVP
A Piecemeal MVP is the final step before we jump into using code to build our product. A Piecemeal MVP digitizes delivery of value wherever possible. This should be the closest thing to a fully-digital experience that we can deliver without writing code. If Lake wanted to apply the Piecemeal MVP treatment to StitchFix, she’d be looking for ways to automate steps in the process. These might include survey delivery and data processing, email communications, billing, and even the shipping and returns process.
To accomplish this, Lake would likely have to look at different off-the-shelf tools. Such as Mailchimp, Quickbooks, Typeform, and even retailer apps and connect them together using a service like Zapier or IFTTT. This is where the name comes from. The piecemeal MVP requires a founder to use different services and tools to deliver as close to a fully-digital experience as possible.
While the Concierge MVP validates the core value proposition of a product and the WOO MVP helps uncover issues and assumptions in the user’s digital experience, a Piecemeal MVP helps a founder explore feasibility. How? By challenging the founder to assemble the tools required for a fully- digital product experience.
When done correctly, a Piecemeal MVP should help founders understand what tools are available. Thus not required to build from scratch as well as where they will need to focus their developer time and money to build or connect other features or services.
MVPs are fantastic tools that allow you to gain durable learning about your customer and their relationship to your product quickly and cheaply. Because MVPs allow you to provide direct contact with the value proposition you’re testing, that learning is very high quality, which translates to super effective product decisions.
There’s one last thing I want you to remember when you’re considering your MVP. Failure is a part of this process. In fact, it’s inevitable. MVPs are designed to de-risk that failure and reframe it as learning. This helps you evolve and iterate your product toward finding Product-Market Fit.
As Elena Verna puts it, growth happens in three phases:
- Learn how to fail
- Learn how to learn
- Learn how to win
Your MVP sets you on the path of learning– how to fail and learning how to learn from those failures. If you bring a mindset of experimentation and eagerness to learn to this process, you’ll be learning how to win before you know it.
If you have any questions, please register for HVL Office Hours. I’d be delighted to meet with you one-on-one and talk further about the above concepts or product development in general.
