Feature, Advantage, Benefit: how to describe something so people want it
By Rita Okonkwo · The Craft
When people describe something they care about, a product, a tool, their own proposal, they describe what it is. What it does, how it works, what is in it. All true, and all about the thing. The listener is left to translate every feature into a reason to care, and most will not bother.
Feature, Advantage, Benefit does the translation for them. What it is, why that is better than the alternative, and what the listener gains. It moves the description, one step at a time, from the thing to the person.
Feature, Advantage, Benefit, one part at a time
Question: Sell us on the document tool you would choose for the team.
- Feature (What it is): It keeps every version of a document automatically, every time anyone saves.
- Advantage (Why it beats the rest): Unlike emailing attachments, nobody ever has to ask which file is the latest, and nothing is lost when two people edit at once.
- Benefit (What the listener gains): Which means you stop spending Friday afternoons merging changes, and you can undo anyone's mistake, including your own, in one click.
The three parts
1. Feature: what it is
The fact about the thing: what it is or what it does. One feature, not a list. Choose the feature that leads to the benefit your listener cares about most, not the one you find most impressive.
2. Advantage: why it beats the rest
Compare it with what the listener would otherwise use, even if that is "doing nothing". An Advantage only means something relative to an alternative: "keeps every version" becomes interesting once you remember the email thread with five attachments called final.
The trap is a comparison nobody was making. Compare with what your listener actually does today.
3. Benefit: what the listener gains
What changes in the listener's life, in their terms: time, money, stress, risk, a better Friday. Speak to them directly ("you stop...") and make it concrete enough to picture. This is the part that sells; the other two are there to make it believable.
The "which means" test
The quickest way to find a Benefit is to say the Feature and then add "which means...", and keep adding it until you reach something the listener would actually want. "It keeps every version, which means nobody loses work, which means you stop spending Friday afternoons merging changes." Stop when you reach the person. If you run out of "which means" before you get there, you have picked the wrong feature for this listener.
An answer, taken apart
Feature. It keeps every version of a document automatically, every time anyone saves.
Advantage. Unlike emailing attachments, nobody ever has to ask which file is the latest, and nothing is lost when two people edit at once.
Benefit. Which means you stop spending Friday afternoons merging changes, and you can undo anyone's mistake, including your own, in one click.
Three sentences, and the last one is entirely about the listener. That is the direction the whole answer travels.
Where it works, and where it doesn't
Use it for sales conversations, product demos, recommending a tool or supplier, pitching a feature to your team, and the "why should I use this?" question in any form. It also works on ideas: a policy's feature, its advantage over the current rule, its benefit to the people affected.
It assumes the listener already has the problem. If they do not, start with Problem, Solution, Benefit, which names the pain first.
How the Coach listens for it
The Coach checks a take for a feature, an advantage and a benefit. The usual miss is a take that stays at the feature: a clear description of what something does, with no comparison and nothing about the listener.
Practise it
Practise Feature, Advantage, Benefit in the Coach. Lock it and try the Sale and Pitch scenarios; then try it on something that is not a product at all.