MVP - What Does It Actually Mean

MVP, or Minimum Viable Product, is the first working version of a product. It’s not about building a product as cheaply as possible or creating half an app and calling it an MVP.

It’s about finding the smallest version of a product that actually solves a specific problem.

Let’s say you want to build an app for booking appointments with specialists. A user should be able to find an available time, choose a service, book an appointment, and receive confirmation. That’s the main thing the product needs to do.

At the beginning, you don’t need a loyalty program, advanced analytics, chat, dozens of different notifications, or thirty filters. Those things can come later. Not because they’re bad - simply because they’re not needed to find out whether the core idea works.

Where do we start?

Not with a list of features. First, we want to know: what are we building, who is it for, what problem are we solving, and what should the user be able to do?

Only then do we define the scope of the first version.

For every feature, you can ask a simple question:

Can the user still achieve their main goal without this feature?

If yes - it can wait. If not - we probably need it.

It’s a simple rule, but this is where you can avoid a large part of unnecessary costs. The budget rarely disappears because of one huge, unnecessary feature. It usually disappears little by little: “let’s add this too”, “maybe that would be useful”, “let’s build a version for companies as well”.

A few months later, you’ve built a lot. You just still don’t know whether anyone actually needs it.

An MVP should be small. But it shouldn’t feel unfinished.

The first version doesn’t need everything. It does need to work.

Users should be able to complete the most important action without wondering what to click or constantly running into errors. That’s why even with a small scope, we care about simple usability, a good interface, working core features, stability, and the ability to see how people are using the product.

Fewer features doesn’t mean a worse product. It means focusing on what actually matters.

So why build an MVP at all?

Because before a product is launched, most things are still assumptions.

You can be convinced that users will use a particular feature. You can assume they’ll be willing to pay. You can have a very specific idea of how the app should work.

You only start knowing what actually works when the product gets in front of real people.

That’s why after launch, we look at what people use, where they drop off, what they don’t understand, what they’re missing, and what they’re willing to pay for. Then we use that information to make the next decisions.

Build → launch → check → learn → improve.

An MVP isn’t a cheap version of a product

It’s the first sensible version of a product that solves a specific problem and lets you find out whether it’s worth going further.

The earlier you learn what users actually need, the less money you’ll spend building things they don’t.

That’s what an MVP is for.