---
name: evidence-ladder-labeler
description: A skill for product managers and their teams that grades every claim about users in a PRD, roadmap, ticket thread or other product document with a User Evidence Ladder level, and states which decision the evidence can carry now. Use this skill when the user wants every claim about users in a product document graded before anyone argues about it. Inputs include a PRD, requirements document, roadmap proposal, set of user stories, ticket thread, CRM notes, UAT sign-off, or meeting notes. The skill labels each claim with a User Evidence Ladder level, gives any test result a UAT Distance, writes a Simulated User Disclosure for any D2–D4 test, drafts a Product Evidence Brief for the main proposal, and states which decision the evidence can carry now. Triggers on requests like "label the evidence in this PRD," "what level is this claim," "is this real UAT," "write the Simulated User Disclosure," "draft the Product Evidence Brief," or "how strong is the case for this feature."
---

# User Evidence Ladder Labeler
This skill is Labor as Code™ for the labeling 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 a product
manager's habit of asking "what level is that?" of every sentence about
users, and of writing the answer down where the next reader can see it.

The method comes from three chapters. "Label the Evidence Before You
Argue About It" teaches the User Evidence Ladder and the Product Evidence
Brief. "“We Tested It” Means Almost Nothing" teaches the UAT Distance
Scale and the Simulated User Disclosure. "Instrument Before Arguing"
explains why Level 3 is usually the missing rung. Read them for the full
argument and the Caseline worked examples. This skill generalizes those
examples into a repeatable pass over the user's own document. It does
not retell them.

The skill grades what a document says. It never raises a label because
a claim sounds confident, because a senior person made it, or because
it has been repeated in several formats. It never invents evidence,
users, quotes, requirements, or numbers to fill a gap. A gap is a
finding, and the skill reports it as one.

**This skill cannot observe users.** Observation is a human act: a
person sits beside someone doing real work and records what they do.
The skill can read notes that a named person wrote while watching, and
it can label those notes Level 4. It cannot produce Level 4 evidence
itself. A skill that reads interview transcripts or ticket text and
calls the result "observed user research" has become a stand-in for
the user, which is the failure the book exists to name.

## Before running

Confirm these points with the user before the first label:

1. **Which document, and which decision.** Get the actual text, not a
   summary. Ask what decision the document is meant to support: a
   discovery effort, a prototype, a pilot, a general release. The
   labels mean little until the skill knows what they have to carry.
2. **What evidence exists outside the document.** Telemetry, counted
   tickets, observation notes, and pilot results often exist but are
   not cited. Ask for them. Label only what the user supplies. Do not
   assume a dashboard exists because someone said "the data shows."
3. **Who the testers were, if a test is cited.** The skill cannot tell a
   former nurse from a working one, or a customer success manager from
   a customer. Ask the user for each tester's current job. Where the
   user does not know, mark the distance "not in the records."

## Step 1: Find every claim about users

1. Read the whole document once before you label anything.
2. Quote every sentence that makes a claim about users. Quote it
   exactly.
3. Include claims in disguise: user stories, "customers are asking,"
   "the market wants," "users will love," "we tested it," and any
   sentence that starts "the user wants."
4. Record the user role each claim names. If it names no role, write
   "no role named." Use the Five Names from "Customer-Facing Teams Rarely See the People Who Use the Software" (buyer, customer, administrator, user, affected party).
5. Record the source the document gives for each claim. If it gives
   none, write "no source stated."

A request for proposal (RFP) line, a buyer's purchase requirement, or a
QA pass is not evidence about users at any level. Record it, name what
it is ("buyer requirement," "evidence that the build meets its
specification"), and do not place it on the ladder.

## Step 2: Assign a User Evidence Ladder level

Use the six levels and their exact names:

| Level | Name | What the evidence is |
| --- | --- | --- |
| 0 | Opinion | A judgment, however expert. |
| 1 | Anecdote | One user, one conversation. |
| 2 | Repeated independent reports | The same need from separate sources. |
| 3 | Behavioral evidence (telemetry) | Counted behavior across users. |
| 4 | Observed user research | What real users did while a named person watched. |
| 5 | Validated intervention | A measured change in the real outcome. |

Apply these rules to every claim:

1. Base the level only on the evidence the document or the user states.
2. Grade the evidence, not the speaker. A chief executive's hunch is
   Level 0. A Support agent's count of eleven separate practices is
   Level 2.
3. Count sources, not repetitions. Three people from one practice on
   one call is one report. One customer success manager repeating a
   need in five meetings is one report.
4. Do not raise a level when a claim is restated. An anecdote rewritten
   as a user story is still Level 1.
5. Assign Level 3 only when the document cites counted behavior. "The
   data shows" with no count is Level 0.
6. Assign Level 4 only when a named person watched real work. An
   interview transcript is what someone said, not what someone saw.
7. Assign Level 5 only when a measured outcome changed after an
   intervention, against a stated baseline.
8. Mark a claim "unsupported" when the document states no evidence.
9. Give the reason for each label in one sentence.

Then check for costumes, the book's name for a claim stated in the
language of a higher level than its evidence. Flag each one by name:

- **The plural anecdote.** "Customers are telling us" from one call.
- **The dashboard glance.** "The data shows" with nothing counted.
- **The simulated test.** "We tested it with users" when the testers
  were internal staff.
- **The buyer standing in for the user.** "The market wants this" from
  an RFP.
- **The confident expert.** A domain expert's safety judgment stretched
  into a judgment about daily workflow the expert has not done.

## Step 3: Assign a UAT Distance to every test result

A claim that came from a test carries two labels: its ladder level and
its UAT Distance. Write them in parentheses after the claim, the way an
engineer writes units: "Care managers prefer grouping by reason (Level
4, D1)."

| Distance | Who performs it |
| --- | --- |
| D0 | A real user doing real work, in the real setting, with real volume, data, interruptions, and exceptions (a production pilot) |
| D1 | A representative user doing realistic tasks in a controlled setting |
| D2 | A subject-matter expert familiar with the work but not doing it now |
| D3 | A customer-facing employee simulating the user |
| D4 | Product, Engineering, QA, or other internal staff simulating the user |

1. Assign a distance to each tester, not to the test as a whole.
2. Do not assign D0 or D1 unless the records show the tester does the
   job now.
3. Record any test at D2, D3, or D4 as simulated UAT. Replace "UAT:
   passed" with "simulated UAT: passed."
4. Label an internal sign-off from a scripted walk-through as Level 0,
   informed opinion, whatever the distance. Capable testers still give
   an opinion when none of them does the job.

## Step 4: Write a Simulated User Disclosure for every D2–D4 result

Fill in every field. Where the records are silent, write "not in the
records." Do not guess.

```
SIMULATED USER DISCLOSURE: [test name, date]
Who simulated which role:           ____
UAT Distance (per tester):          ____
What they know that the user wouldn't: ____
What the user knows that they don't:   ____
Conditions absent (volume, interruptions, real data, exceptions): ____
Decision this result supports:      ____
Decision this result does not support: ____
```

The field "what the user knows that they don't" is the hardest one to
fill from records. Leave it for the human to complete, or better, for a
real user to answer. The skill can list the questions the field
raises. It cannot answer them.

State the narrowest decision the result supports. A simulated result
can support a safety check, a go/no-go on whether a build is ready for
real users, or a small labeled pilot. It cannot support "accepted." The
book's rule: nothing is accepted until a user at D0 or D1 has done the
job with it.

## Step 5: Draft the Product Evidence Brief for the main proposal

Identify the one proposal the document exists to advance. Draft its
brief from the labels above:

```
PRODUCT EVIDENCE BRIEF: [proposal]
Claim about users:                 ____
User role:                         ____
Level and evidence (the evidence itself, not only the number): ____
UAT Distance of tests so far:      ____
Missing evidence:                  ____
What result would change our mind: ____
Smallest test to raise one level:  ____
Decision requested:                ____
```

1. Use the strongest evidence the proposal actually has, and list the
   supporting levels below it.
2. Write "what would change our mind" before any new result exists.
   Ask the user to confirm it. It is the field that stops the goalposts
   from moving later.
3. Name the measurement in the smallest test, so the test can come back
   one level higher instead of as a round of opinions.
4. If the document already requests a decision, copy it exactly. The
   skill compares it to the evidence in Step 6. It does not rewrite it
   quietly.

## Step 6: Conclude with a recommendation

Close with a short statement, not an evidence pack. It has four parts.

**The decision the evidence supports now.** Use the ladder's own
limits: Level 0 is enough to choose what to investigate. Level 1 is
enough to go look. Level 2 shows a need is widespread without saying
what the need is. Level 3 shows what people do at scale, not why.
Level 4 explains why for a few people, which is enough for a bounded
pilot. Only Level 5 supports a rollout. State which decision the
proposal's evidence can carry. If the document requests more, say so
plainly: "This is a Level 1 claim asking for a Level 5 decision."
A Level 0 brief that asks for a small decision ("let two of us watch
three mornings") is legitimate. Say that too, when it applies.

**The weakest claim the decision depends on.** Name the claim whose
failure would sink the proposal and whose level is lowest. Ignore weak
claims the proposal does not need.

**The smallest test that would raise that claim one level.** Be
specific: who, how many, where, what gets measured, and the result that
would count against the proposal. Use the book's moves: count the
uncounted reports to reach Level 2; instrument the workflow to reach
Level 3; watch several people do the real task to reach Level 4; run a
bounded pilot against a named baseline to reach Level 5. Where the
test needs a human observer, say so. The skill cannot run it.

**The reasoning.** Two or three sentences tying the recommendation to
specific labels from the steps above.

If the evidence cannot support any decision beyond "go look," say that,
and name what would change it. Do not round a set of Level 0 and Level
1 claims up to a recommendation to build. If two readings of the
evidence are both defensible (for example, telemetry and a counted set
of reports point at different needs), present both side by side, each
with its reasoning and the test that would settle it.

## Checks before calling the work done

- **Every quote matches the source word for word.** Search for three of
  them.
- **No number appears that the user did not supply.** Delete any that
  does, and treat the rest of the output with suspicion.
- **No label was raised for tone, rank, or repetition.** Re-read each
  Level 2 claim and confirm the sources are independent. Re-read each
  Level 4 claim and confirm a named person watched.
- **Every D2–D4 test has a disclosure,** and no disclosure supports a
  broader decision than its evidence.
- **The recommendation names a decision, a claim, and a test.** A list
  of labels with no stated conclusion is an unfinished run.

## What this skill does not do

This skill does not decide whether to build the proposal. It states
what decision the evidence can carry, and the people who own the
product make the call with that in hand. It does not watch users, and
it does not treat its own reading of a transcript as observation. It
does not supply "what the user knows that they don't" from its own
general knowledge of a job; that answer has to come from a real user.
When the evidence is thin, the correct output is "this is Level 1, and
here is the three-morning test that would raise it," not a confident
case built to fill the silence.