Most first versions are too big. Not because founders are careless, but because every feature feels important when you have been thinking about the product for months. The result is a long build, a late launch and a lot of work on things nobody has asked for yet.
The useful question is not "what should the product do?" It is "what has to be true on day one for this to be worth launching?" Everything else can wait.
Start with the one thing you need to prove
Every product rests on an assumption. That people will book online instead of calling. That a team will publish without a developer. That customers will buy after reading. Your first version should test that assumption as directly as possible.
Write it down in one sentence. Then go through your feature list and ask, for each item: does this help prove it? If not, it probably waits.
What usually belongs in the first version
- The core flow, end to end. The one journey your users came for, working properly from start to finish. A complete narrow flow beats a wide, half-finished one.
- The minimum to take payment or capture value, if that is part of what you are testing.
- Enough admin to run it. Often this can be simple, or even manual, behind the scenes.
- The basics people will not forgive: security, data protection, and anything a regulator cares about. These do not wait.
- A way to learn. Basic analytics and an easy way for users to tell you what is wrong.
What can usually wait
- Settings, preferences and customisation.
- A second or third type of user, if one will do for now.
- Integrations that can be handled by hand at first.
- Polished dashboards and reports.
- Native mobile apps, if a good web version will prove the point.
- Clever features, including the AI one, until the basics are working.
"Later" is not "never". It means after you have evidence that the core works and people want it.
Three decisions that shaped real first versions
On a connected health product with a launch date that could not move, the decision was what had to be true at launch. The flow from device to result came first. Everything else was sequenced after it, and the date held.
On a content platform for a lean team, the first version was built so the team could publish on their own from day one. That mattered more than any feature on the list.
On a storefront split across two platforms, the first version did not migrate everything onto one. It joined the two where customers felt the gap, which was faster and far less risky.
In each case, the first version was defined by a decision, not by a feature list.
Signs your MVP is too big
- It will take more than a few months to launch.
- You cannot say in one sentence what it is meant to prove.
- It serves several kinds of users equally.
- Removing any feature feels impossible.
The short version
Decide what you need to prove, build the narrowest version that proves it properly, and keep the basics people will not forgive. Write down everything else, so waiting does not feel like losing it.
If you are working out what your first version should be, this is how I work with founders. The first conversation is usually about exactly this.