A 40-line wish list
Most first versions start as a long list in a document. A competitor has a feature, so it goes in. A prospect mentioned something on a call. A partner wants a dashboard. Each line sounds small.
Built together, those lines reach users late, with every part half-finished. Users struggle to see what the product is for, and feedback spreads so thin across features that you learn little.
This guide assumes you already know your primary user and core flow. If not, define those first, because the test below depends on them.
The four-question test
Take each feature in turn.
1. Does the core job need it?
Walk through the core flow. If a user can finish the job without this feature, it’s a candidate to cut. A food-ordering flow needs item selection, payment and confirmation. Ratings can wait.
2. Would first users refuse the product without it?
Some features sit outside the core flow and are still deal-breakers. An accounts team may reject software that can’t export to Excel. A clinic may reject a booking tool without reminders. Ask real prospective users; guesses from your own team don’t count here.
3. Can it be handled by hand for now?
Plenty of features automate work you can do manually while volumes are low. Our MVP scoping guide lists the usual candidates, such as account setup, reports and refunds (Step 4). If a manual workaround holds up for the first stretch of real use, cut the feature and note the workaround.
4. Is it much harder to add later?
This question stops you cutting the wrong things. The next section covers it.
A feature that fails the first two questions, has a manual workaround and is easy to add later should go. A feature that fails the first two but is hard to add later deserves a second look.
Cheap now, costly later
Some decisions shape the foundations. Adding them after launch can mean reworking the database and many screens.
If you’ll ever serve more than one branch, company or GSTIN, design the data for it now, even if the first version shows only one.
Build a roles structure that can grow, even if you launch with two roles. Rewriting access checks across a live app is slow and risky.
Record who changed a price, an invoice or a stock count, and when. That history is hard to reconstruct, and you’ll want it the first time something goes wrong.
Launch in English if you like, but keep screen text out of the code so Hindi or a regional language doesn’t mean a rewrite.
Include a basic data export. Customers and your own team will ask for it.
If you message customers on WhatsApp or collect personal data, record consent from day one.
These keep the second version of any custom web app affordable (web app development).
MoSCoW, used honestly
MoSCoW sorts features into Must have, Should have, Could have and Won’t have (this time). It is widely used, notably in the DSDM project method.
Its trap is that everything becomes a Must. Two rules help. A Must is something without which the first version fails its core job or first users refuse it. And set a limit: decide the budget or effort for the first version, then fill it with Musts first. If the Musts alone don’t fit, the core job is too big.
The “not yet” list
Cutting can feel like losing ideas. Move every cut feature to a “not yet” list, and beside each one write the trigger that would bring it back.
| Feature | For now | Trigger to build it |
|---|---|---|
| Self-signup | Accounts created by hand | Account requests take a real share of someone’s week |
| Ratings and reviews | Nothing | Users ask how to compare options |
| Multi-language | English, with text kept out of code | Users who need another language sign up |
| Charts dashboard | Monthly export to a spreadsheet | Managers open the export more than once a week |
When a stakeholder wants their feature in
The hardest cuts are often internal: a partner, a senior manager or an investor wants their item included. Show them the core flow and ask where the feature fits. Explain that each addition delays the day real users start giving feedback. Put the idea on the “not yet” list with a trigger, so it’s recorded with a path back. And agree up front that one person owns the final scope, because decisions by committee grow lists.
Signs you’ve cut too far
They are listed in Step 5 of our MVP scoping guide.
What we put in a first version is only what the job cannot work without. If the job still works without an item, the item waits, however good an idea it is.