MVP (Minimum Viable Product): A Practical Approach

An MVP (Minimum Viable Product) is the first version of your product that allows you, as the product creator, to:

• Validate the hypothesis about the need for a specific solution based on user behavior.
• Collect feedback from your future users.
• Attempt to sell (or already be selling) your solution to users.

Let’s break these points down.

As an example, let’s take a simple product — not an IT solution, but an everyday item: a Swiss Army knife.

Validating Hypotheses without a Product

Once, people came up with a hypothesis that could represent a problem: what if I find myself in a dense forest, needing to cut a mushroom and mark it after having a bottle of wine? Carrying both a corkscrew and a knife is just inconvenient (and who in their right mind takes a corkscrew into the forest?). What if we combine these tools into one?

These people (let’s call them the founders) tried to combine a corkscrew and a knife into one tool, created the first prototype (it turned out crooked and uncomfortable, but functional), and tried to sell it to future customers.

Let’s imagine they succeeded. What should they do next?

• Keep selling the current solution while gradually adding new tools (features) based on feedback and customer suggestions.
• Improve the current solution to make it more user-friendly (work on UX).
• Collect user feedback and adjust the product accordingly.

But everything only works on the first try for the creators of Swiss Army knives. In real life, 42% of startups fail due to lack of demand. Founders may launch a new set of tools (test different hypotheses) or, if things go wrong, pivot the business model.

With each version of the Swiss Army knife, our founders need to release a prototype to the market as quickly as possible to get feedback from customers.

How can this be done?

• Produce and try to sell very small batches.
• Cut costs on quality (but not to the point of ruining the product).

This approach — quickly creating a solution, testing it with users, gathering feedback, and entering the second cycle of product improvement (or pivoting the business model) — is what we can call the MVP approach.

How to Select Hypotheses and Features

A hypothesis is an assumption about a customer’s problem.

In one version of a product, you should only test one hypothesis at a time. Moreover, the hypothesis should be bold. Do people want to eat mushrooms? Definitely yes! Are they willing to drink wine? Oh yes! But does someone suddenly need both a knife and a corkscrew at the same time? That’s a hypothesis worth testing!

Now let’s move on to what can be included in the first version of the product. The answer is simple: include the features that:

1. Work to validate the core hypothesis. It’s sacrilege to add a knife to a Swiss Army knife when testing this hypothesis!
2. Provide the most value to the user. Yes, you could stuff a Swiss Army knife with a step tracker and a Bluetooth speaker, but the primary value in our example lies in the knife and the corkscrew.

All features that do not meet these criteria can be left for the future.

Validation without a Product

Is it possible to validate a hypothesis about a product without creating any solution at all?

In the IT sphere — yes, if you’re a bit smarter and savvier than our founders in the example.

For instance, they could have created a landing page for "Miracle Swiss Army Knives," driven traffic from social media, and seen if people placed preorders for the product. If they did — then it’s worth producing.

To Sell or Not to Sell?

Eric Ries, the author of "The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses," says that an MVP should start selling from day one. I completely agree with him.

We create products not only to solve problems and make the world a better place but also to make money. If you have investments and personal savings to pay designers and developers for years to come (with the plan to monetize the platform later), that’s great. But if not, the product should start generating revenue today — whether through subscriptions, ads, or charging for integrations.

Mistakes in MVP Development

An MVP is a vast field for major mistakes and squandered budgets!

Here are some common mistakes you can make along the way:

• Including too many unnecessary features. Imagine you’re Rodin (with a Swiss Army knife in hand), and you’re ruthlessly discarding what doesn’t add value to your product or support its viability.

• Ignoring user feedback. If you don’t conduct testing or listen to feedback from users, it’s unclear why you even started building an MVP. Maybe you should have just jumped into building a full product and ended up broke?

• Trying too hard. There’s a saying that if you show the first version of a product and you’re not at least a little embarrassed — you’ve overdone it. Trust me, you’ll have countless opportunities to improve your product, and making it perfect right away is not necessary!

• Not trying hard enough. You might come up with a brilliant idea to combine a knife and a corkscrew, but if you do it half-heartedly with the attitude of "good enough," you risk a user losing their hand while using your miracle tool. To rephrase: in the 21st century, it’s no longer enough to create a clumsy, buggy app. Customer expectations are growing, so make sure your first version at least looks decent.

• Falling in love with the product. Midway through development, you may need to change the concept. You may have to sacrifice features you were so fond of! Or maybe you’ll even have to abandon the whole product. Don’t fall in love with your product — otherwise, any changes will be difficult. Keep a cool head, stay flexible, and listen to your users. Remember, causing you problems and giving you tasks is their main job.