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 (4)
The acceptance check is the part I'd keep. "Can someone find a sample repair and tell the customer what happens next" is something you can actually test with a person in five minutes, unlike a feature list. I've found the trigger question gets skipped most often, and it quietly decides half the navigation.
Thanks, Rishita. I like the distinction between a feature list and an acceptance check. In the hypothetical repair example, the trigger is someone asking for the current status; the result to check is whether they can find the correct repair and give an accurate answer. What trigger questions do you find most useful when navigation still feels unclear?
수리 상태를 찾은 뒤 고객에게 다음 단계를 설명할 수 있는지로 완료 기준을 잡은 예시가 구체적이네요. 여기에 카운터와 작업대에서 동시에 상태를 바꿨을 때 어떤 값이 남아야 하는지도 작은 수용 테스트로 적어두면, 화면은 작게 유지하면서 운영 중 혼선을 확인할 수 있겠습니다.
Thanks for raising the simultaneous-update case. It adds a useful test beyond whether each person can save a status. For this hypothetical example, I'd want to check what happens when someone saves an older status after another person has updated it, and whether the second person gets a clear explanation. Do you usually define that conflict rule in the acceptance criteria before designing the screen? (I'm sorry if my translation of your comment did not fully capture your intent)