Workflow Pain Map

Map One Occurrence, Not the Official Process

A workflow map begins with something that happened. A request arrived, a deadline approached, an exception appeared, or a customer needed an answer. People then moved information, waited, improvised, checked, corrected, approved, and eventually produced an outcome.

That sequence is more useful than a description of how the work normally goes. “The coordinator reviews the jobs and sends the weekly report” conceals the missing notes, copied data, private checklist, approval, and Friday chase that determine both the pain and the product surface.

Use this map after a problem interview has found a recurring situation and before choosing MVP scope. It is also useful when a feature request seems important but nobody can place it inside a recent episode. If the customer cannot recall or safely show an occurrence, label the map as a hypothesis and use it to plan the next conversation. Do not treat it as product evidence.

Set the Boundary of the Page

At the top of a blank page, record:

• Customer and episode: who did the work, and which recent occurrence you are reconstructing.
• Trigger: the event, request, deadline, alert, file, or exception that started it.
• Finished means: the observable output or decision that ended the work for the customer.
• Source: interview, observation, screen share, support story, or shared artifact.
• Evidence limits: what you could not observe, what rests on memory, and what sensitive material was deliberately excluded.

Keep the episode narrow enough to trace. “Month-end reporting” may contain several workflows. “Preparing last Friday’s account update after technicians closed their jobs” has a beginning, an end, and evidence that can be inspected.

Bring notes and any screenshots, empty templates, exports, messages, or documents the customer is allowed to share. Record the unofficial tools too: the side spreadsheet, inbox label, saved message, personal checklist, or experienced employee’s memory may be carrying the process.

Trace the Work in Time

Write one line for each action in the order it occurred:

[Actor] does [action] in [tool or channel], using [input], and produces [output].

The output of one line should usually become the input, permission, or reason for the next. If it does not, find the missing step. “Operations exports completed jobs” followed by “the client receives a report” hides the work the product would have to understand.

Annotate the sequence only where the episode supplies evidence:

• Handoff when responsibility changes.
• Wait when progress stops for time, information, or authority.
• Data move when someone copies, exports, reformats, reconciles, or re-enters information.
• Rework when a later step sends work backward.
• Exception when the ordinary path branches.
• Trust when a person needs sources, review, approval, reversibility, or confidence before acting.
• Consequence when delay or error costs time, money, reputation, customer confidence, compliance, or opportunity.

Use the customer’s verbs before applying a category. “Chased three technicians for missing close-out reasons and delayed the client call” teaches more than marking a cell “coordination: high.” A category can help you scan several maps later; it should not erase what resisted in this occurrence.

Do not add a product opportunity beside every step. First make the workflow true. Premature solution notes turn observation into a feature inventory.

A Worked Map: The Friday Account Update

Consider the modeled field-service company from the ICP one-pager: a twenty-person maintenance business promises clients a weekly update, and its operations manager assembles that update from technician close-out notes.

The first version of the map might look tidy:

Jobs completed -> notes exported -> report written -> report sent

Reconstructing one Friday exposes the actual work:

Thursday 16:00: scheduling system marks the week's visits complete
  -> operations manager exports close-out notes to a spreadsheet [data move]
  -> manager finds three blank outcomes and two unexplained return visits [exception]
  -> manager messages the technicians and waits for replies [handoff, wait]
  -> one reply contradicts the status recorded in the scheduling system [trust]
  -> manager checks the work order and calls the site lead [rework]
  -> manager groups the usable notes by client and rewrites internal language
     as a customer update [manual judgment]
  -> service manager checks promised follow-ups and removes an unsupported claim
     [approval, trust]
  -> operations manager sends the approved update before the client call

The export takes minutes. The episode becomes painful when incomplete and inconsistent close-out notes must be turned into a report another person is willing to send under the company’s name. Delay threatens a client commitment; a polished but unsupported sentence threatens trust. Those consequences are different, even though both occur in the same cluster.

The current workaround also explains why the workflow survives. The operations manager knows which technician language needs translation, which missing detail can wait, and which promise must be checked with the service manager. Automating the spreadsheet export while ignoring that judgment would solve the cleanest step and leave the painful one intact.

Read the Map for a Pain Cluster

After the sequence is honest, circle the place where several marks gather. Test the cluster with four questions.

What repeats? Record how often the situation and the troublesome step occur. A severe annual exception may deserve a service or control, but it may not sustain a product. Frequent work is not sufficient either; copying a harmless value once a day can be less consequential than a weekly approval that holds up payment.

What consequence reaches beyond annoyance? Name what becomes late, risky, expensive, embarrassing, or impossible. Ask who experiences that consequence. The person doing the manual work, the person approving it, the buyer, and the recipient of the final output may have different definitions of pain.

What does the workaround protect? A manual review may be waste, or it may be the control preventing a false payment or an unsupported client message. A spreadsheet may be clumsy, or it may remain adaptable because the exceptions change every week. Before removing a step, identify the local knowledge, visibility, accountability, or flexibility it supplies.

Can the founder reach value without owning the whole workflow? Identify an input the first product can actually obtain, an output the customer would recognize as useful, and a trust standard that can be met without a large integration, implementation, or support burden.

If every step appears equally painful, the episode is still too broad or the map is filled with impressions rather than consequences. Narrow it and reconstruct again.

Choose a First Value Moment

The product boundary belongs after the map. Complete these statements:

• Pain cluster: At [step], [actor] repeatedly [workaround], which causes or risks [consequence].
• First value: The customer can see improvement when [observable outcome].
• Available input: The first version can receive [specific file, message, record, or action] without pretending an unproven integration already exists.
• Trust condition: Before the output is used, [person] needs [source visibility, review, approval, correction, reversal, or refusal behavior].
• Manual learning boundary: [exception, classification, cleanup, or judgment] remains manual while its pattern is still being learned.
• Excluded workflow: The first version will not own [systems, roles, decisions, or downstream actions].

Then write the proposed slice in one sentence:

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

For the modeled account update:

The first version helps the operations manager turn an exported set of close-out notes into a source-linked draft that flags missing outcomes, so the service manager can review the weekly client update without reconstructing every visit, while ambiguous notes and promised follow-ups remain human decisions and external sending stays outside the product.

This boundary does not yet prove demand. It gives the founder a serious thing to test. A manual draft service or a narrow upload workflow could reveal whether review time falls, whether the flags catch the right omissions, and whether managers trust the result. Automatic client sending, technician messaging, scheduling-system replacement, and silent resolution of contradictions would answer different and riskier questions.

Know When the Map Is Ready

Use the map to guide MVP work only when another person can follow one recent episode from trigger to finished output without relying on phrases such as “then they process it.” The map should identify:

• the highest-pain step and the observable consequence;
• the workaround customers use today and the useful constraint it preserves;
• the actor who feels the pain and the person who must trust the result;
• the input a first version can obtain and the output that creates first value;
• the exception or judgment that should remain manual;
• the systems, actions, and promises the first product must not attempt.

Return to discovery when actors, inputs, outputs, edge cases, or trust points remain guesses. Also return when the proposed value requires broad integrations, several organizational approvals, or high-stakes correctness before the customer can experience any benefit.

The map has done its job when it makes the first product smaller for reasons visible in the customer’s work. Its next companion, the alternative-to-MVP translation sheet, asks whether that smaller intervention is meaningfully better than the workaround it would replace.