The decision
An MVP needs one complete path to a useful outcome and a way to learn whether it matters. Removing screens is not the same as removing risk. A feature belongs when the core user cannot finish the chosen job without it, or when its absence makes the experiment unsafe or unmeasurable.
A worked example
For an illustrative equipment rental service, keep availability, a booking request, staff confirmation and cancellation. Manual invoicing can remain outside the product if someone owns it and customers understand the process. Record requests declined because equipment was unavailable; successful bookings alone hide important evidence.
Choose a complete slice of the rental journey
Write the first release as a sequence of actions with a beginning and an end. A customer finds an available item, requests dates, receives a decision and knows what to do next. Now remove a proposed feature and replay the sequence. If the job remains understandable and someone can cover the gap responsibly, the feature may wait. If removal leaves money, availability or responsibility ambiguous, the gap belongs in the first-release discussion. This method is more useful than calling every feature “must have” because it forces the team to explain the promise being protected.
Put limits around manual work
A manual workaround is a deliberate part of an MVP only when it has an owner, capacity and a visible status. In the rental example, staff can confirm bookings manually, but the product should not display “confirmed” until that decision exists. Describe how customers are told about a delay, what happens outside working hours and where requests wait. Keep an operator checklist and a record of interventions. Otherwise manual work disappears from the product plan while continuing to determine whether customers receive the promised service. Learning from that workload may justify the next automation.
Agree what evidence earns another feature
For each deferred capability, define the observation that would make it worth reconsidering. Multiple locations might become necessary when a real booking cannot be fulfilled correctly across locations, rather than when a competitor adds a map. Record abandoned requests, corrections, support questions and successful completion using appropriate privacy controls. Review these alongside short conversations with users; a count alone may not explain the reason. Before release, test a completed request, a declined request and a cancellation, including the staff steps. The MVP is ready to teach you something when the full promise works and the team can tell where it did not.
Alternatives worth weighing
A concierge service tests demand with manual work. A clickable prototype tests comprehension. A functioning MVP tests real use. Choose according to the unanswered question, rather than treating these as interchangeable versions of the same deliverable.
Where the plan breaks
Avoid prioritising by stakeholder enthusiasm or copying a competitor's menu. Access rules, recovery and essential notices cannot simply be postponed because they are less visible. Give every deferred item a reason and a condition that would bring it back.
Before you commission the work
Which user and job does this release serve? What can remain manual without breaking the promise? What observation would change the next investment? An MVP development brief should make those decisions explicit before listing features.