A feature list tells you what software might contain. A clear purpose tells you what someone should be able to do with it.
Before deciding what belongs in an MVP, try writing one sentence:
When [situation occurs], [person] needs to [complete a task] so they can [reach a useful outcome].
Consider a hypothetical neighborhood repair shop:
“When a customer asks about a repair, the person at the counter needs to find its current status so they can give a useful answer.”
That sentence gives you five questions to work through.
1. Who needs to finish the task?
“The business” is too broad. In this example, the person at the counter needs a quick answer. The technician may need to record more detailed notes. Their screens do not necessarily need the same information.
2. What starts the task?
A phone call, an arriving customer, or a scheduled review can lead to different interactions. For a phone call, opening a record quickly matters. A daily review may benefit from a list of outstanding work.
Describe the trigger before designing the navigation.
3. What counts as a useful result?
“Show a dashboard” describes an interface. “Find the status and explain the next step” describes a result.
For the repair shop, try a small acceptance check: can someone locate a sample repair, read its status, and tell the customer what happens next?
4. Where will the task happen?
A desktop at the counter and a phone beside the workbench create different constraints. A shared workflow needs an explicit answer about how changes reach the other device and what users see while waiting.
Choosing platforms is also choosing which situations you need to support.
5. What information is actually necessary?
Start with the information needed to complete the task. For this example, that might include a repair reference, status, and next step. Ask what else is required before collecting additional customer details.
For each field, name its purpose, who needs access, and when it should be removed.
Write a boundary for the first version
A first version could support finding a repair and updating its status. Inventory forecasting, loyalty points, and automated marketing might be useful later, but they do not follow directly from this task.
Put those ideas in a separate list. Then test the small workflow with realistic sample data and watch where someone hesitates.
What is one feature you removed from an early version because it did not serve the main task?
GateCity CodeWorks is a software studio in Nashua, New Hampshire, founded by Michael Dunlap. We build thoughtful tools around everyday workflows. Explore our work.
Top comments (0)