---
name: complaint-to-hypothesis
description: 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. It runs the Complaint-to-Hypothesis Converter under the Observation-to-Hypothesis Prompt's rules, then writes an observation plan for the causes only watching can separate, and closes with which cause to test first. Triggers on requests like "users say it has too many clicks, what do we fix," "convert these tickets into hypotheses," "what's the real cause behind these complaints," "should we build what the customer asked for," "plan an observation session," or "run the complaint converter."
---

# Complaint to Hypothesis
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:

| Column | What goes in it |
| --- | --- |
| Complaint, verbatim | The exact words of a representative observation |
| Pain it proves | What hurts, for whom, how often |
| Candidate causes | At least three different mechanisms |
| Evidence that would distinguish them | What each cause would look like in the evidence, so a test that comes back without that result rules it out |
| Smallest test | The cheapest test that would produce that evidence |

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.