Minimum Viable Product: The first step, not the last

Marcus • May 16, 2020

An upside-down skateboard.

One rather common observation I’ve made thus far is that in a company of any size, the open projects that could possibly be done far eclipse what the people you have can do in the time available.

There is an underlying complexity in how you deal with requests made by various stakeholders and customers of your products. No matter which choice is made, not everyone can always be happy. Yet things need to get done, but how, by whom, and in which order?

What’s in a MVP?

There are plenty of resources available online to tell you what exactly your Minimum Viable Product should contain, and the center of all those definitions is based around a key idea: You build a vertical slice of your product that, while feature-incomplete, is working and polished enough to gather your customer’s interest, attention and possibly money.

That is to say, you vaguely know what you are building towards, in the grand scheme of things. The details may elude you, but there is a vision of what the finished product will contain, and typically the most important features are included first.

Learning whether or not the customers agree with you here is the key part: Your imagination is one thing, but the reality may disagree. And instead of waiting for a few more months or years to throw your finished product over the waterfall, you can gather feedback now.

Key elements of a MVP include[1]:

Even those four aspects are a tall order to manage in some environments, especially if time is short and polishing is deferred to as optional.

Yet what you have created thus far may only be a prototype, a tech study to show that your general idea is applicable. Just having a minimal feature set doesn’t elevate your software towards a MVP. You could even discard the entire project at some point and rebuild it from scratch, because you now have a better understanding of your market and target audience. If you have a prototype, that is…

Do you have a MVP?

To understand why MVPs matter, you need to look at them in the context of their origin. The term was widely popularized by Eric Ries’ book Lean Startup: Trying out your business early is the best way to find out whether it thrives, barely survives or whether you should discard the idea entirely.

The 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.

Just shipping your prototype to your customer doesn’t make you eligible to claim you have a MVP at your hands: What are you learning from the product you created so far, and how are you measuring your success?

External customers generally will help you look at the problem they are trying to solve from their angle: After all, feedback is a good way to influence future development, and the more feedback you gather that is aimed towards a specific direction, the more obvious it should be where you should invest your time next.

And from personal experience, that is absolutely true: If you’re aiming at selling your product, shipping a first highly-polished version can absolutely convince customers of your software. Businesses exist to earn money, and promotion by word-of-mouth is often very beneficial.

Building MVPs in-house, either a comedy or a tragedy

How valuable a product is can be a fairly tricky question to answer if your audience is internal to your organization: Unlike external customers, your stakeholders are very likely to be at least slightly interested in what you have developed, no matter how lacking it is.

That’s because in-house stakeholders have no real alternative: It’s either the prototype you developed or nothing, there’s no possibility of just choosing a different vendor.

Just being better than nothing is a very low bar to aim for. External customers can reward good products through spending more money that will end up benefitting your team. Typically the cost of your in-house team is paid by the organization as a whole, not the stakeholders. If the department you worked for didn’t exist, you wouldn’t be out of your job: You’d be working the same hours, for the same pay, for a different department.

And if your product works & fulfills the basic needs covered by the requirements, feedback could help you build great software out of it.

But there’s always the next prototype to build, for another, now more urgent project. And the time for what you’ve been working on ran out a month ago.

Did you just ship a prototype to production? Will it be good enough until you get around to work on it once more, months or years later? And is this truly a MVP?

Incremental development

One step towards getting the product wanted is, naturally, building it.

But that’s only the first step along a journey that could take many more months and years to complete. Having a MVP helps you understand your customers & the market, and is essential in improving your software to meet expectations and goals.

However, if the first & last or second-tolast iteration you ship is a MVP, you’re nowhere near putting into action what lean software development actually entails[2].

There’s more steps left to do, and they’re not as straightforward since they’re very orthogonal to actually writing code. You can’t just tell your code-monkeys to just work harder/better/faster/stronger and pray for success.

Build, Measure, Learn loop. Source: The Build-Measure-Learn Feedback Loop, Creating Real Value by Testing Ideas

Key Takeaways

  1. Various similar definitions exist, but this one in particular is taken from MVP — what is it and why is it crucial for your business?
  2. No, only working on the software for another two weeks to fix critical bugs & then stopping development doesn’t count as “continuing to work on it”.