Product research

A compact product teardown: symptom, cost, cause, smallest test

Turn a product complaint into a bounded investigation without presenting an inferred cause or preferred fix as fact.

Field note · Published August 12, 2026 · Written by Alfred

A useful product teardown does not need a dramatic verdict. It needs a disciplined path from what was observed to what should be tested next.

Use four fields: symptom, user cost, possible cause, smallest test. They fit on one card, but they should not be collapsed into one sentence. The separation matters because each field has a different evidence standard.

1. Symptom: record what happened

Write the symptom as an observable event, not an interpretation of intent or competence.

Prefer:

After submitting the form, the same page returned with no confirmation and the entered values were gone.

Avoid:

The team does not care about checkout.

The first statement can be checked against a recording, support report, reproduction attempt, or direct observation. The second invents a motive. Even “the form is broken” can be too broad when the evidence covers one browser, one path, or one moment.

Include the boundary that makes the observation useful:

the task the person was attempting;
the step at which progress changed;
the visible or audible result;
the environment or version, when known;
the source and observation time;
what was not observed.

Do not copy private details into the card. Replace names, addresses, account values, order numbers, and other identifying data with the minimum context needed to reproduce the behavior. If the symptom cannot be described safely without exposing someone, keep the evidence restricted and publish only an aggregate pattern.

2. User cost: state the blocked outcome

The cost is the consequence for the person’s task, not an invented business metric.

Examples include:

progress stopped before account creation;
entered work had to be repeated;
the person could not tell whether payment completed;
an important control could not be reached with the tested input method;
recovery required leaving the current flow.

Separate observed cost from possible cost. “The participant re-entered all six fields” is an observation. “This causes thousands of abandoned orders” requires population and causal evidence that one session does not provide.

A compact card can use two lines:

Observed cost: The task could not continue in the observed session.
Potential wider cost to investigate: Other sessions on the same path may also lose entered data.

That wording preserves urgency without pretending the available sample establishes prevalence. GOV.UK’s service guidance recommends beginning with user needs rather than a preselected solution and warns that a proposed feature is not itself a user need. The operational consequence is simple: describe the outcome people are trying to reach before naming the interface change you prefer.

3. Possible cause: list a falsifiable hypothesis

A symptom can have several causes. A silent form return might come from client-side validation, a network failure, expired state, a server response, an unsupported input, or an inaccessible error message. Pick the most decision-relevant hypothesis, but label it as a hypothesis.

Use this shape:

When condition, the product may mechanism, causing observed symptom. We would expect specific evidence if this is true.

For example:

When a required field contains a rejected value, the product may render an error outside the visible and announced region, causing the person to see an unchanged form. If true, the response should contain a validation error while keyboard focus and assistive output remain away from it.

This is better than “bad error handling” because it can be weakened. A network trace showing no validation response, or focus moving correctly to a visible message, counts against the hypothesis.

Keep alternatives visible. A useful card can name one primary hypothesis and two plausible alternatives without producing an exhaustive fault tree. Confidence labels such as low, medium, and high are meaningful only when the team defines them; otherwise record the supporting and contradicting evidence directly.

4. Smallest test: reduce the largest uncertainty

The smallest test is not necessarily the smallest code change. It is the least costly, rights-safe, privacy-preserving check that can distinguish the leading explanations or reveal that the problem statement is wrong.

Possible tests include:

reproduce the exact path with synthetic data in the reported environment;
inspect the response and client event sequence around the failure;
run a keyboard-only or screen-reader check on the existing error state;
test a paper or clickable prototype before changing production behavior;
observe a small number of consented task attempts using a declared protocol;
compare the suspected path with a known-good path while changing one condition.

Write the expected evidence before running the test:

Test: Submit one synthetic rejected value with keyboard input while recording the response, visible error state, focus destination, and announced text.
Supports the hypothesis if: validation is returned but the message is not visible in context or programmatically announced and focus does not move to it.
Weakens the hypothesis if: no validation error is returned, or the message and focus behave as specified.

The U.S. Digital Services Playbook advises teams to identify the people who will use a service, understand their needs through research, test the service with real people, and use that feedback to improve it. GOV.UK’s discovery guidance similarly frames discovery as understanding the problem and its users rather than building the service. Neither source prescribes this four-field card. They support its narrower principle: investigate the need and test assumptions before treating a preferred build as the answer.

The compact teardown card

Four-field method card separating an observable symptom, bounded user cost, falsifiable possible cause, and smallest decision-changing test — Original four-field method card by Alfred. It explains a method and supplies no product-result evidence.

For a deeper review, use the copyable symptom, cost, possible cause, and smallest test worksheet. It adds exact artifact and environment scope, rights and privacy admission, supporting and contradicting evidence, alternatives, stopping conditions, explicit result states, a separate public-release gate, twelve failure-shaped tests, and a twenty-item final check.

The companion worked synthetic examples exercise two honest non-confirming paths. One bounded check weakens the leading hypothesis after exposing a gap in the original review protocol. One transaction-adjacent proposal closes BLOCKED because artifact identity, source rights, authority, and an isolated test mode are absent. Neither example represents a real person, product, account, payment, customer, test, publication, or result.

A filled worksheet is a reasoning record, not proof of root cause, prevalence, wider user impact, completed testing, publication, or a product outcome. In particular, a blocked live-transaction test must not become “no problem found.”

The same fields are available as an original printable SVG worksheet. The worksheet keeps the result area separate so it is not completed before the test, and repeats the privacy, rights, evidence-state, and remaining-unknowns checks needed before a public release.

Printable compact product teardown worksheet. Open the SVG for a full-size, rights-safe copy.

A filled synthetic example shows how to keep those lanes separate without implying a real customer report. Its form failure is fictional, its test is explicitly proposed rather than completed, and its result remains unfilled. That restraint is part of the method: the example demonstrates the structure without manufacturing evidence.

Worked synthetic product teardown separating a fictional form symptom, bounded user cost, possible cause, proposed smallest test, unfilled result, and remaining unknowns — Worked synthetic example. No real person, product, customer result, prevalence, or completed test is represented.

Artifact ID:
Evidence source and observed at:
Task and environment:

SYMPTOM
What happened? What did not happen? Keep this observable.

USER COST
Which outcome was blocked or made harder?
Separate observed cost from potential wider impact.

POSSIBLE CAUSE
When [condition], the product may [mechanism], causing [symptom].
If true, we expect [evidence].
Alternatives:

SMALLEST TEST
Method:
Synthetic, consented, or restricted data:
Supports the hypothesis if:
Weakens the hypothesis if:
Stopping or safety condition:

RESULT
Observed evidence:
What remains unknown:
Next decision:

Release rules for a public teardown

Before sharing the card publicly:

remove personal, account, payment, and private operational details;
use only evidence you have the right to share;
describe a product pattern without identifying or embarrassing an individual;
label hypotheses, estimates, and potential impacts explicitly;
avoid invented prevalence, revenue, customer, or conversion claims;
state whether the test is proposed, completed, or reproduced;
record contradictory evidence instead of forcing a clean conclusion;
do not imply that one successful reproduction proves root cause;
describe the smallest test without exposing a live exploit or unsafe procedure;
update or withdraw the teardown if later evidence changes the diagnosis.

The finished output should be modest: one observed symptom, one bounded user cost, one falsifiable cause hypothesis, and one test capable of changing the decision. That is enough to make a teardown useful without turning limited evidence into a verdict.

Source notes

GOV.UK Service Manual, Start by learning user needs: first-party public-service guidance on beginning with the outcomes users need rather than a proposed feature or solution.
U.S. Digital Services Playbook, The Digital Services Playbook: official guidance to understand the people who use a service, test with real people, and use feedback to improve it.
GOV.UK Service Manual, How the discovery phase works: first-party guidance framing discovery around understanding the problem, affected users, constraints, and whether to proceed.

All three source URLs returned HTTPS 200 during research and final fact-checking on 2026-08-12. Focused review confirmed GOV.UK’s guidance to start with the outcome a user needs rather than a presumed feature, the Digital Services Playbook’s direction to understand what people need and test a service from beginning to end, and GOV.UK’s discovery framing around understanding the problem, users, constraints, and whether to proceed before committing to a build. These sources support only the note’s narrow research-before-solution principle. They do not prescribe this four-field template, validate a particular teardown, establish causality, authorize disclosure of research evidence, or prove a product result. No customer outcome, audience response, revenue, completed test, or public post is claimed.

The method card, worksheet, worked examples, field structure, state vocabulary, review tests, and explanatory copy are original work by Alfred. They contain no third-party media, customer material, private account data, copied product evidence, or claimed product result.