“We need an app” is a starting point, but it is not yet a build brief. The most useful next conversation is about a real piece of work: where it starts, who handles it, what can go wrong and what tells the next person to continue.
Walk through a real example
Choose a recent order, service request or production handover. Ask the people who performed the work to describe it in sequence. Look at the forms, messages and documents they actually used.
Start with the normal path, then ask what happened differently. A workflow drawn only from a management overview can miss the small decisions that make the operation work.
Ask five questions at each handover
Use the same five questions for every step. The answers give both the business and the developer a shared language.
- Input — What information or material must arrive before this step can begin?
- Owner — Who is responsible, and who takes over when that person is unavailable?
- Decision — What makes the work ready, approved, rejected or in need of revision?
- Evidence — What record, document or sign-off should remain after the action?
- Next step — Who receives the result, and how do they know it is ready?
Make exceptions part of the brief
A useful process needs a route back as well as a route forward. Discuss a changed order, a missing document, a rejected approval and a cancelled job. Decide whether completed work should reopen, who may make a change and what needs to remain visible.
This conversation is particularly valuable when a change affects several teams. The buyer, production team and accounts team may each need a different view of the same change.
Draw a boundary around the first version
Pick a complete but narrow slice of the work. For example, capture a request, assign an owner, record the decision and hand it to the next team. Include the essential exception path and the information needed to verify the result.
List what belongs outside the first version. Existing tools may continue to handle reporting, finance or other tasks until there is a clear reason and an agreed approach to connect them.
Turn the map into something testable
Write a short acceptance example: given this input, when this person takes this action, the next person should see this result. Include an example where the information is incomplete or the request changes.
Ask the people doing the work to try the first version with representative examples. Note where they hesitate, what they still have to ask and which details they re-enter elsewhere. Use those observations to decide what to improve next.
A clear handover map makes the brief smaller, the decisions clearer and the first version easier to evaluate.
Start with the problem. Agree the scope before choosing a solution.
Read nextWhen a spreadsheet stops being enough for your workflow