The short answer
Define your MVP around one user completing one valuable task, then state what that release needs to teach you. Include the features required for a credible test and the safeguards needed to run it responsibly. Keep everything else conditional.
Start with the decision you need to make
Consider a hypothetical scheduling product for maintenance teams. The backlog has a calendar, route planning, customer chat, invoicing, and a dashboard. All sound reasonable. None tells you what the first release should prove.
A better starting question is narrower: will a dispatcher use this to assign a job and get a confirmation from the technician? That gives the product a complete task to investigate. Route planning can wait unless the task requires it.
Write down the investment decision before discussing features. Are you deciding whether to fund a broader build or pursue a particular buyer? A demonstration that supports a sales conversation isn't automatically a useful test of repeated use.
Write a boundary someone can disagree with
Keep the MVP brief to one page. Include four statements:
- User: the dispatcher assigning work for a small maintenance team.
- Task: assign a job and see whether the technician accepted it.
- Evidence: observe whether the team uses the flow for subsequent real jobs without step-by-step guidance.
- Exclusions: no route planning, payroll, customer messaging, or automated invoicing.
The exclusions do real work. When someone asks for a customer portal, discuss how it changes the test instead of debating whether portals are useful. They may be. Usefulness alone doesn't earn a place.
Choose evaluation criteria before development, based on the intended pilot and business decision. An impressive-looking benchmark borrowed from another product won't settle yours.
Give every backlog item a job
Treat this table as a scope conversation, not a scoring algorithm. Explain what breaks without each proposed feature.
| Item | Why it matters | First-release decision |
|---|---|---|
| Assign and accept a job | This is the task being tested. | Build. |
| Account access rules | Job information must reach the right people. | Include appropriate safeguards. |
| Invoice generation | It follows the task but doesn't test acceptance. | Use the existing invoicing process. |
| Route suggestions | The value is plausible but untested. | Defer unless dispatch requires it. |
| Custom dashboard | The team needs visibility, not necessarily a dashboard. | Start with a simple operational view. |
Give items serving another user or buying decision a separate hypothesis. Otherwise the MVP quietly becomes two products sharing a deadline.
Keep the trust floor intact
Small scope doesn't excuse careless operation. Decide what data the pilot will hold, who can access it, and how mistakes will be corrected. Give users understandable errors and a recovery path.
Manual work can be a sensible boundary. An operator might approve an account or prepare a report behind the scenes. Write down that work, assign an owner, and record the effort. Otherwise you risk attributing a labor-intensive service to software that hasn't delivered it.
Disclose human involvement where it affects user expectations or data handling. Don't remove a safeguard because it is less visible than a feature in the demo.
For an App Store submission, a small scope still needs a complete, working app without placeholder content. Review Apple’s app-completeness requirements before planning the release.
Plan for an answer you don't like
Agree what you'll do if the pilot doesn't support the idea. Otherwise, every weak signal can become an argument for another feature.
Abandonment before assignment needs a different investigation from assignments that technicians never acknowledge. Watch the task and talk to the people involved. Distinguish usability trouble from lack of value; a dashboard won't answer either question by itself.
Keep observations separate from interpretations. “The dispatcher returned to the spreadsheet after creating a job” is an observation. “They need more reporting” is a hypothesis. Test the second statement before it becomes a requirement. The release should improve the next decision, including a decision to stop.
Make scope changes pay their own way
New information should change a plan. New enthusiasm shouldn't change it invisibly.
When a feature request appears, ask which part of the task it supports, what evidence prompted it, and what leaves if it enters. Record accepted changes with their consequences for scope and evaluation.
Give the team a sentence it can use in a meeting: “This release helps a dispatcher assign a job and get a confirmation; we're learning whether teams will use that flow in real work.” If that needs a long list of caveats, the boundary is still loose.
Bring the sentence to your next scoping conversation. Leave the feature wishlist underneath it.
What to take into your next meeting
- Define the decision the release should inform before selecting features.
- Keep manual work visible and include the safeguards the pilot needs.
- Require new scope to explain what it changes or replaces.
Apply this to your product.
Bring the decision you’re stuck on. We’ll help make the trade-offs clearer.
Discuss your project
