MVP in software development: how to scope one that ships

Most software projects struggle because of scope, not code. The MVP is the best-known answer to that problem. It is also the most misunderstood one.

I manage client projects at PNZ Medya and our own product at Entrobase. So I want to explain the MVP in software development from the mistakes I see on both sides, not from a glossary. Three of them come up again and again: treating the MVP as a small product, confusing it with a prototype, and shipping it without measuring anything.

What is an MVP in software development?

MVP stands for minimum viable product. In software and in startups, it means the smallest version of a product that is worth putting in front of real users.

Eric Ries brought the idea to a wide audience with his book The Lean Startup. In his definition the weight is on learning, not on the product.

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.

The definition I use at work is simpler: the smallest version that solves the target user's core problem and lets you measure that it is used. Both conditions matter. If it does not solve the problem, nobody will use it. If you cannot measure it, you will not know whether anybody does.

In this definition, "minimum" describes focus, not the number of features. An MVP is not a copy of the big product with a little of every part. It is one narrow path that solves one problem from start to finish.

MVP vs prototype vs full product

These three ideas get mixed up in meetings all the time. When they do, the wrong thing goes live, or the right thing never does. It helps to separate them by purpose and by whose hands they are in.

At PNZ Medya we never start development before showing a working prototype. That rule turned out to be the most effective way to settle scope early. People want to see something that works before they decide. Once they see it on screen, they often point out what they do not need.

Still, a prototype does not replace an MVP. A prototype helps you make a decision. An MVP shows, through real use, whether that decision was right.

How many features does an MVP need?

The smallest version that solves the target user's core problem, and lets you measure that it is used, is enough. In scoping sessions we cut every feature against that test. One question does most of the work: can the user solve the core problem without this feature?

If the answer is yes, the feature moves to a later release. When you ask this honestly, these items usually move:

• Detailed reports and export options in the admin panel.
• Support for several languages and currencies.
• Roles and permissions that sit outside the core flow.
• Custom settings and notification preferences for every user type.
• Integrations nobody has asked for yet.

There are ready-made prioritisation methods, and MoSCoW is the best known. The method helps, but if you do not tie the list to a single question, every feature drifts into the "must have" column. As the list grows, the MVP turns into a big project that happens to be called an MVP.

The MVP scope document: what is in, what is out, and why

If scope grows in every meeting and the delivery date keeps slipping, the cause is usually that nothing is written down. Everything discussed counts as agreed. A short, clear document prevents that.

1. Target user and the problem solved: one sentence.
2. What is in the first release: each item as a user story with acceptance criteria.
3. What is deliberately left out: each item with a short reason.
4. Metrics to track: three at most.
5. When, and based on which data, the decision about the next release will be made.

The most useful part of this document is the "out" list. When a feature that was left out comes back, the debate does not restart from zero; people look at the document and the reason. A decision you do not write down gets argued again every week.

A ready prompt to cut your MVP scope

If you have a long feature list, you can use the prompt below in an AI assistant. Treat the output as a first draft for your scoping session, not as a decision.

I want to cut the MVP scope of a software idea. Below are the target user, the problem I want to solve and the features I have in mind.

Your task:
1. Rewrite the target user's core problem in one sentence. Ask me where you are unsure.
2. Test every feature with this question: can the user solve the core problem without this feature? If yes, move it to a "next release" list.
3. Using the remaining features, write one flow the user follows from start to finish, step by step.
4. Suggest at most three measurable signals that would show this flow is actually used.
5. Give the result under three headings: in the first release, deliberately left out (with reasons), what we measure.

Do not add features that are not on my list. Keep it short and use bullet points.

Target user: [write here]
Problem to solve: [write here]
Feature list: [paste here]

Write down what you will measure before launch

The picture I see most often in product teams is this: the MVP goes live, but nobody measures which feature works. The next decision is made on instinct again. In that case the whole point of an MVP, which is learning, never happens.

Write your metrics before launch and keep them few. For most MVPs, three questions are a good start:

• Do users complete the core flow from start to finish?
• Do people who tried it once come back?
• Does user feedback land in one place on a regular basis?

Having your MVP built by an agency? How to protect the scope

I write this as someone who sees both sides. An agency's clock runs on the client's calendar: the deadline is fixed and the scope is drawn by the contract. A product's clock is uncertain; you do not know what will work until users arrive.

What brings these two clocks together is, again, the scope document. If you prepare it before asking for quotes, the quotes price the same work and become comparable. During development, ask for a weekly demo: finished work is shown running and checked against the document.

Someone on your side should track scope, priorities and delivery. If nobody in the company can take that role, an outside product owner or technical lead can do it.

After the MVP: let user data set the next release

In many teams that ship an MVP and then get stuck, the roadmap is just the rest of the list written before the MVP. But that list was written before any user showed up.

Set the priorities of the next release by looking at the first user data. The metrics you tracked, the feedback you collected and the reasons behind what you left out are read together here. Sometimes a feature from the old list moves up. Sometimes a need you never thought of does.

Think of your MVP not as a small product but as a narrow answer to one question. Write the question in one sentence, answer it with the smallest version you can, and measure the result. If you want to turn your idea into a plan like that, we can work on it together.