Features, Benefits and Outcomes
Date: 2026-09-27
A feature is what it has, a benefit is what that does, an outcome is what changes for the customer. Copy stalls at features because that’s what the business knows; buyers decide on outcomes — but specifiers compare features, so the right level depends on who’s reading.
Features, benefits and outcomes are three levels of describing the same thing: the feature is a property of the product, the benefit is what that property does, and the outcome is the change in the customer’s situation.
The ladder
FEATURE ceramide complex, fragrance-free what it HAS
↓ so what?
BENEFIT repairs the skin barrier; no irritants what it DOES
↓ so what?
OUTCOME skin that doesn't feel tight by lunch; what CHANGES
no more flare-ups before big days for them
“So what?” is the whole technique. Ask it of each line until the answer is something the customer would say about their own life. The two-step version is the FAB frame in Persuasive Structures; the outcome rung is the one it tends to skip.
Outcomes are where the job lives — the progress someone is trying to make, in Jobs To Be Done terms. That’s why they’re the rung that differentiates: many products share features, fewer promise the same outcome credibly.
Why copy stalls at features
- It’s what the business knows. Spec sheets, supplier data and product teams speak features
- Features are safe. “Contains 5% niacinamide” is verifiable; “clearer skin” is a claim, and in regulated categories may not be allowed — [CHECK: ASA (Advertising Standards Authority) and CAP (Committee of Advertising Practice) code rules on efficacy claims in your category]
- At scale, features are what can be templated — Product Descriptions
Why “always lead with benefits” is wrong
The common rule overcorrects. The right level depends on the reader:
| Reader | Needs first | Because |
|---|---|---|
| Problem aware, new to the category | Outcome | They can’t yet translate specs into meaning |
| Solution aware, comparing options | Features, with the benefit attached | They’re checking specs against a list |
| Technical buyer, specifier, B2B | Features, precisely | Vague outcomes read as evasion |
| Repeat buyer | Neither — the variant and the price | They already know |
Feature-first is right when the reader already knows the outcome they want and is checking whether this delivers it. Laptop RAM, a lens’s focal length, a supplement’s dose. Burying the spec under outcomes frustrates exactly the buyer closest to purchase. This maps closely onto Awareness Stages.
The shape on a product page
HEADLINE / FIRST LINE outcome "all-day comfort for tight, dry skin"
SUPPORTING POINTS benefit + feature "repairs the barrier — ceramide complex"
"no irritants — fragrance-free"
SPEC TABLE / ACCORDION features, full ingredients, size, pH, certifications
Every layer present, in descending order of abstraction. The scanner reads the first line, the comparer reads the table — Reading Behaviour Online, Progressive Disclosure.
Benefit inflation
The failure on the other side:
- Outcomes nobody believes. “Transform your mornings” from a toaster. The further the outcome from the feature, the more proof it needs — Trust Signals
- Generic benefits. “Saves time”, “high quality” — claimed by everyone, differentiates nothing. The reversal test in Value Propositions catches these
- Outcome without the feature — asks the reader to take the claim on trust with no mechanism. The feature is the evidence for the benefit
- Unlawful outcomes. Health, efficacy and financial outcomes are regulated claims, not copy choices
Testing it
- Test the first line’s level, not the whole page — outcome-led versus feature-led opening
- Segment by source before concluding; a flat result can be a win for one awareness stage and a loss for another — Segmentation (test results)
- Returns and support contacts as guardrails — outcome copy that oversells converts and then comes back — Guardrail Metrics