TLDR: Your MVP is a model of how you think users will solve a problem. Every feature is an assumption. Build fewer features to minimize assumptions and increase the probability that your MVP is most likely to be true

Your MVP Is A Model of How Users Solve A Problem

As many product managers can recite verbatim: “an MVP is the minimum viable product needed to solve a customer problem.”

However, by rephrasing and reframing the definition, we can view an MVP from a slightly different perspective, as a more standardized scientific model.

An MVP is a standard model of how users solve a problem.

Any model takes some inputs and outputs.

Users with a specific problem may download and install an app in hopes of solving their problem. We can apply the process framework above to a basic example of a User downloading and installing Airbnb to solve their problem.

Solving a problem using Airbnb as our MVP model

Input = User trying to solve a problem

Our user needs to find a place to stay for a weekend getaway quickly approaching and doesn’t have a huge budget so they download and install Airbnb on their phone.

Process = User Interactions with features

We can make the following assumptions: 1) user needs a way to search for listings 2) user needs to compare prices 3) user needs to see positive reviews. These are all user interactions with features based on assumptions of what we think a user needs to do to achieve their goal and solve their problem.

Output = Number of goals achieved & problems solved

Finally, after some searching, comparing, and reviewing, our user successfully books an apartment that is listed close to their preferred area, at a reasonable price, and by a trusted host. They have successfully fulfilled their needs, achieved their goal, and solved their problem..

In this way, every feature is an assumption of how you think a user’s needs and goals will be fulfilled and achieved — their problem solved. And the success of your model, ultimately, depends on the accuracy of your assumptions.

Every Feature Is an Assumption

When scientists are building scientific models and formulating hypotheses, they are hyper-focused on assumptions. If the assumptions on which a model is built are incorrect, then the credibility of the model quickly becomes contested (oh the shame…).

Any feature you add to an MVP is what you think is going to meet a customer need. You have not validated it. It is neither proven nor unproven. It is merely an assumption of how you think you’re going to solve a problem. Even jf your CEO, VP, or friendly neighbourhood HIPPO proclaims it must be a brilliant idea…

The Hard Truth About MVPs

When you are launching a new product to market, you don’t have the luxury of real-world usage data. So how do you know if your assumptions are likely to be true? How do you know if you are going to help users solve their problem, fulfill their needs and achieve their goals?

The humble answer (and only honest one) is you don’t. No amount of market research, competitive analysis, user interviews, usability testing or gut instinct can simulate the real world scenario of launching a product into the wild to see if it truly provides value to users and gains traction.

As with scientific models, if the assumptions on which an MVP is built (a.k.a., the features) are incorrect, then the credibility of the MVP quickly becomes contested…and you end up like our poor scientist above!

Launch with Minimal Viable Assumptions

This may seem discouraging, and sometimes it is, but, you can at least ensure that your methodology maximizes the likelihood of your model being true by keeping things lean and controlled.

I like to call this approach the Minimal Viable Assumptions Methodology. What are the minimal amount of assumptions you can make to get a product to market?

To launch with minimal assumptions, you must avoid feature bloat at all costs. Say no to stakeholders. Stay focused.

Because:

Any model with the least amount of assumptions is most likely to be true.

I will say it again for emphasis:

Any model with the least amount of assumptions is most likely to be true.

Now you try:

Any model with the least amount of assumptions is most likely to be true.

Ok, I’m sure you get the point. But seriously, this should become your new mantra.

Why? Because, any product with the least amount of assumptions (a.k.a. features) has the fewest variables. If you want to understand how the chemical composition of water changes when you add salt, then only add salt! The fewer variables, the easier it is to isolate and discern causality.

Be Ruthless About Causality

We want our model to help our users successfully achieve their goals. If it does, then our assumptions (a.k.a., features) were correct. If it does not, then our assumptions (a.k.a., features) were incorrect. If we have too much going on, it will become very difficult to discern causality. It will be difficult to understand which assumptions were correct and which were incorrect.

The best Product Managers are ruthless about causality.

They want to know how each feature being added relates to success or not. They are brutally figuring out the strategy of where they are heading, prioritizing, and executing. You can only build 5% of the things you can think of, so you better make sure they are the right 5%.

So the next time you are trying to get to market and stakeholder requests are piling up from all directions, remember, do not bloat your product (a.k.a., your model). Do not muddy the experiment.

Launch with Minimal Viable Assumptions to maximize the probability that your model is most likely to be true.

Channel your inner scientist. Keep it lean, keep it controlled, and be ruthless about causality. Your stakeholders will thank you!