Complaint to Hypothesis

Use this skill when the user has complaints, feature requests, Support tickets, CRM notes, or customer success notes about a workflow and wants to know what is actually wrong before anyone builds a fix.

This skill is Labor as Code™ for the complaint method in You Are Not the User. Labor as Code is a skill that encapsulates a person's knowledge, judgment, taste, and skill in durable, inspectable, versioned form. The know-how is the discipline of believing a user's pain completely while treating the user's diagnosis as one hypothesis among several.

The method is taught in "Watch Users Work to Find What Causes Their Complaints," which introduces the Complaint-to-Hypothesis Converter, the Observation-to-Hypothesis Prompt (full text in the online companion's prompt library, intellectualfrontiers.com), the User Observation Guide, and the "Show Me, Don't Tell Me" Interview Guide. Read it for the full argument and the Caseline worklist example, where "too slow and too many clicks" split into a performance problem and a missing ranking, and neither fix was fewer clicks. This skill applies the same order of work to the user's own complaints. It does not retell the example.

A complaint is an observation, in the sense Zero-Bureaucracy Product and Project Management uses the word. It proves that someone felt enough pain to report it, in a particular place, for a particular role, at a particular time. It does not prove cause. A request is a complaint with a solution attached, and gets the same treatment.

This skill cannot observe users. Observation is a human act. The skill can plan an observation, and it can sort notes a person wrote while watching. It cannot watch, and it never labels its own reading of tickets or interview transcripts as Level 4, observed user research. A skill that does that has become a stand-in for the user. For the causes that only watching can separate, the skill's output is a plan for a human to run.

Before running

1. Get the raw text. Ask for the complaints, tickets, and notes in the user's own words, not a summary. A summary has already chosen a cause. Ask the user to remove patient, customer, and personal data first.
2. Get the denominator. Ask how often the workflow is used, by which roles, and at which customers or sites. A complaint count means little until it is divided by use. If the user has no usage count, record "unknown" and carry it forward as a gap.
3. Scope to one workflow. Complaints about several workflows at once produce a mixed table. Pick one, or run the skill once per workflow.

The rules this skill follows

These are the Observation-to-Hypothesis Prompt's rules. They hold for every step below.

• Use only the observations the user supplied.
• Do not invent requirements, users, quotes, or numbers.
• Quote each observation exactly. Do not paraphrase a quote.
• Treat a complaint as proof of pain, not proof of cause.
• Treat a request as an observation, not a requirement.
• Write "not stated" when the input does not state a fact.
• Do not write requirements, user stories, or feature proposals.

The prompt also says "do not recommend a solution" and "do not rank the groups by priority." This skill keeps both rules through Step 5. Step 6 recommends which cause to test first. It still recommends no fix, because no fix is justified until a test picks the cause.

Step 1: Record and label the observations

1. Number each observation.
2. Record its source, the user role, the customer or site, and the date. Write "not stated" for any field the input lacks.
3. Give each observation one User Evidence Ladder level: 0 Opinion, 1 Anecdote, 2 Repeated independent reports, 3 Behavioral evidence, 4 Observed user research, 5 Validated intervention.
4. Give the reason for each label in one sentence.

A pile of tickets and CRM notes almost never reaches Level 4 or 5, because nobody watched anything. A single ticket is Level 1. Several tickets reach Level 2 only when they come from independent sources. Count distinct customers, not tickets.

Step 2: Group the pain and state what it proves

1. Group the observations that describe the same pain.
2. Quote two observations from each group word for word.
3. Count the observations and the distinct customers in each group.
4. For each group, state the pain: what hurts, for which role, and how often. Write "unknown" for each part the input does not show.
5. Where the user gave a denominator, state the complaint rate against use. Note whether the rate climbs with customer size or stays flat. Size-linked pain suggests the software strains under volume. Flat pain suggests the design itself.
6. Note the timing. Pain gets reported when it is worst. A complaint filed during the busiest hour of the month may describe a cause that is absent the rest of the time.

Step 3: List at least three candidate causes per group

1. Write at least three candidate causes for each group.
2. Include the cause the users named, if they named one.
3. Make each cause a different mechanism. Three wordings of one cause count as one cause.
4. Delete any "cause" that is a feature request in disguise. "Needs a bulk-approve button" is a fix, not a cause.

For a complaint about clicks or slowness, the book's own list of candidates is a useful starting set: latency, repetitive navigation, information hierarchy, interruption recovery, terminology, and remembering across screens. Use it to prompt thinking. Keep only the causes the observations make plausible, and say why each one stays on the list.

Step 4: Name the distinguishing evidence and the smallest test

Fill in the converter, one entry per group:

Then write one hypothesis per candidate cause, in the prompt's form:

We believe [cause] makes [user role] experience [pain].
We will know we are right if [observable result].

For each smallest test, record who would run it and what it costs. The book's rule: a smallest test with no owner does not get run. Ask the user to name an owner and a date. Do not assign one.

Step 5: Plan observation for the causes only watching can separate

Sort the candidate causes into two sets.

• Causes a count can separate. Latency, error rates, round trips, exports, and abandonment show up in logs or telemetry. The test is a query or a new event, run by the team.
• Causes only watching can separate. Information hierarchy, work done outside the product, memory load, interruption recovery, and mismatched terms rarely show up in logs. A person must watch.

For the second set, write an observation plan using the User Observation Guide. Plan it for a human to run.

1. Name a real task and a real shift. Do not use a demo slot.
2. Name who must give consent: the person watched, and whoever governs their workplace.
3. Tell the observer to watch before asking anything.
4. List what to record: what the person does, where they hesitate, what they leave the product to do, what they must remember, where they are interrupted, and what they have built for themselves (spreadsheets, sticky notes, printouts, workarounds).
5. Tell the observer to stay silent while the person works, including during a hesitation. Ask afterward.
6. Plan more than one person, at more than one site. One observation shows one way the work can be done. Several show which parts are the work and which parts are that person.
7. Tell the observer to record what their presence may have changed, and to ask at the end what was different about today.

Then write the "Show Me, Don't Tell Me" questions for the interview after the session, or for use when live watching is not possible:

1. Sit at the user's own screen, in their own setting.
2. Ask the user to show the last time they did the task. Do not ask how they usually do it.
3. Follow the artifact. Open the file, report, or note they used, and ask what each part is for.
4. Ask about specifics that already happened. Do not ask for opinions about features that might exist.
5. Do not demonstrate the product.

Write each question so it points at a specific artifact or a specific past instance: "Show me yesterday's list. Why is this row above that one?" Remove any question that asks for a prediction ("Would you use a feature that...?"). Predictions and compliments are Level 0.

State plainly in the plan that its results become Level 4 only after a person has run it and written the notes. If the user later brings those notes back, the skill can sort them into what the person did and what the person said, flag any statement the actions contradict, and relabel the causes. It still does not change a word of the notes.

Step 6: Conclude with which cause to test first

Close with a stated recommendation and its reasoning. Rank the tests, not the fixes.

1. Name the cause to test first. Choose on three grounds, in this order: which cause the current evidence makes most plausible, which test is cheapest and fastest to run, and which result would change the most decisions. A cheap log query that can rule out latency in a day often goes first even when latency is not the favorite, because it clears the field for the observation mornings.
2. Give the reasoning. Cite the specific observations, counts, and gaps that support the choice.
3. Say what each result would mean. For the first test, state which causes a positive result keeps and which a negative result rules out.
4. Name the observation plan's place in the sequence. If watching is the only way to separate the leading causes, say so, and put the observation plan first.
5. Draft the answer back to the complainers. Write two or three plain sentences a customer-facing person could say: what the team believes, what it is checking, and what it is asking the users for next. Taking a complaint seriously means telling people their pain was believed.

Where the evidence cannot rank the causes (for example, a dozen tickets from one site with no usage count and no dates), say so directly. Do not pick one cause to sound useful. Name what would let the causes be ranked: a denominator, a count of distinct customers, a week of a specific event, or one observation morning. Where two causes are equally supported and their tests cost the same, present both side by side, each with its reasoning and the result that would favor it.

Checks before calling the work done

• Every quote appears in a real observation. Search for three.
• No number appears that the user did not supply. Delete any that does.
• Every group has at least three distinct causes, and one of them is the cause the users named, if they named one.
• No hypothesis is a feature request in disguise.
• No Level 4 label came from the skill's own reading.
• Every smallest test has an owner and a date from the user, or is marked "no owner yet."

What this skill does not do

This skill does not decide what to build. It turns complaints into tests and says which test to run first. It does not treat a user's diagnosis as wrong, either. The user's pain is taken at full value, and their named cause stays on the list until evidence rules it out. It does not watch the work; it plans the watching and hands the plan to a person. When the input is too thin to rank causes, the correct output is "the evidence can't rank these yet, and here is what would," not a confident diagnosis invented from ticket text.