An MVP is an initial scope selected to test a product idea through real use. Being small does not mean leaving users unable to finish what they started. The priority is delivering one useful outcome from beginning to end.
Write the question you want to test
Instead of “will people like my app?”, choose an observable question: “will users record a journal entry by voice and return to it later?” That question makes recording and reopening entries necessary. It says nothing yet about social following or badges.
Decide which behaviour you will evaluate before implementation. Without evidence, do not present a numerical target as an industry benchmark. Record it as a hypothesis to revisit after initial use.
Sort features into three groups
- Core value: steps that let the user complete their task.
- Reliable use: errors, cancellation, empty states and retries.
- Later expansion: features not needed to test the main hypothesis.
For a journal, creating, saving and listing entries belong in the first group. Offering text input when microphone permission is declined belongs in the second. Sharing entries with friends may wait. This is an illustrative scope, not a universal priority list.
Losing a draft is not a minor detail
The Nurena case study describes storing text as a local draft before analysis. This protects work already started. When deciding what to cut from an MVP, make similar loss scenarios explicit rather than treating every non-happy-path behaviour as optional polish.
Define acceptance in terms of behaviour
Replace “journal screen finished” with “a user creates an entry, closes the app and can find the entry after reopening it.” State what happens without a connection and what survives a failed request. Design, development and testing can then assess the same outcome.
A short acceptance scenario also exposes dependencies. Reopening a saved entry requires persistence; showing a remote result requires loading and failure states. Those dependencies should be part of the estimate.
Let use inform the next release
Keep deferred ideas in a separate list. Observe where early users stop and what they cannot complete. Improving an existing journey may be more appropriate than adding another feature.
Our product design service makes these decisions tangible through flows and prototypes. For implementation planning, read the mobile app scope guide.
Communicate the scope to your team
Once priorities are clear, put them in the software project brief template. It brings exclusions, open questions and acceptance criteria into one document.