Almost every founder starts with a list of thirty features and a launch date in three months. The list wins, the date slips and the product reaches users late, with half of the features unused. The fix is not to work faster. It is to build less.
Start from the job, not the feature list
Write one sentence describing who the product is for and the one job it does for them. Then list the steps a user takes from signing up to completing that job. This path is your MVP. A feature is in only if a user cannot finish the path without it.
A simple test for every feature
- Can a user complete the core job without it? If yes, it waits.
- Can you do it by hand for the first users? If yes, do it by hand.
- Does it need a decision about design, data or pricing that you cannot make yet? If yes, it waits.
- Will the first ten users ask for it unprompted? If not, it waits.
What founders usually cut too late
- Team roles and complex permissions.
- Admin dashboards for things you can check in a database.
- Settings pages with options nobody has asked for.
- Integrations with tools your first users do not use.
- A native mobile app before the web version has proven useful.
What you should not cut
- Reliable sign-up and secure handling of data.
- Payments, if you want to know whether people will pay.
- Basic analytics, so you can see what users actually do.
- A clear way for users to contact you with problems.
Keep a 'later' list
Cutting a feature is easier if it is not deleted, only postponed. Keep a visible list, and review it after your first users have worked with the product. Often half of it turns out to be unnecessary, and one or two items you never thought of rise to the top.
For a step-by-step view of the whole journey, read our guide to building a SaaS MVP, and see our cost guide to understand how scope drives price.