An app idea often arrives as a list of features. The more useful starting point is a person trying to complete a task. Describe that task well and it becomes easier to decide what the first version should contain.
Describe the situation before the solution.
Who is doing the work, what are they trying to achieve and where does the current process become difficult? A customer trying to book a service and an operator coordinating those bookings are connected, but they have different tasks.
Use examples from the current workflow. Spreadsheets, messages and repeated support questions can reveal where information is lost or an unnecessary step appears. Keep observations separate from assumptions about what people might want.
Choose one complete journey.
A first release does not need to include every future possibility. It does need to let someone finish the task it promises. Map the starting point, the decisions along the way and the result the person should receive.
Include the supporting steps in that map. Account access, validation, an empty state and confirmation are not decorative extras if the main task depends on them. A feature list becomes more useful when the team can explain how its parts connect.
Put constraints where the team can see them.
A required integration, a fixed launch date or a particular device capability may shape the whole project. Write down what is known, who owns the dependency and which question still needs an answer.
References help when their purpose is specific. A clear navigation pattern or a useful booking flow can inform the work without becoming an instruction to reproduce another product. Explain the behaviour you value, not just the visual impression.
Agree the next decision.
The first output might be a prototype, a technical check or a development scope. Choose the step that resolves the uncertainty preventing a sensible commitment. Beginning with production is not always the quickest route to a usable product.
A useful brief ends with ownership: who prioritises, who reviews, who supplies information and who approves a release. That agreement keeps later decisions connected to the original task.
Start with a person, a task and a complete outcome. Let the feature list serve that journey.
Questions for the working session.
- Who will use the first version?
- What task should they be able to complete?
- Which assumptions or dependencies need checking?
- Who can make the scope and release decisions?