Workflow Discovery Script

Follow the Work, Not the Process Description

A customer may explain a workflow in one polished sentence: a request arrives, the team handles it, a manager approves it, and the result goes out. A product cannot be scoped from that sentence. The work lives in the missing verbs—copying, waiting, checking, asking, correcting, reconciling, and deciding whether an exception is safe.

Use this script after a problem interview has found a recurring painful situation and before choosing an MVP slice. Its job is to reconstruct one occurrence closely enough that the first product becomes smaller. If the customer cannot recall a recent occurrence, do not fill the silence with a hypothetical process. Find another interviewee or treat what follows as a hypothesis to verify.

Bring a blank workflow pain map and one commercial or product assumption the conversation could overturn. You might be wrong about where the pain concentrates, which input is available, who must trust the output, or whether the useful step can be reached without an integration.

Ask Permission Before Asking to See

Observation can reveal what memory smooths over, but a useful screen share is not permission to inspect confidential records. Agree on the boundary first:

I would like to reconstruct one recent instance from the event that started the
work to the result that counted as finished. I am interested in the actual
sequence, including manual steps and exceptions. If it is safe, you can show
an empty template or the shape of an artifact, but please do not reveal
customer, employee, financial, health, or other confidential data.

Ask whether you may take notes and how those notes may be used. If the customer needs to conceal names, values, or records, record the existence and function of the data rather than the data itself. A description of the fields in a file is often enough to expose a handoff.

Give the Episode a Beginning and an End

Start with the most recent occurrence the customer can replay, not the most dramatic story they can remember.

What is the last time this happened?
What arrived or changed that started the work?
Who noticed it first?
How did you know the work was finally done?
Who used, approved, or received the result?

Write the trigger and finished result at opposite ends of the page. If “done” means different things to the person doing the work, the approver, and the recipient, keep all three. That disagreement may be part of the problem.

Move One Action at a Time

Now return to the trigger and ask the question that carries most of the interview: What happened next? Record each answer as an actor doing an action in a tool or channel, using an input and producing an output.

When the customer skips from one stage to another, slow the sequence down:

What did you open or look at before you could do that?
Where did that information come from?
What did you copy, change, or add?
Who received the result, and how?
What were they waiting for before they could act?
What came back when the work was incomplete or wrong?

Follow responsibility and data separately. A person can hand off the decision while still moving the file. A spreadsheet can remain with one person while its rows travel through email, chat, and an official system. Name the side channel, saved message, private checklist, or experienced colleague’s memory. Hidden work often carries the state or judgment that the official process has lost.

Do not ask for every possible exception while the main trace is still vague. Finish the occurrence first. Then ask what made this instance ordinary or unusual and which branch recurs often enough to change the product.

Stop Where the Work Resists

When the customer says that a step was slow, awkward, manual, or frustrating, do not immediately label it the opportunity. Ask what the resistance caused.

How long did the work wait there, and what was waiting on it?
What had to be done again?
What error or ambiguity were you trying to prevent?
Who noticed the consequence?
What did you do to recover?
What does the workaround protect that a cleaner process might lose?

A manual review may be waste, or it may stop an unsupported client message. A flexible spreadsheet may be clumsy, or it may absorb exceptions that change every week. The workaround reveals both an opportunity and an obligation: a first product must preserve whatever useful control, context, or adaptability keeps the work safe.

Trust points deserve a second pass. Wherever the episode could move money, change a schedule, contact a customer, alter an official record, expose sensitive data, or create an irreversible action, ask:

Who is allowed to make this decision?
What do they need to see before they trust it?
How do they correct, reverse, or refuse the result?
What happens when the source is missing, late, duplicated, or contradictory?

These answers determine whether the first product may act, should draft, must show sources, needs approval, or should refuse.

Let One Trace Change the Product

Suppose a founder is studying weekly client updates at a field-service company. The operations manager first describes the workflow as “export the jobs, write the report, and send it.” A closer trace reveals that three technicians left outcomes blank, one recorded status contradicts a work order, and the manager spends Friday morning chasing replies. A service manager then removes an unsupported promise before the report goes to the client.

The export is an obvious integration target, but it is not where the value lives. The painful cluster is turning incomplete close-out notes into an update the company is willing to send under its name. The saved messages, follow-up calls, and final review are not debris around the workflow; they are how the company restores missing evidence and protects customer trust.

That trace suggests a narrower first test: accept an export, flag missing or contradictory outcomes, and produce a source-linked draft for review. Technician follow-up, resolution of ambiguous notes, approval, and external sending remain human. The founder can test whether the draft saves review time and catches the right omissions before promising a scheduling integration or automated communication.

Test the Boundary, Not a Feature List

At the end of the trace, ask the customer to identify the moment whose improvement would be visible. Then describe one bounded intervention using nouns the episode supplied:

It sounds as though the difficult moment is [actor] trying to [specific step]
when [evidence from the episode]. If a first version used [available input] to
produce [useful output], while [judgment or exception] stayed with [person] and
[excluded system or action] remained outside the product, would that improve
this occurrence? Where would it fail?

Do not defend the boundary. A customer who rejects it precisely may reveal that you chose the wrong actor, input, output, or value moment. Ask what would have to be true for the result to help, what proof the user or approver would require, and which part of the workflow the customer would refuse to change.

An integration request is still a question at this stage. Find the exact object, fields, format, event, cadence, permission, and failure behavior before turning “connect to our system” into scope. An upload, forwarded message, or manual service may answer the first value question with far less permanent surface area.

Leave With a Decision, Not a Beautiful Map

At the bottom of the page, write:

• the recent episode and any evidence you could not observe;
• the step where pain concentrates and the consequence it creates;
• the actor, available input, useful output, and person who must trust it;
• the workaround or judgment that should remain manual while you learn;
• the systems, actions, users, and promises the first version excludes;
• the next unknown that needs another interview or a bounded test.

Then write the slice in one sentence:

The first version helps [actor] turn [available input] into [useful output] so that [observable value], while [manual judgment] remains with [person] and [excluded workflow] stays outside the product.

Move to scope or pilot design only when every noun in that sentence comes from the episode rather than the founder’s product idea. Return to discovery when the map still contains “they process it,” every step seems equally painful, the required input is inaccessible, or value depends on owning most of the workflow.

The conversation has done its job when it makes the proposed product smaller for reasons the customer recognizes—and leaves the founder with one consequential uncertainty to test next.