Structured Customer Discovery Conversations

Hello! Last lesson distinguished the FDE’s delivery responsibility from the work of product, platform, and solutions-engineering teams. That responsibility begins before implementation: you need to understand the customer’s work well enough to avoid building a convincing solution to the wrong problem.

We’ll continue with the support-assistant example. The customer says, “Use AI to answer tickets faster.” Your task in discovery is not to choose a model or promise an integration. It is to learn who handles the tickets, how a reply gets produced today, where the work breaks down, what limits a possible change, and what evidence would show improvement. This lesson gives you a structure for a conversation that uncovers those facts without making the customer feel interrogated.

Begin with the problem behind the request

A customer may arrive with a proposed solution: “We need an AI assistant that sends replies automatically.” Treat that as a valuable clue about what they hope to achieve, not as a settled specification. You might respond: “What is happening in the current process that makes automatic replies appealing?” That question leaves room to discover whether the costly step is finding policy, drafting routine language, waiting for approval, or something else.

The Service Manual’s account of discovery is written for public services, but its central move applies here: examine a proposed solution, understand the wider user journey, and make assumptions visible.

For the support assistant, the requester might manage the support operation, while the users are agents who research and draft replies. A reviewer may approve certain answers; a policy owner may decide which documents are authoritative. You need not put everyone in one meeting. You do need to notice whose perspective is missing and arrange to hear it. An executive’s account of “slow replies” cannot, by itself, tell you what happens at an agent’s desk when two policies disagree.

A useful discovery objective is therefore specific but solution-neutral: Understand how agents answer policy-related tickets today, where time or quality is lost, which boundaries they must respect, and how the customer would recognize a worthwhile improvement.

Bring a guide, not a questionnaire to recite

A structured conversation starts with prepared unknowns, not a demand that the customer “tell me your requirements.” Before the meeting, write down what you need to learn and the questions most likely to reveal it. During the meeting, follow an important answer even if it arrives earlier than your guide anticipated.

The Nielsen Norman Group article below explains how to prepare that kind of flexible guide. Notice the distinction between a research question—what you need to learn—and an interview question—what you ask someone so they can describe their experience.

For a 30-minute first conversation, an adaptable guide might reserve a few minutes to explain the purpose and hear the person’s role, most of the time for a recent ticket and its difficulties, and the final minutes for constraints, success, and a readback. Your core prompts could be:

• Users: “Who takes part in answering this kind of ticket? Who uses the final reply?”
• Workflow: “Could you walk me through the last policy-related ticket you handled, from arrival to sending?”
• Pain: “Where did you have to wait, repeat work, or make a difficult judgment? What did you do instead?”
• Constraints: “What rules or systems affected what you could see, use, approve, or send?”
• Success: “What would need to improve for this to be worth changing—and what must not get worse?”

These are prompts, not five questions that must be asked verbatim. A detailed account of one ticket may cover several. Mark those areas in your guide, listen for what remains unknown, and ask a follow-up rather than restarting the list.

Follow a real case through the workflow

A broad answer such as “Searching takes too long” is a starting point. Ask for a recent instance: “Which ticket comes to mind?” Then establish what triggered the work, which person handled each step, what information they used, where it went next, and what happened when the normal path failed.

A short requirements-elicitation video offers a useful lens for finding missing handoffs. Its questions about who, what, when, where, and how are especially helpful when a customer describes the workflow as one seamless activity.

Suppose an agent says, “I usually find a previous answer and adapt it.” A useful follow-up is, “Tell me about the last time you did that. How did you check that the answer was still valid?” If the agent replies, “I asked a senior colleague because the policy had changed,” you have learned more than “search is slow.” You have found a possible authority and freshness problem, plus a dependency on another person. Do not yet assume how often it occurs; ask about frequency or look for a way to check it.

The next video demonstrates the conversational side of this work: set expectations, ask one question at a time, avoid steering people toward your preferred feature, and give them space to describe what they actually did.

In a customer setting, explain at the outset what you are investigating, how notes will be used, and whether examples can contain sensitive information. Invite the person to omit or anonymize details they should not share. During the conversation, “What happened next?” often yields better evidence than a string of “Why?” questions, which can feel accusatory. Closed questions still have a place for confirmation—“Was a reviewer required for that reply?”—after you have heard the story in the person’s own terms.

Separate reported experience, your interpretation, and an unknown in your notes. For example: “Agent reports checking policy dates on recent tickets”; “possible document-freshness issue”; “unknown how often outdated documents appear.” That distinction keeps one memorable story from silently becoming a universal requirement.

Surface boundaries and define what improvement would mean

Once you understand the current work, ask what a solution would have to live within. In the support example, that might include document permissions, rules for sending replies, existing ticketing tools, a required review process, data-handling restrictions, or an implementation deadline. Avoid turning a reported preference into an immovable rule. “We cannot change the review step” calls for a follow-up: is it required by policy, imposed by a current tool, or simply how the team works today? Who can confirm?

Return to the Service Manual for its distinction between constraints that cannot readily change and processes that may be changeable, and for its emphasis on deciding how success could be measured.

“Faster answers” is not yet a usable success criterion. Ask: Faster for which ticket types? Measured from when to when? What is the current baseline? Could the customer obtain that data? An illustrative proposal to discuss, not a target to impose, might be a reduction in median handling time for eligible policy tickets, accompanied by checks that unsupported or incorrect replies do not increase. The time measure addresses speed; the quality check guards against achieving it by sending worse answers.

Success also has a human side. If agents must leave their ticketing workflow to use a new tool, low adoption may defeat an otherwise impressive speed result. Ask who would use the change, what would make it trustworthy to them, and who would judge whether a trial worked. Detailed acceptance criteria come in the next lesson; here, establish the outcome, baseline, possible evidence, and decision-makers.

Close by testing your understanding

Leave time to read back a brief account, not to pitch an architecture. For example: “I heard that agents handling policy tickets sometimes adapt earlier replies, but need help confirming which policy is current. A reviewer approves some replies before sending. We still need to verify how often the policy check delays work, who owns the documents, and whether the review step is mandatory. Is that accurate? What have I missed?”

That closing gives the customer a chance to correct you. Afterward, organize the notes under the five discovery headings—users, workflow, pain points, constraints, success criteria—and flag each consequential unknown with a person or source who can verify it. If you spoke only with a manager, arranging a conversation with an agent may be the most important next step.

The key takeaway is that structured discovery is prepared but responsive. Start from the customer’s desired result, follow a real instance of the work, probe friction and boundaries without presuming a solution, and confirm how improvement could be observed. In the next lesson, you’ll turn what discovery establishes—and what it leaves uncertain—into testable functional requirements and acceptance criteria.