Building or re-building your MVP? Focus on one thing; delivering an outcome to the customer

Rob Calvert
Product Coalition
Published in
6 min readJun 11, 2020

--

Photo by Yu Hosoi on Unsplash

Foreword: I’ve written this article for anyone who has used the term ‘MVP’, but is yet to have repeated success with launching them and scaling beyond a first few customers.

The talk around MVPs has got very complicated.

“It should be minimal yet valuable”.

“It shouldn’t scale”.

“Just reduce the non-essential features”.

All of this are true, but they just describe what an MVP looks like. They — and most articles — miss the core reason why an MVP exists in the first place.

And if you miss that core reason, yours is likely to fail. Even worse, you won’t know why.

When a phrase loses meaning

When terms like ‘MVP’ get popularised they get watered-down. The original purpose gets lost, and only a fraction of people who use them know what they really mean.

That doesn’t sound too harmful, but it can be.

For example, how often is Agile about 2-week sprints, story points and ‘developer productivity’, rather than early and continuous delivery of valuable software?

Or how many entrepreneurs fail to get going because they interpret ‘Lean’ as ‘build a landing page’?

Both of these lead to two things founders fear the most. Missed opportunities, and disenfranchised teams being ‘busy’ but having little effect.

Get an MVP wrong, and the same thing can happen. And the truth is, most MVPs will fail — however smart you are. Trust me, I’ve seen it many times — and done it many times myself.

The solution? Go back to first principles.

Where MVPs came from, and where it is now

Here’s how Eric Reis first described an MVP;

“…the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”.

If you understand Lean principles through and through, it’s a fantastic definition. But to those jumping into startups for the first (or even second/third) time, I think it’s a step too far.

If you’re true to this definition, and MVP can take many formats. For this post, I’m going to focus on the first ‘live’ version of a product — a ‘launch’ MVP.

This is where the founding team has done their research, is confident (enough) that their product will work, and want to build, release it to customers and start seeing revenue.

Intentionally or not, MVPs are always designed to answer one or two key questions. With the first ‘launch’ MVP teams are asking;

“Does the product really work?”

“Will it get traction?”

If it really works, and the market is bigger than the one or two customers your first bringing on board, it will get traction.

So to build a successful launch MVP we have to ask ourselves, what does ‘work’ really mean?

Customers care about outcomes

Customers hire a product to get a job done.

Whether it’s to get from ‘A’ to ‘B’ (Uber), store/share their files (Dropbox) or manage their customer data (Salesforce), all that customers ultimately care about is whether your product delivers against that job.

In short, whether it delivered the outcome they wanted.

So before you do anything else, make this central to your thinking.

That’s because your customers will be the only reason why your startup exists. Not your brilliance, or your fantastic product. If they don’t care about the outcome you’re offering, or if you can’t deliver it, you will have no business.

When you approach customers (or if you’re lucky, they approach you), they’re doing so because you’re promising to deliver an outcome they desire.

That’s it, simple.

So, what matters for that launch MVP? Two things:

  • Do you deliver the promised outcome?
  • Do they respond in a way that proves out your business model? (e.g. If it’s B2B SaaS, will they pay and give you a testimonial?)

Those are the only things you need to focus on for your launch MVP. That’s what you focus on. Everything else is secondary.

Where ‘Lean’ and ‘MVP’ come in

When you’ve grounded yourself in this principle, we can bring in ‘Lean’ and ‘MVP’.

When we do that, we should now ask ourselves, “How can we deliver this customer outcome with the least possible effort?”.

Here, ‘least possible effort’ can mean many things. But it certainly means that you don’t spend 9 months building your end-vision product.

And when you do this, you can see why all those phrases I put at the start of this article exist:

  • “It should be minimal yet valuable”‘Valuable’ means delivering the outcome you promised. ‘Minimal’ means with at least effort as possible.
  • “It shouldn’t scale”Delivering with the ‘least possible effort’ probably means lots of manual effort behind the scenes.
  • “Just reduce the non-essential features”Anything ‘non-essential’ is anything that isn’t essential to delivering the customer’s desired outcome. With early adopters, the threshold for this is probably much lower than you think.

But if you understand the core reason you’re building a launch MVP, you don’t need to focus on these. They should come naturally.

Here’s a few great examples of these principles coming to life:

  • Zappos — an e-commerce with revenue in the billions — started life without their own site or even their own stock.
  • CardMunch — a service that digitised the text from business cards, acquired by LinkedIn in 2011 — didn’t bother with (what was — at the time) complicated OCR software for their MVP. Instead, they did it all manually in the background.
  • Wealthfront’s — an automated investment service firm with $20 billion assets under management — started without any of the ‘automated’ part. They simply manually created and delivered investment plans face to face to kick-start learning.

Re-setting your MVP design

So if you’re setting out to build an MVP, or re-designing one that failed, focus on these three questions:

  • What is the outcome that our customer wants?
  • How do they measure that?
  • How can we deliver this outcome with the least possible effort?

As a good measure, your MVP should almost feel like a joke; where (non-startup) people will almost be shocked about if they find out how it works behind the scenes. Or on the flip-side, one that you’d be proud to shout about when you’re well on your way to success.

When you’ve defined it, get it setup, onboard the customer, and test that it delivers the outcome the customer wants.

And then — here’s the crucial bit — iterate.

Why? Because unless you’re incredibly lucky, it won’t work first time.

When you iterate, it’s very likely that these iterations should involve large changes. Almost to the extend where they feel like pivots.

Why? Your early adopters are going to be very forgiving. So if you haven’t made them happy, your solution isn’t ‘slightly’ wrong, it’s probably very wrong.

This is exactly why you need to fall in love with the problem, not the solution.

When you finally get there and your first customer is happy, see if you can repeat it with a second customer. Then a third, then a fourth.

Then use those testimonials to acquire new customers. Then begin replacing your heavily manual processes so you can bring on more clients. And so on.

The message beneath all this; don’t skip ahead

And this is what it’s all about. Too many startups skip ahead and think about acquisition and scale.

Do that, and you miss the main thing that the business there to do — deliver an outcome for the customer.

Starting? Struggling? Then reset.

  1. Define on the outcome that your customer wants, and how they measure it
  2. Get something out as quickly as possible that you think will achieve both of these
  3. Iterate until you’ve made your first customers happy, and they’ve responded in a way that’s key to your business model. Remember these iterations are most likely to be relatively large changes

Further reading

  • MVPs are a complex topic. For brevity’s sake, I’ve focussed on one type of MVPs that most founders gravitate towards — the first ‘version’ of the product. If you want to understand what else can MVP can look like, I’d recommend starting here.
  • If you’ve got a huge vision, you’ll need to understand how an MVP fits into that process. If you’re thinking on the grandest scale, of course SpaceX is a great analogy to use as a blueprint. A little closer to home, here’s a good jumping off point for how to first customers relate to your product vision.
  • If you’re looking for inspiration on the types of tests you can do to both generate and evaluate market segments and product ideas, I’d recommend downloading The Real Startup Book.

--

--