How To Build a Minimum Viable Product That’s Immediately Valuable
The difference between success and failure with a Minimum Viable Product almost always comes down to deciding what gets built when.
In 20+ years of building all kinds of products, I’ve come to the conclusion that while there is no perfect plan for success, the most damning mistake startups make with their MVP is building it from the ground up. That kind of unstructured product development leads to disaster every time.
Fortunately, avoiding disaster is pretty simple.
Step 1: Define the value proposition and stick to it
For an MVP to be valuable to both your customers and your company, it has to accomplish three things:
- Your MVP must test the core functionality of your product.
- Your MVP must test the full delivery system for your product.
- Your MVP must prove the market viability of the idea on which your startup is founded.
Again, there is no guarantee that your MVP will be successful, but to even begin to determine whether or not you have a success on your hands, your MVP has to test those three hypotheses. Any feature that doesn’t do that can wait.
Step 2: Avoid sabotaging your MVP
Look, some MVPs are just bad ideas coerced into reality. I can’t help you with that, but what I can walk you through is how to avoid sabotaging a good idea with an unstructured MVP development process. These are the most common mistakes that perpetrate that sabotage:
- The MVP isn’t actually an MVP. Instead, it’s somewhere on a scale from really overproduced demo to really shitty version of the final product.
- The core functionality of the MVP doesn’t work or works so poorly that its viability can’t be accurately assessed.
- The discovery, delivery, and support processes fail the MVP, creating so much noise from bad customer experience around the handling of the MVP that all the data about the product itself becomes moot.
- The MVP is successful, but customers fall in love with an overpromised and ultimately under-delivered version of the final product.
- The MVP is successful, but the results wind up being a lot of false positives around functionality that won’t scale and grow into something valuable.
Step 3: Don’t build your MVP from the ground up, build from the sky down
This is how the birth of a new product almost always works: You have the idea, you find the talent, you draw up the roadmap. So now what do you build first?
Never start with a blank slate and go directly to MVP. It’s a classic path to overbuilding and this is what that looks like:
- You’ll launch your MVP, get a lot of customers, and push a lot of product, usually for free. Even though this leads to a successful MVP, you’ll wind up with a bunch of “customers” who all have a bunch of different expectations. When this happens, panic usually sets in, which will lead you to assume your next step and likely guess wrong. Suddenly, the lifetime value of all those customers drops to zero. Ever see a startup blast out of the gate and fail a couple months later? This is almost always why.
- You’ll launch the wrong thing first and never get traction, because none of your potential customers will understand the full value of the realized product. For example, if Amazon had started life with their third-party marketplace, without the infrastructure they had first established with shipping books and CDs and eventually with Amazon Prime, that company just becomes an eBay clone. No one wants to be an eBay clone.
- You won’t launch at all. The team will spin forever debating a dozen MVPs or a dozen different takes on a single MVP. All of these options might require a slightly different strategy, maybe even different positioning. As you finally settle on one option, all the other options start to make more sense, and you keep going back to the drawing board.
So instead of starting with a blank page, you need to write the MVP story from the ending backwards.
Any good author will tell you that they write the end of the book first, and then they’ll work backwards to the beginning. I talk about Three Stories a lot. Story A is what you’re doing today, Story B is what you’re trying to grow into, and Story C is the home-run billion-dollar company.
Write Story C first and work backwards to Story A. That’s your MVP.
Now, you’re going to get some of the future details wrong, but it’s much easier to go back and rewrite Story B and Story C using what you’re learning from Story A. On the other hand, it’s almost impossible to start out by writing Story A and then hoping and praying that your Story A results in a compelling Story B and Story C.
Step 4: Build your MVP around the core
Another MVP approach I talk about often is building around the core functionality of the product, making those specific features robust and prime-time-ready, then cutting corners everywhere else.
So what’s core? It’s those features that show value immediately. The core has to get the customer to a quick understanding of why they need your product. And it has to do this flawlessly.
I’m going to give an example of a software-based consumer product I was asked to give advice on recently. The product is a live MVP, not all there, but accessible to the public.
Now, it’s an MVP, so there were a lot of things that were forgivably missing. There were pieces where I was thinking — “oh, it’s missing this, that would have been nice to have.” Or “oh, this is the way I normally do things and the product wants me to do this a little different. Kind of a little bit of friction there, but OK.” That was all fine. These weren’t core pieces.
The product was very polished in places too, where I was thinking, “oh, this is really easy to use,” and even some features I would call clever, like “that must have taken a lot of thinking and work to accomplish.”
But in the end, the MVP didn’t work. Because it didn’t show any value.
The MVP let me do a lot of things, and it let me tweak a lot of its usage to my liking. It may, at some point, solve my problem, but not this version. It’s a situation where once I put it down, I might never pick it up again.
This is false positive, and a lot of MVPs generate false positives. They get the customer interested, the customer tries the MVP, but the customer never comes back, and the lifetime value crashes to zero or less than zero. Even though there are a lot of customers, it results in a lot of loss.
This happened to me at one of my old startups. We built a new product that was super-cool, way more consumer-oriented than our original product, literally did magic on the screen, but didn’t solve the problem that the old product solved.
It was science for science’s sake. And it crashed, spectacularly. A lot of people were interested, a ton of people tried it, but then everything from onboarding to support was a nightmare. When people did finally apply our solution to their problem, they started asking for all sorts of features that the new product didn’t do and the old product did. We had opened a pandora’s box of low value.
Always think about value
Let’s bring it back to a really simple use case. When I write a post, I’m not just thinking about the moment, I’m thinking about value.
- Am I providing value to you, as a reader, and not just showing off my experience?
- Am I providing value to every other reader like you, generating insights that apply universally?
- Am I setting you up so that you’ll want to read the next thing I write?
Applying those types of questions to your product will help you find the core of your MVP — immediate value. When your customers are done using your MVP, you need them to want to use it again, exactly as it is. That’s the core. Everything else — and all the features you have planned for later — should only serve to enhance that value, not create it.
Hey! If you found this post actionable or insightful, please consider signing up for my newsletter at joeprocopio.com so you don’t miss any new posts. It’s short and to the point.