Why Minimum Viable Products need a name change.

The most misleading thing about minimum viable products (MVPs) in my opinion, is the name. Fundamentally, they should not be a product, especially if you’re bootstrapping.

5 min readMar 22, 2019

Why does this matter?

In short, assumptions. The assumption that something is a product, builds a false idea in the minds of the team building it. Without going too deeply into the semantics of the word, in the context of digital, I’m defining a product as:

“A discrete, complete solution to a stakeholder need”

We use products like this, all the time. We less frequently use MVPs, because as by their very purpose, they don’t scale. This means that for inexperienced teams, the idea of constitutes “minimum” and “viable” is skewed. This is especially true in the early stages of a bootstrapped startup, with limited technical capacity.

I’m a big advocate of running a Lean process in startups. I read the books, used the templates, preached the gospel. But still I made all the cardinal mistakes myself:

Designing something too complex
Spending too long building it
Spending too much resource on the build
Refining the minutia before validating the main concept

This leads to hundreds of hours wasted, months of runway lost and ultimately lack of traction. This double jeopardy of wasted time and lack of insight/traction is the real killer of many bootstrapped startups.

So what should it be called?

Having made the mistakes, I also feel I’ve developed more of a sense of what it takes to ship an MVP. Generally, I’ve learned that MVPs fall into two camps:

Minimum Viable proposition (MV-prop) — testing if stakeholders will “buy” it
Minimum Viable feature (MV-feat) — testing if stakeholders will “use” it

In this context “buy” means acquiring new users and “use” means behaviors that drive retention or successful outcome.

In high regulation sectors, it may be necessary to build more than a single MV-feat at a time. If that’s the case, I’d encourage you to either avoid being bootstrapped, or think very carefully about how you test ideas without a product i.e. as consulting or human service, that is less easy to scale, but easier to change.

Minimum Viable propositions

MV-prop’s require three ideal components — audience, proposition delivery and measurement. Three questions to ask:

How will we drive traffic to the test?
How will we display the proposition?
How will we measure the reaction?

Examples of this could include:

A Landing Page with PPC campaign to drive traffic and sign up box
A button on an existing website (with traffic), measured by analytics
A social media post that gathers comments and feedback
A new community, on a platform (e.g. Reddit) that attracts interested users and allows them to debate relevant topics
A leaflet, taken to a trade show, that facilitates conversations
A slide deck used to present the concept to potential customers and agree to contracts

These are cheap, simple, non-technical ways to acquire customers.

Minimum Viable features

MV-feat’s require three similar components to MV-prop’s — audience, the feature delivery, measurement. The three questions to ask:

How will we provide the feature to the user at a relevant point in the UX
How can we avoid building the feature, whilst still providing the benefit
How will we measure the impact on the user?

Examples of this include:

Using a human with a list of instructions, to mimic an automated service
Building a spreadsheet that does the job and fixing errors on the way manually
Using a tool like Zapier to tie together existing services (with a human for the gaps)
Coding with an existing framework/API/SDK

There is a reason that coding comes last in this list. I cannot emphasize enough how important it is to try to avoid building the feature (more on that below).

Why developers are (often) bad at MV-feats

For a talented developer, writing a line of code may be easier than manually responding to a load of repetitive emails over a series of weeks. This is, entirely, their value to the company. The ability to automate the repetitive, using computers. However, in an early bootstrapped startup, trying to ship a series of MV-feats, this presents several problems:

Estimation — most things take longer than you think. Show me someone who estimates accurately 100% of the time and I will show you a liar.
Maintenance — every line of code is an overhead. You have to think about the whole lifecycle of the code when costing it out.
Dependencies — it’s likely you will build using other peoples code. Changes to this will affect your maintenance costs.
QA — solving the problem is only one part of the job. If something automated breaks, you need ways to know.
Change — an MV-feat is an experiment, you have to cost in continual changes. The pathway will not be straight.
Pride — anyone who creates well, will have pride in their work. They will usually build something ever so slightly better than you need. Then, also, throwing it away becomes harder too.

It may seem like a waste to not let you CTO do what they’re paid for. But honestly, if you can test things without building new things, it avoids a mountain of pain. The reward of enough successful tests is building something beautiful.

A Lean Mindset

As with many early stage areas of startups, one of the key things, in my opinion, is the mental model you adopt. The behaviours I have come to value at this stage are:

Get good at writing tests — if you can’t be explicit you have work to do before designing
Avoid building things — again, being smart with how you spend your skills
Over-estimate complexity — whatever you can do to strip out extraneous parts will save you complexity. Think payment, login, design… anything that can be an email with a human on the end is a win in this context
Switching things off that don’t work — nobody enjoys killing a feature they thought was useful. Thinking of insight as the value makes it easier.
Not lacklustre — working “dirty” does not equal work “sloppy”.What you build must work enough to legitimise the outcomes. Don’t skimp on testing.
This is not about pride—you are not making something beautiful (unless aesthetic is what you’re testing). You are creating an experiment.