FAB: Features, Advantages, Benefits — stop selling features

After AIDA, PAS and BAB, here is the method that works at a different scale: FAB, for Features, Advantages, Benefits. Its starting observation is blunt: most landing pages describe what the product is ("real-time sync", "high-density foam", "unlimited PDF export"), while the visitor buys what their life becomes. FAB isn't a page structure, it's a systematic bridge: for each feature, you derive the advantage it provides, then the human benefit it makes possible. Three levels, always in the same order — and a page that finally stops talking about itself.

The three levels, on one running example

Let's take an openly fictional product: Factura, invoicing software for freelancers. One of its features: "automatic follow-ups on unpaid invoices at day 7, day 15 and day 30".

F — The feature: what the product is

This is the raw, verifiable fact, written from the product's point of view: Factura sends automatic reminders on a schedule. A feature never lies, but it doesn't sell either — it assumes the visitor will do the translation work themselves. Most won't.

A — The advantage: what the feature enables

The advantage translates the feature into a capability: thanks to automatic follow-ups, you no longer have to track who owes you what or write reminder emails by hand. We've left the product and entered usage — but we're still in functional, interchangeable territory: a competitor can promise exactly the same thing.

B — The benefit: what the visitor's life becomes

The benefit goes all the way down to the human level: you get paid faster, without ever playing bad cop with your clients — the reminder comes from the software, not from you, and the business relationship stays intact. That's the sentence that belongs in the first screen, the subheadline, the section titles. The feature moves down into the body of the page — as proof, not as promise.

The "so what?" exercise

How do you know you've reached the benefit? With the simplest test in copywriting: ask "so what?" after each sentence, and keep going as long as an answer exists. "Automatic follow-ups at day 7." — So what? — "You no longer have to think about it." — So what? — "Your invoices get paid without you coming across as the annoying creditor." — So what? — "Your cash flow breathes, and so do your client relationships." When the only possible answer is a fundamental human need — time, money, status, peace of mind, relationships — you've arrived. If your sentence still supports a "so what?", it describes a means, not an end. This exercise connects directly to the work on your value proposition: a value proposition is a FAB benefit chosen as the main angle for the entire page.

Why stacking features backfires

The classic objection: "the more features we list, the more complete the product looks". Marketing research has studied precisely this reflex. A study by Debora Viana Thompson, Rebecca Hamilton and Roland Rust, published in 2005 in the Journal of Marketing Research, "Feature Fatigue: When Product Capabilities Become Too Much of a Good Thing", shows that before purchase, consumers overweight the number of features and underweight ease of use — then regret that choice in actual use, when the accumulated complexity erodes their satisfaction. The authors call this phenomenon "feature fatigue". The lesson for a landing page is twofold: stacking features may seduce in the short term, but you're selling exactly what will disappoint later; and a page centred on benefits and ease of use doesn't just convert better — it sells the value the customer will actually perceive once the product is in their hands. Writing in benefits isn't a sales trick: it's aligning the promise with the experience.

Where to use FAB on a landing page

FAB doesn't structure the whole page; it structures every argument the page contains. Concretely, four spots benefit immediately:

• The features section, turned into a benefits section: each block keeps its icon and its feature, but the block title becomes the benefit ("Get paid without chasing anyone") and the feature moves into the supporting text.
• Headlines and subheadlines: the subheadline of the first screen is the best spot on the page for a pure benefit — the feature has no business there.
• Bullet lists: each bullet is written benefit first, feature second ("Get your evenings back — reminders sent automatically at day 7, 15 and 30").
• The pricing page: a plan that lists "10 users, 5 GB, API" sells quotas; a plan that states what each tier lets you do more of sells a progression.

When features remain necessary

FAB doesn't say to delete features — it says never to leave them on their own. Facing an expert buyer or a technical B2B audience, the feature becomes essential again: a CTO comparing three solutions wants the list of integrations, the certifications, the API limits, and a page offering nothing but benefits will feel hollow, even suspicious. The rule: the benefit opens, the feature proves. The benefit creates desire and sets the direction; the spec, placed right behind it, brings credibility and answers the objection "how can you promise that?" — exactly the role we give proof in our article on handling objections. A feature without a benefit interests no one; a benefit without a feature convinces no one.

FAB versus AIDA, PAS and BAB — and the two traps to avoid

FAB doesn't compete with the structures we've already covered: AIDA, PAS, BAB or StoryBrand organise the entire page, from the first screen to the final button; FAB organises each argument inside that page. They combine naturally: a PAS page whose solution section unrolls its arguments in FAB, a BAB page whose After is a benefit pushed to the end of its "so whats". Two traps remain. The first: vague, interchangeable benefits — "save time", "boost your productivity" — that could close any page for any product; a good benefit stays attached to its feature and to a precise scene ("your invoices get paid while you're in a meeting"). The second: stacking features for fear of leaving one out — listing all fifteen features "just in case" is precisely the reflex the feature fatigue study invites us to correct; pick the three to five features whose benefits carry the decision, and leave the rest to a documentation page. The LanderKit templates save you half the work: the benefits section is already structured — benefit headline, supporting text, feature as proof — all that's left is to pour in your words, at €89 per template or €229 for the full pack.