Start with a task your customer already does. Ask them to walk through the last time they did it, find the difficult handoff and turn that into one outcome an app could help them achieve. You will leave with a more useful build brief than a list of features people say they might want.
Your first milestone is small: one conversation, one task described accurately and one testable next step. Download the customer-task interview worksheet and fill it in as you go. You do not need to sell an app during the conversation.
Ask about the last real occurrence
Choose someone who actually performs the task. The business owner may approve a purchase while a receptionist handles the work every day. Those are different perspectives; start with the person doing the work, then check who makes the decision.
Ask permission to take notes. Explain what you are exploring and let them skip anything private. An empty form or redacted example is often enough to understand a process. Do not request customer lists, passwords or sensitive records for an early exercise.
Use these questions as a conversation, not an interrogation:
- What happened that made you start this task last time?
- What did you do first, and what happened next?
- Which people, messages or tools did you need?
- Where did you wait, repeat work or ask someone for help?
- What did you do when the usual process did not work?
- How did you know the task was finished correctly?
- What would make changing the current process difficult?
Follow an answer with “Can you show me a harmless example?” or “What happened next?” Let their sequence emerge before suggesting a screen. “Would an automated dashboard help?” invites agreement without explaining the job.
Separate evidence from your interpretation
Keep four kinds of notes: what the person said, what they showed you, what you assume and what you still need to learn. If they estimate a task takes an hour, record it as their estimate. It becomes a measured duration only when you observe or collect an appropriate measurement.
Avoid treating an enthusiastic response as a buying commitment. Ask how they decide to adopt a tool, who approves it and what it would replace. A useful problem can still have an unsuitable buyer, an infrequent need or a simpler solution.
At the end, play the task back: “When this happens, you need to do this, so that this result is clear. Have I missed anything?” Their correction is useful progress. You are trying to describe their work accurately.
Work through one example
The following is a fictional exercise, not a customer interview or a reported result. Imagine a small service business handling requests to change an appointment. Use it to practice turning loose notes into a brief.
| Exercise note | What it gives you | What still needs checking |
|---|---|---|
| A customer calls to move an appointment | Trigger: requested change | How often does this happen? |
| A coordinator checks a calendar, then messages a staff member | Two people and a handoff | Who may approve the new time? |
| The customer calls again because they are unsure whether it changed | Desired outcome: an unambiguous decision | Which confirmation channel is acceptable? |
| The business already has a booking tool | An existing system to respect | Can a process change solve this without another app? |
Do not jump from these notes to “build a complete booking platform.” The smaller task is to record a requested change and make its decision clear. Calendar integration, automatic messages and payments introduce separate setup and testing work.
Compare this exercise with your notes. Keep only details supported by your conversation. Replace guesses with questions for a follow-up rather than letting them quietly become requirements.
Write a brief with a visible passing result
Use a sentence a customer could recognize: “When I request a new appointment time, I need to see whether it is pending, accepted or declined, so I know which time to attend.” Then name the people, record and rules needed to support it.
Here is a practice brief for the fictional exercise:
Build a sample appointment-change request flow.
People: a customer and an authorized coordinator.
Record: original appointment, requested time, request reason,
decision, decision time and the person making that decision.
The customer sees only their own requests.
The coordinator may accept or decline a request and add a short explanation.
Keep the original appointment unchanged while the request is pending.
If accepted, make the requested time the confirmed time in the sample record.
If declined, retain the original confirmed time and show the explanation.
Preserve the decision and confirmed time after refresh and sign-in.
Start with fictional appointments. Do not connect a live calendar,
send messages or take payments in this first test.
Passing exercise: accept one sample request and decline another.
The customer returns and correctly identifies each confirmed appointment.
List unresolved scheduling rules and setup before suggesting a live pilot.
The app-brief guide helps expand this into records, permissions and acceptance checks. If your assistant will build it through a connection, use the MCP walkthrough. Account access, available tools and build credits still apply.
Inspect a real starting point without skipping discovery
The public Bookslot template gives you a concrete service-selection flow to inspect. The booking-app guide shows its public steps and explains the scheduling checks a real service app needs.
An actual Bookslot preview capture from September 9, 2026. Use it to discuss a concrete flow after understanding the customer’s task; it is not evidence of demand or a completed booking.
Open full-size imageLook at the order of choices, the information requested and the point where a customer would expect confirmation. Compare those choices with the task you heard. A well-presented flow can still be the wrong fit for that person's work.
You can open the Bookslot remix entry when you are ready to create your own version, subject to sign-in, access and credits. The public preview does not establish that your copy handles saved bookings, conflicting requests or private customer records. Test your version before using it for real appointments.
Invite a small, deliberate pilot
Begin by asking the participant to complete the sample task in a prototype. Give them the goal, then watch where they hesitate or need help. Write down completed actions and errors separately from comments about the design. If you must explain every step, the next job is to improve that flow.
For a later live pilot, agree on its participants, duration, permitted data, support contact and fallback process. Explain any costs and which parts remain manual. Decide what success and a stop condition look like before starting. For example, a wrong confirmed time should stop the pilot until it is understood and fixed.
Review the launch checklist, including access and saved-data checks, before introducing real work. One successful task is useful evidence about that task; it is not proof of demand across a market or a revenue forecast.
Finish this exercise with a decision: clarify the problem, test a simpler process or build the smallest useful flow. Put the owner and next action in the worksheet. That gives the conversation a practical result, even when the right next step is not an app.