Running a discovery workshop with a customer: map the process from both ends, score every task, then promise

Picture nine o’clock in the morning at a customer’s office. There are twelve people in the room. The head of operations opens: “We want AI for the whole complaints department.” The head of IT sits at the far end of the table, arms folded. The three staff who answer complaints every day have not yet been asked a single question. You have ninety minutes.

For a Forward Deployed Engineer this is an everyday situation, and how you run that session decides much of what happens next. Scaler’s FDE playbook states plainly that discovery is where most deployments are won or lost.

The goal is a problem statement and a definition of success that both sides agree on, not a wish list.

What follows is one example worked from start to finish: a hypothetical logistics company and its process for handling invoice disputes.

Before the meeting: one question, two endpoints, fewer than ten people

Koji’s guide to running discovery workshops advises writing down, before anything else, the single question the session must answer. For the logistics company, that question should not be “How can AI help customer service?” A better one: “In the invoice dispute process, which step should be automated first, and how will we measure success?”

Triaster, a company that specialises in process mapping, recommends fixing the scope before the meeting and opening with its start and end points. In this example, the process starts when a complaint email lands in the shared inbox. It ends when a credit note is issued, or when the complaint is rejected with a reason.

The guest list matters just as much. Triaster treats subject-matter experts, the people who actually do the work, as essential. It keeps numbers below ten, wants one person who understands how the process connects to other departments, and needs the support of the process owner.

Scaler makes the same point: do not talk only to leadership; sit with the people who will actually use the system. So with those twelve people, the first job is to cut the list.

Keep the process owner, the three complaints handlers, the person in accounts who issues credit notes, the head of IT and the warehouse manager. The head of operations may only need to join for the last fifteen minutes, when priorities are settled.

Map from both ends towards the middle

Once the two endpoints are on the board, ask the staff to walk through a real complaint they handled last week.

Each step goes on a sticky note: receive the email, classify it, look up the invoice in the ERP, check it against proof of delivery, request approval, issue the credit note.

Under each note, record four things: who does it, in which system, with what data, and where cases tend to wait.

Some questions will have no answer in the room, such as which system holds the proof of delivery. Do not stop to dig until you find it. PostHog’s FDE handbook advises using the customer’s real work to surface the real problems, rather than trying to model everything up front.

Mark the note with a “?”, assign someone to check it, and move on.

Ten sensible tasks, choose one

By the end of the mapping there are usually a dozen ideas on the board, all of them plausible. PostHog describes the FDE’s core judgement as exactly this: knowing which of ten sensible things to do first, and which not to do at all.

OpenAI Academy’s prioritisation matrix asks two questions of each workflow. If it worked, how much value would it deliver? How much effort and complexity would it take to implement?

To estimate value, it points to three strong signals: frequency, repetition and reach. Here is a hypothetical scoring for the logistics example, on a scale of 1 to 5:

Candidate workflow	Frequency	Repetition	Reach	Effort	Decision
Classify complaint emails	5	4	3	2	Do first
Match invoices against proof of delivery	4	5	3	4	Do later, once the data is clear
Monthly complaints report for the CFO	1	4	1	2	Don’t do
Predict which customers will complain	2	2	2	5	Don’t do

The table is not a formula. Its value lies in forcing the room to say out loud why one task was chosen over another. The CFO report is easy to build, but it runs once a month and only one person reads it. Complaint prediction sounds the most exciting, but it takes the most effort and its value is unclear.

At that point someone will ask: “While we’re at it, could we do the prediction too?” PostHog’s advice is to push back on every “should we also…”. Write the idea in a “later” column on the board so its proposer can see it has not been thrown away. But do not let it slip into today’s scope.

The questions you cannot skip

The first is for the head of IT, still sitting with arms folded. Scaler stresses that if the customer’s data is not allowed to leave the internal network, you need to know before you design anything. Ask directly: can complaint emails and ERP data be sent to an external model, and who signs that off?

The second is one PostHog includes in its scoping list: does the problem as described point to a deeper pattern? Suppose that, while telling their story, the staff mention that most complaints come from the same warehouse.

The root cause may be faulty proof-of-delivery scanning at that warehouse, with an email-reading agent merely cleaning up the consequences. Because the warehouse manager is in the room, you can ask on the spot whether this hypothesis is worth checking.

The third goes back to the goal Scaler sets: what does success look like? Do not leave the room without a sentence both sides nod to, such as “the time from receiving an email to the complaint reaching the right queue falls from X to Y”, with X measured on real data over the following week.

After the meeting: everything on the board is still a hypothesis

Koji is clear that a workshop does not produce evidence. The sticky notes, the scores and even the claim that “most complaints come from one warehouse” are all hypotheses.

Koji also advises ranking assumptions by impact and uncertainty. Applied to the logistics example, “complaint emails are clear enough to classify automatically” has high impact, because the first task rests entirely on it, and nobody has measured it. “Most complaints come from one warehouse” is also high impact and also uncertain.

So the first job after the meeting is to test those two assumptions: take a sample of real complaints, say one week of emails, run the classification step on it as a trial and count complaints by warehouse. That is exactly the spirit of using real work to surface problems that PostHog recommends.

Send a summary within a day, covering the central question, the process map, the scoring table, the “later” column, the answer on data and the definition of success.

A document like that, with the customer’s name removed, is also something you can take into an interview. On a CV, the line “ran a discovery workshop, narrowed scope from ten ideas to one and measured the outcome against an agreed metric” says more than “good communication skills”.

Mistakes that turn a workshop into a wasted meeting

One is mapping the entire company because no start and end points were fixed, so ninety minutes pass without reaching a single step worth automating.

Another is making promises in the room before asking about data constraints. Such a promise can collapse after a single email from the security team. The last is treating whatever the room agrees on as verified fact, and building on it straight away.

A good workshop does not end in applause. It ends when you have one thing to do on Monday morning, one number to measure, and a list of things to which you have tactfully said “not yet”.