The list for "version one" has fifty features. Each one looks essential when you view it alone: sign-up with several methods, profile, notifications, dashboard, export, permission management. After six months of development the product launches, and it turns out customers want one thing, which wasn't at the top of the list.
The "Minimum" in MVP is the hard part to apply. Here is a practical way to decide what goes in.
What an MVP is supposed to do
An MVP is a learning tool. Its purpose is to answer one question, where a negative answer makes the rest of the features irrelevant. For example: will restaurant owners pay for a system that manages their orders from different sources? Will users complete a long sign-up process if it saves them time?
Stating the hypothesis before you start is the important part. If you can't phrase it in a single sentence, you are probably planning several products at once.
The filter question
For every feature on the list, ask: if we remove it, can we still test the hypothesis? If yes, it leaves the first version. That is the whole rule.
When you apply this rule honestly, the list shrinks sharply. The features that come out aren't deleted. They move to a list called "after we learn."
The hardest features to cut are the ones considered "standard": full user management, a password reset in a designed email, a settings screen, language support. Each of them has a cheaper answer for a first version, and sometimes the cheapest is simply to do it by hand.
Manual before automated
You can deliver the experience to the user without the whole system being automated. A person approves requests instead of a rules engine. The report goes out as an email someone prepares, and isn't built as a screen. Billing is done by invoice instead of an integration with a payment processor.
This is an excellent way to test demand before investing in the build, and it also shows what the process really looks like, so the automation you build later fits reality and not assumptions. When you're developing an AI-based solution, this approach is especially useful, because it shows which cases an automated system will need to handle.
Almost every MVP has one feature everyone is sure is mandatory, and in practice the first users barely touch it. That's why we recommend starting with a manual or partial version of the process, and building automation only after you see how people really use it.
A cutting process you can run in one meeting
- Write the hypothesis in one sentence, and the single type of user it is tested on.
- List the full path of that user, from entry to the moment they receive value.
- Mark every feature that is not on this path. It comes out.
- For each step on the path, ask: can we do this manually at first?
- Estimate the time. If the version exceeds the ceiling you set, cut again rather than extend the schedule.
The ceiling matters. Without it, the first version grows slowly, every small addition looks reasonable, and six months later there are still no users. At our company, development runs in stages that begin with an MVP, and cutting unneeded time and features is a permanent part of the process.
A cutting example
The following example is for illustration only. Say a platform connects tradespeople with customers. The hypothesis: customers are willing to pay a fee for a fast match. The original list includes rich profiles, ratings, chat, in-app payment, a mobile app and an admin panel.
What stays: one request form, a match made manually by a person, an email to both sides and a manual invoice. What comes out: chat, ratings, the app, payment. After two months of real requests you can see which parts are truly missing, and build them in the order users ask for them.
When a bigger MVP is fine
There are fields where the first version has to be broader: financial systems bound by regulation, products that touch health, or an integration into an organization that won't accept a partial tool. Even there the rule stays the same, and what changes is what counts as "on the path." A regulatory requirement is on the path. A polished button isn't.
What you must not cut, even in an MVP
Some things cost a lot to skimp on in the first version:
- A reasonable data model. Changing a database structure after real users exist hurts far more than building it right from the start. It doesn't need to be perfect. It needs to avoid contradicting your next hypothesis.
- Basic security. Permissions, password encryption, protection of personal data. Once the product goes live with real users, there is no trial version of a data leak.
- Measurement. If you don't measure usage of the central process, the MVP teaches you nothing. Two events counted correctly are worth more than a pretty dashboard.
- Backup and the ability to restore. Even a first product can lose the data of the person who was first to believe in it.
Mistakes that keep recurring
- Many users at once. An MVP that tries to serve managers, employees and end customers ends up with three weak products. Pick one type of user and learn from them.
- Perfect design before validation. A clean screen matters, but designing every state before you have a single user is waste. A basic design system is enough, and you improve it after you learn.
- Depending on a third party before checking it's available. An integration with an external system can swallow weeks of approvals. Check it in the first week.
- Postponing launch "a little longer." Every extra week without users is a week without learning.
Who decides what gets cut
Cutting succeeds when one person has the authority to say "no." Without that person, everyone involved in the project adds a request, and every request sounds reasonable. Define a single product owner, and ask the development team to estimate the cost of each addition in days. When people see that a "small" feature costs a week, the argument ends quickly.
If you don't have an internal product owner, it's a role you can get from outside, as part of the process. Product management is one of the areas where we work.
What to do with the results
At the end of the testing period there should be a decision: continue, change direction or stop. It's worth defining in advance what counts as success, in quantity or quality, so the answer isn't set by gut feeling. If there is no clear result, that is also information, and it is far cheaper than a full version built on a wrong assumption.
Anyone who arrives at the build with an organized spec saves many rounds, and we covered that in how to write a spec developers actually understand. And on delays that happen even in small projects: why almost every software project runs late.
The bottom line
The right MVP answers one hypothesis, with one user and one path from end to end. Everything not required to test it is deferred, and whatever can be done manually is done manually. Data model, security and measurement stay even when you cut.
If you have a product idea and need a team to cut it down to a first version and take it all the way to launch, this is how our Software House works.
