Discovery and requirements capture

The short version

A discovery interview is a structured conversation to learn how someone does their work, what goes wrong, and what it costs them. The most useful single technique is to ask about the last real case: 'Walk me through the last invoice exception you handled.' A specific, recent case has real details, real systems and real time spent. A general question such as 'How do you handle exceptions?' gets the official version.

Rob Fitzpatrick's book The Mom Test gives three rules that fit discovery well. Talk about their life, not your idea. Ask about specifics in the past, not generics or opinions about the future. Talk less and listen more. The name comes from the idea that even your mother would lie to you about your idea to be kind, but she cannot mislead you about facts from her own week.

Why opinions and future questions mislead

Questions like 'Would you use a tool that does X?' or 'How much time would this save you?' ask people to predict their own behaviour. Most people answer yes to be helpful, and their estimates are guesses. Compliments ('That sounds really useful') feel like progress but carry no information.

Facts from the past are different. 'How many exceptions did you handle yesterday? Which one took longest? What did you do?' gives you things you can check against system data later. When someone says 'always' or 'usually', ask for the last time it happened.

A simple interview structure

Forty minutes is enough for most interviews. Book an hour so you never rush the close, which is where you get access to the next source of evidence.

• Open (2 minutes): who you are, why you are here, that there are no wrong answers, and that you want to learn their work, not test them.
• Context (5 minutes): their role, their day, the systems they use, who they get work from and hand it to.
• Last real case (15 minutes): walk through one recent case step by step. Ask them to show you on screen if possible.
• Dig into pain (10 minutes): which step was slowest, what went wrong, what they did about it, how often that happens.
• Workarounds and numbers (5 minutes): spreadsheets, notes, personal tricks; volumes and times they can point to.
• Close (3 minutes): ask for documents, a chance to shadow, and who else you should talk to.

Question bank

The question 'Have you tried to fix this before?' is especially telling. If someone has built a spreadsheet or asked IT for help, the pain is real. If they have never done anything about it, it may be a minor annoyance.

• Tell me about the last time you did this. When was it?
• What happened just before it reached you? What happened after you were done?
• Which system did you have open? Can you show me?
• What took the longest? What were you waiting for?
• What did you do when it did not fit the normal steps?
• How did you know you had done it right?
• Have you tried to fix this before? What happened?
• If this problem disappeared tomorrow, what would you do with the time?
• Who else deals with this, and who decides how it is done?

Avoiding leading questions and taking good notes

A leading question hints at the answer you want. 'Isn't it frustrating to chase buyers by email?' leads. 'What happens after you email the buyer?' does not. Avoid naming your solution until the end, if at all. When you hear something interesting, ask 'Tell me more about that' or 'Why?' and then stay quiet. Silence feels awkward, but people fill it with the most useful details.

Take notes in three kinds: facts (what happened, with numbers), quotes (their exact words, in quote marks), and your own interpretations, clearly marked as yours. Write up within an hour while memory is fresh. If you record, ask permission first, and follow the client's policy on recordings and transcripts. Interview in pairs when you can: one person asks, the other writes.

Interview: AP clerk, 12 min call, 2025-03-04
Case: INV-102, price mismatch, raised 3 Mar

FACT  Opened ERP exception queue, 41 items waiting
FACT  Checked PO price vs invoice: 4 percent higher
FACT  Searched shared mailbox for buyer approval, none found
QUOTE "I email the buyer and then just wait"
FACT  Emailed buyer twice (4 Mar, 6 Mar); reply 7 Mar
FACT  Tracks open items in a personal spreadsheet
MINE  Waiting on buyer may be most of elapsed time
NEXT  Ask buyer how approvals are decided; get ERP log

The short version

Shadowing means sitting with someone, in person or on a shared screen, while they do their normal work. You watch and ask short clarifying questions. In lean manufacturing this is called going to the gemba, the place where the work happens. In user research it is called a field study or, when you also interview, contextual inquiry.

Documents tell you the intended process. Standard operating procedures (SOPs), work instructions, policies and training slides describe how work should flow. System event logs tell you what actually happened, with timestamps. Together with interviews you get three views you can compare.

How to shadow well

Ask for a normal day, not a demo. Explain that you want to see real cases including messy ones. Sit where you can see the screen. Ask them to think aloud: say what they are looking at and why. Hold your bigger questions for natural pauses so you do not change how they work.

Note every system and screen used, every copy and paste between systems, every lookup in email or a spreadsheet, and every point where they wait or ask someone else. Those are the handoffs and workarounds that matter. Shadow at least two people, because individuals often have different methods for the same task, and at least one busy period such as month end if the work is seasonal.

Timing real cases

Use a simple timing sheet with columns for case ID, start time, end time, steps, systems used, and whether it was standard or an exception. Time at least 20 to 30 cases if you can, across more than one person, so one unusual case does not dominate.

Separate touch time from elapsed time. Touch time is how long someone actively works on the case. Elapsed time is from arrival to completion, including waiting. A case might take 12 minutes of touch time but five days elapsed because it waits for an approval. These lead to different solutions: one saves effort, the other removes waiting.

Record exceptions with the same care as standard cases, and note the reason each one became an exception. Over 20 or 30 cases a pattern usually appears, such as most exceptions coming from a few suppliers or one type of mismatch. That pattern tells you which cases your proof of concept should handle first.

Reading SOPs and documents

Ask for the SOP, any work instructions, the policy that governs the process (for example an approval limits policy), recent audit findings, and training material for new staff. Read them before shadowing so you can spot where practice differs.

Mark every rule that has a number or a condition, such as 'invoices more than 2 percent above PO price need buyer approval'. These rules are often exactly what an AI assistant must apply, and they become test cases for your evaluation.

Check the date and owner of each document. An SOP last updated years ago, or owned by someone who has left, is a sign that practice has moved on, and a gentle question about it often opens up the real process.

Event logs from systems

Most systems record events: case created, status changed, approved, paid. An event log needs three fields at minimum: a case ID, an activity name, and a timestamp. A resource field (who or what did it) is a bonus. With these you can compute elapsed time, count rework loops, and see which paths cases really take. The discipline of analysing these logs at scale is called process mining.

Ask IT for a read-only export of one or two months for the process you are studying, with personal data removed or masked as the client requires. Then you can query it in SQLite or a spreadsheet, as the example shows.

When interviews and logs disagree

Disagreement is a finding, not a failure. Common patterns: people describe touch time while logs show elapsed time; logs show steps repeated (rework) that people do not mention; the SOP has an approval step that logs show is often skipped; and some work never appears in logs because it happens in email or spreadsheets.

Take the difference back to the people involved without blame: 'The log shows about a third of cases are emailed to the buyer twice. Does that match what you see?' Their explanation usually reveals the real rule or the real pain.

The short version

A process map shows the steps of a piece of work in order. A swimlane map adds horizontal or vertical lanes, one per role or system, so you can see who does each step and where work passes from one lane to another. Every time a line crosses between lanes, there is a handoff, and handoffs are where delay and errors collect.

BPMN (Business Process Model and Notation) is a standard notation for these maps, maintained by the Object Management Group (OMG). You do not need the full standard. A handful of symbols covers most discovery work and makes your maps readable by business analysts and process teams who already know BPMN.

The BPMN basics you need

• Pool: a whole participant, such as your client company or an outside supplier.
• Lane: a role or system inside a pool, such as AP clerk, buyer or ERP.
• Start event (thin circle): what triggers the process, such as 'invoice received'.
• Task (rounded rectangle): a unit of work, named verb plus object, such as 'Check PO price'.
• Exclusive gateway (diamond): a decision with one path taken, such as 'Price within tolerance?'.
• Sequence flow (solid arrow): order of steps inside a pool.
• Message flow (dashed arrow): communication between pools, such as an email to the supplier.
• End event (thick circle): how the process finishes, such as 'payment released'. A process can have several end events.

Building the map step by step

Start from your evidence, not a blank whiteboard. Use your interview notes, shadowing timing sheet and event log. First, agree the start and end: what triggers the process and what counts as done. Second, list the steps of the standard path as verb plus object. Third, assign each step to a lane. Fourth, add decisions as gateways and the paths out of each. Fifth, add exceptions: what happens when a check fails, a reply never comes, or data is missing. Sixth, label each step with the system used and, where you have it, the typical time.

Draw the happy path first, then the exceptions. If you start with every exception the map becomes unreadable before anyone understands the main flow.

Levels of detail

Keep maps at the level of the conversation. A level one map fits a whole value chain stream such as procure to pay on one line. A level two map shows one process, such as invoice exception handling, in eight to twenty steps. A level three map details one step, such as how the clerk investigates a price mismatch, and is useful when that step is where your AI assistant will work.

Map the current state (as is) first. Draw the future state (to be) only after the client agrees the current state is right. The future state should show exactly which steps change, which disappear, and where a human still reviews AI output.

Reviewing the map with the client

Walk the map with the people who do the work, not only managers. Ask 'What is missing?' and 'Where does this usually go wrong?' rather than 'Is this right?'. Mark every disputed step and resolve it with evidence. Keep a version date on the map. Tools can be as simple as paper and sticky notes, or any free diagram tool; what matters is that the lanes and handoffs are clear.

A good test of a finished map: someone new to the process should be able to point at any step and say who does it, in which system, what triggers it and what happens next. If they cannot, the map needs another pass.

From map to solution design

Once the current state is agreed, the map becomes a design tool. Mark each step with its pain from your evidence: long waits, high touch time, frequent errors. Then ask, for each marked step, whether it can be removed, simplified, or supported by a tool. Removing a step beats automating it. Many approval loops exist only because information is missing when the request is made, so sending the right information up front can remove the loop entirely.

Where an AI assistant helps, draw it as its own lane in the future-state map, and show the human review step right after it. That makes it obvious to the client who decides, which matters for trust, audit and the acceptance criteria you will write next.

The short version

A stakeholder is anyone who affects or is affected by your work. RACI is a simple table that lists tasks or decisions down the side and people or roles across the top. Each cell holds one letter: R for Responsible (does the work), A for Accountable (owns the outcome and signs off), C for Consulted (gives input before the decision, two-way), and I for Informed (told after, one-way).

The most important rule: exactly one A per row. If two people are accountable, nobody is. If nobody is, the decision will drift.

The usual stakeholders on an FDE engagement

• Executive sponsor: funds the work, sets the goal, removes blockers. Cares about outcomes and risk.
• Process owner: the manager responsible for how the process runs day to day, such as the AP manager. Decides what changes in the process. Your most important ally.
• Users: the people who will use the solution, such as AP clerks. They know the real process and decide, in practice, whether it gets used.
• IT and data owners: control access to systems, environments and data exports. Will support whatever is left behind.
• Security: reviews data flows, vendors such as LLM providers, access and logging.
• Compliance, legal and privacy: check regulatory rules, contracts, personal data and record retention.
• Others who touch the process: buyers, suppliers, internal audit, works councils or unions in some countries.

Finding and ranking stakeholders

Start with the process map: every lane is a stakeholder group. Add the people who own each system the process touches. Then ask in every interview 'Who else should I talk to?' and 'Who could stop this?'.

A power and interest grid helps you plan effort. High power and high interest (sponsor, process owner): manage closely, meet often. High power, lower interest (security, IT leadership): keep satisfied, involve at clear checkpoints. Lower power, high interest (users): keep informed and involve in design. Lower power and lower interest: inform occasionally.

Positions on the grid change during an engagement. Security may have low interest until you propose sending data to an outside API, and then become the most important approver, so review the grid every couple of weeks.

Building the RACI

List the real tasks and decisions of your engagement, not generic ones: approve scope, grant data access, approve the LLM vendor, build the proof of concept, define acceptance criteria, run user testing, approve go-live, own support after handover. Put roles across the top using names where possible. Fill it as a draft, then review it with the sponsor and process owner and change it until they agree.

Check each column too. A person with many Rs may be a bottleneck. A person with no letters may be someone you have forgotten. Too many Cs slows everything down, so consult only those whose input genuinely changes the decision.

Using it during the work

Put the RACI in the project folder and refer to it when a question comes up: 'Per the RACI, the process owner signs off acceptance criteria.' Update it when roles change, such as when a new IT contact joins. At handover the RACI changes: the FDE drops out of R and the client team takes over support, so draw a handover version too.

When a disagreement comes up that the RACI does not cover, add a row, agree the A, and move on. The table is a living tool, not a one-time deliverable, and keeping it current takes minutes.

Meeting security and compliance early

Security and compliance teams are often the slowest approvals, and they are much easier to work with when they hear about the work at the start rather than the week before a pilot. In the first two weeks, send them a short note: what the proof of concept does, which data it reads, where that data goes (for example to an LLM provider's API), who can see the results, and how long anything is kept. Ask what their review process is and how long it usually takes.

Treat their questions as design input. If they require that no personal data leaves the company, you may need to mask fields before sending them to a model. If they require logs of every AI suggestion, build that in from the first version. Finding these rules in week one costs a day; finding them in week eight can cost the pilot.

The short version

A one-page brief states the problem, who has it, how it works today, what will change, how success is measured, what is in and out of scope, and what constraints apply. User stories describe what each user needs in their own terms. Acceptance criteria are the specific, testable conditions that must be true for a story to count as done.

Write the brief at the end of discovery, review it with the process owner and sponsor, and get explicit sign-off before you build. Revisit it whenever the scope is challenged.

The template, field by field

• Title: short and plain, naming the process and the change.
• Problem: two or three sentences in the user's words, based on evidence.
• Who is affected: user groups and rough numbers of people.
• Current process and baseline: the key steps and today's measured numbers, such as volume, touch time, elapsed time, error rate, with sources.
• Goal and success metrics: the target change in those numbers, plus any quality threshold the AI output must meet.
• In scope: what the proof of concept will do.
• Out of scope: what it will not do, stated explicitly so nobody assumes it.
• User stories: three to six, each with acceptance criteria.
• Data and systems: what it reads, what it writes, and access needed.
• Constraints: security, privacy, compliance, human review rules, budget, timeline.
• Risks and assumptions: what could make it fail and what you are taking as true.
• Owners and sign-off: sponsor, process owner, and the date agreed.

User stories

A user story has the form: As a (role), I want (capability), so that (benefit). The benefit part matters most because it explains why, which lets the team find better ways to meet the need. Write stories from evidence: each should trace back to a pain you heard or saw.

Good stories are small enough to build and test in days, and independent enough to deliver one at a time. The INVEST checklist is a common test: Independent, Negotiable, Valuable, Estimable, Small, Testable.

Acceptance criteria

Acceptance criteria turn a story into checks. A common format is Given (a starting situation), When (an action or event), Then (an observable result). Another is a plain checklist of rules. Both must be specific enough that two people would agree whether they pass.

For AI features, add criteria about quality across a set of cases, not just one: for example 'On the 50-case evaluation set, the stated cause matches the AP lead's judgement in at least 45 cases.' Also add safety criteria: what the system must never do, such as approving a payment by itself, and what it should do when unsure, such as saying it cannot tell and showing the evidence it found.

Writing criteria for AI behaviour

AI features need three kinds of criteria that ordinary software often does not. Quality on a set: measured over a fixed set of real, representative cases, ideally labelled by the process owner's team, so you can rerun it after every change. Behaviour when unsure: what the system says when evidence is missing or conflicting, such as stating that it cannot tell and showing what it found. Boundaries: actions it must never take on its own, such as approving, paying or emailing a supplier.

Agree how the evaluation set is built before you build the solution. If the team picks the cases after seeing results, the test is no longer fair. A simple rule works: take every case from a chosen recent week, remove ones out of scope, and keep the rest, including the messy ones.

Getting sign-off

Send the brief in advance, then walk it through in a 30-minute meeting with the process owner and sponsor. Read the out-of-scope list out loud; it prevents more arguments than anything else on the page. Record the agreed version with a date. If something changes later, change the brief and get it agreed again rather than letting scope drift by email.

Sign-off does not need ceremony. A short email reply saying 'Agreed' from the process owner and sponsor, saved in the project folder with the brief, is enough. What matters is that the agreed version is clear and easy to find when someone asks later what was promised.

The short version

Change management is the work of helping people move from the current way of working to a new one. ADKAR is a model from Prosci that breaks individual change into five stages: Awareness of the need to change, Desire to take part, Knowledge of how to change, Ability to do it in practice, and Reinforcement so the change sticks. If someone is stuck, find the first stage they have not reached and work on that.

For an FDE, the most important person is the process owner. If they see the solution as theirs, their team will follow. If they see it as something done to them, it will quietly fade.

Why people resist

Resistance is usually a reasonable response, not stubbornness, and it tells you which part of the change is missing. Listen for the reason behind it before trying to answer it. Common reasons:

• Fear for their job or status, especially with AI. People whose expertise is knowing where things are may feel that is being taken away.
• Extra work during the transition: learning a tool while still clearing the normal queue.
• Past tools that were promised and failed, so they wait to see if this one lasts.
• Unclear benefit to them personally, as opposed to the company.
• Lack of trust in AI output, especially after one visible mistake.
• Not being asked: the tool was designed without them and misses their real exceptions.

ADKAR applied to an FDE engagement

• Awareness: share the baseline numbers and pain from discovery with the team, so the reason for change is their reality, not a slogan.
• Desire: show what is in it for them, such as fewer chasing emails or leaving on time at month end. Be honest about job impact; if the sponsor has said there are no cuts, say so clearly.
• Knowledge: short, hands-on training on their own cases, plus a one-page guide covering when to trust the output and when to check.
• Ability: a pilot period with you available, a simple way to report problems, and time freed to practise.
• Reinforcement: share results, fix reported issues quickly, recognise champions, and have the process owner build use into the standard procedure.

Bringing the process owner along

Involve the process owner from the first week. Ask them to choose who you interview and shadow. Review the process map and brief with them before anyone else. Let them name the exceptions that matter and approve the acceptance criteria; they are accountable for those in the RACI.

Show early, rough versions on real cases, and let their team break it. Each problem they find and you fix builds trust. Agree with them how adoption will be measured, such as the share of exceptions where the assistant's draft was used, and review it together weekly during the pilot.

If the process owner is too busy to engage, treat that as a risk to raise with the sponsor early, not something to work around. A solution built without its owner rarely survives the FDE leaving.

Signs adoption is working or failing

Working: usage grows week by week without reminders; users ask for new features; the team starts describing exceptions in the tool's terms; the process owner presents results themselves. Failing: usage spikes after training then falls; people use the tool only when you are in the room; workarounds such as the old spreadsheet stay in use; feedback stops. When you see failing signs, go back to ADKAR and ask which stage is missing, then talk to two users about their last real case with the tool.

Designing for adoption in the build

Adoption is partly a design problem. Put the assistant where people already work, such as inside the ERP screen or the ticket view, rather than in a new window they must remember to open. Show the evidence behind each suggestion, so users can check it in seconds and build trust. Make it easy to correct the output and capture those corrections, since they become your best source of improvement and show users their input matters.

Keep the first version narrow and reliable. One task done well on most cases earns more trust than five tasks done unevenly. Add scope only after usage and quality are stable.