The key points
- Start from the riskiest assumption, not from a feature wish-list.
- Keep the core task and make it work properly.
- Defer admin tooling, dashboards and settings.
- Write down what you are deliberately leaving out.
How do you decide what is core?
Ask what a user must be able to do for the product to have any value, then ask what you need to see to know whether they valued it. Everything that serves neither question is a candidate for later. This is harder than it sounds, because features that feel complete are tempting, and it is common to watch more runway disappear into premature admin tooling than into any other category of work.
What can safely be deferred?
Most things that make software feel finished: elaborate settings, detailed reporting, multiple user roles, themes, bulk tools and polished onboarding. Early on, the team can handle many of these manually or through simple existing tools or lightweight workflow automation, which also teaches you what is worth automating.
- Admin panels that staff could replace with a spreadsheet for now
- Analytics dashboards beyond the one number you need
- Settings and preferences
- Additional user roles and permission levels
How do you keep scope from creeping?
Keep a visible list of what is out of version one of your MVP, and add to it deliberately, because every addition lengthens the MVP timeline. When a new request arrives, ask which assumption it tests; if the answer is none, it goes on the list. Review the list after launch, when usage shows which items were actually missed.
Feature triage questions
- What must a user do for this product to be worth anything?
- What will tell me whether they valued it?
- Can this feature be handled manually for now?
- Does this test an assumption, or just feel complete?
- Is it written on the out-of-scope list?
Sources
Rules and guidance this answer relies on. Policies change, so check the current version before acting on it.