User Evidence Ladder Labeler

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.

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:

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)."

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.