Skill: quochungto/bookforge-fab-statement-classifier (version 1.0.0)

--- name: fab-statement-classifier description: "Classify seller statements as Features, Advantages, or true Benefits using Rackham's strict FAB definitions. Use this skill to audit a pitch deck, sales email, demo script, or call transcript for FAB distribution. Invoke when someone asks 'are these benefits or advantages?', 'is this a feature or a benefit?', 'review my sales deck for FAB', 'audit my pitch for Rackham FAB', 'classify these statements', 'are my slides benefit-focused?', 'why am I getting objections to my deck?', 'does this qualify as a benefit?', or 'I call these benefits but I'm not sure'. The skill enforces Rackham's empirically-derived definition: a statement is a Benefit ONLY if it meets a customer-expressed Explicit Need — not if it sounds helpful, not if it shows the product can help, and not if it meets a problem (Implied Need). In typical B2B sales content, 40-50% of statements labeled 'Benefits' by the seller are actually Advantages. This skill catches that. Also includes Rackham's 10-item FAB classification quiz for self-testing. Applies to B2B account executives auditing their own decks, sales managers reviewing team content, and marketers producing collateral for large-sale contexts." version: 1.0.0 homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/spin-selling/skills/fab-statement-classifier metadata: {"openclaw":{"emoji":"🔬","homepage":"https://github.com/bookforge-ai/bookforge-skills"}} status: draft source-books: - id: spin-selling title: "SPIN Selling" authors: ["Neil Rackham"] chapters: [5, 6] tags: [sales, b2b-sales, enterprise-sales, fab-methodology, pitch-deck-review, content-audit, spin-methodology, objection-prevention] depends-on: - need-type-classifier execution: tier: 1 mode: hybrid inputs: - type: document description: "Seller content to audit — pitch deck export (.md, .pdf, .txt), sales email, demo script, or call transcript with seller statements extracted" - type: document description: "Deal context (optional) — needs-log.md or deal-brief.md identifying Explicit Needs the customer has expressed" tools-required: [Read, Write] tools-optional: [Grep] mcps-required: [] environment: "Document set: pitch-deck-{deal}.md, sales-email.md, demo-script.md, or call-transcript-{date}.md. Agent classifies and produces audit report; human acts on the coaching." discovery: goal: "Determine whether each seller statement is a Feature, Advantage, or true Benefit — and surface the dominant error: statements labeled Benefits that are actually Advantages" tasks: - "Classify each statement from provided seller content as Feature, Advantage, Benefit, or unclassifiable" - "Flag the Advantage-as-Benefit anti-pattern when present" - "Produce a count summary by FAB type" - "Provide coaching guidance on converting Advantages into Benefits by first developing Explicit Needs" - "Run interactive FAB practice using Rackham's 10-item quiz" audience: roles: [account-executive, sales-manager, solutions-consultant, marketer, founder-led-seller] experience: intermediate when_to_use: triggers: - "Before a major demo or proposal — check whether the deck has any true Benefits or only Advantages" - "After a call with objections — diagnose whether the content generated them by offering Advantages" - "Marketing reviewing collateral for large-sale context — most 'Benefits' in decks are Advantages" - "Sales coaching — showing a rep why their 'benefits-focused' deck actually contains zero Benefits" - "Self-training using the 10-item FAB quiz" prerequisites: - "need-type-classifier — needed to verify whether an Explicit Need is present before classifying as Benefit" not_for: - "Drafting new Benefit statements (use benefit-statement-drafter)" - "Generating SPIN questions to develop Explicit Needs (use spin-discovery-question-planner)" - "Diagnosing objection causes in full (use objection-source-diagnoser)" - "Pricing strategy" environment: codebase_required: false codebase_helpful: false works_offline: true quality: scores: with_skill: 0 baseline: 0 delta: 0 tested_at: "" eval_count: 0 assertion_count: 0 iterations_needed: 0 what_skill_catches: - "Marks aspirational claims ('so you can focus on what matters') as Advantages, not Benefits" - "Correctly requires a prior customer-expressed Explicit Need before allowing Benefit classification" - "Flags the industry-wide pattern of labeling Advantages as Benefits" what_baseline_misses: - "Calls any statement showing value a 'Benefit' without checking for an Explicit Need" - "Treats implied needs ('they mentioned this problem') as sufficient basis for a Benefit" - "Does not distinguish between Type A and Type B definitions or flag the naming confusion" --- # FAB Statement Classifier ## When to Use You have seller content — a pitch deck, sales email, demo script, or call transcript — and you need to know: are these statements Features, Advantages, or true Benefits? This matters because the most common error in B2B sales content is calling Advantages "Benefits." Rackham's 5,000-call study found that Advantages (what most training calls "Benefits") had no statistically significant relationship to success in large sales — but true Benefits were strongly linked to Orders and Advances. The distinction is not semantic. It predicts whether your content will close deals or generate objections. Use this skill: - Before a major demo or proposal, to verify the content contains true Benefits (not just Advantages) - After a call where you received value objections or "it's not worth it" responses — these are the customer response most correlated with Advantage-heavy selling - When marketing reviews collateral for use in large-sale contexts - When coaching a rep who claims their deck is "benefit-focused" **Interactive practice mode:** If you want to self-test your FAB classification ability, ask the skill to run Rackham's 10-item quiz. The full quiz with answer key is in [references/fab-classification-quiz.md](references/fab-classification-quiz.md). Do NOT use this skill to draft new Benefit statements (use `benefit-statement-drafter`) or to generate questions to develop needs (use `spin-discovery-question-planner`). ## Context & Input Gathering ### Required Context (must have — ask if missing) - **Seller content to audit:** The actual statements you want classified -> Check prompt for: pasted text, file path, or slide content -> Check environment for: `pitch-deck-{deal}.md`, `sales-email.md`, `demo-script.md`, `call-transcript-{date}.md` -> If missing, ask: "Paste or point me to the seller statements you want me to classify." - **Sale context (large vs small):** Determines how strictly to apply the Benefit gate -> Check prompt for: enterprise/SMB label, deal size, multi-stakeholder mention -> Check environment for: `deal-brief.md` -> If missing: default to large-sale context (conservative — prevents overstating Benefits) ### Observable Context (gather from environment) - **Needs log or deal brief:** Explicit Needs the customer has expressed -> Look for: `needs-log.md` from `need-type-classifier`, `deal-brief.md` -> If available: use it to verify Benefit candidates — a statement meets an Explicit Need only if that need is documented as expressed by the customer -> If unavailable: note the absence; any statement claiming to meet a need will be classified as Advantage unless the customer's Explicit Need is visible in the content itself (e.g., in a call transcript where both sides speak) - **Mode check:** Is this an audit of existing content, or an interactive quiz? -> Audit mode: read the provided content, classify each statement, produce `fab-audit-{artifact}.md` -> Quiz mode: deliver the 10-item Rackham quiz, collect answers, give scored feedback ### Sufficiency Threshold SUFFICIENT: Seller content + sale context (or default to large) PROCEED WITH DEFAULTS: Content present, no needs log (classify all statements without confirmed Explicit Needs as Advantages with a note) MUST ASK: No seller content provided AND no quiz mode requested ## Process ### Step 1: Establish the Classification Framework **ACTION:** Before classifying any statement, confirm the three definitions below. Apply them exactly as written. **WHY:** The entire value of this audit depends on using Rackham's strict definitions, not the common-usage definitions. Most sellers have been trained that "a Benefit is anything that shows how a feature can help the customer" — this is what Rackham calls an Advantage. If this step is skipped, every subsequent classification defaults to the casual definition and the audit produces no new information. **The three definitions:** **Feature** — A fact, data point, or characteristic about the product or service. Does not explain use or link to customer outcomes. Neutral in impact. - Test: "Is this just describing what the product is or what it includes?" → Feature **Advantage** — A statement showing how a product feature can be used or can help the customer. More than a Feature — links capability to potential value. BUT: does not meet a customer-expressed Explicit Need. - This is what most sales training calls a "Benefit." It is not a Benefit in Rackham's taxonomy. - Test: "Does this show how the product helps, but without a prior customer-expressed want?" → Advantage **Benefit (Rackham's Type B)** — A statement showing how the product meets an Explicit Need that the customer has expressed. Both conditions required: 1. The customer stated a specific want, desire, or intention before this statement 2. This statement shows the product meets that specific expressed need - Test: "Did the customer explicitly say they need/want this? AND does this statement show we can deliver it?" → Benefit **Unclassifiable** — A statement that cannot be evaluated without more context (e.g., a question, a transition phrase, a non-product statement). **Step 1 output:** Confirm the three definitions are loaded before proceeding. ### Step 2: Identify Explicit Needs in the Context **ACTION:** Before classifying individual statements, scan the available context (needs-log, deal brief, or transcript) for any customer-expressed Explicit Needs. List them. These are the only valid anchors for Benefit classifications. **WHY:** The classification of any statement as a Benefit requires a prior customer-expressed Explicit Need. Without identifying those first, there is no reference point — every statement defaults to Feature or Advantage. This step also prevents the common error of using Implied Needs (problems, difficulties) as Benefit anchors. If you need to verify whether a specific customer statement is an Explicit Need, invoke `need-type-classifier` or apply its definitions directly: an Explicit Need is a statement of want, desire, or intention ("we need X," "we're looking for Y," "I'd like Z") — not a statement of problem or dissatisfaction. **IF** a `needs-log.md` exists from a prior `need-type-classifier` run → read it and extract the Explicit Needs column **ELSE IF** the content being audited is a call transcript (both sides visible) → scan buyer statements for Explicit Need language **ELSE** → note that no confirmed Explicit Needs are available; proceed with the understanding that Benefit classifications will be rare or absent **Step 2 output:** A short list of confirmed Explicit Needs available in context (may be empty). ### Step 3: Classify Each Statement **ACTION:** For each seller statement in the provided content, apply the definitions from Step 1, anchoring to the Explicit Needs from Step 2. Produce a per-statement classification table. **WHY:** Showing the classification evidence per statement makes the output auditable. The seller needs to see exactly which words triggered each classification — especially for statements they labeled Benefits that are actually Advantages. Without this granularity, coaching is abstract; with it, the seller can rewrite specific statements. **For each statement, output:** 1. Statement (quoted or paraphrased if long) 2. Classification: Feature / Advantage / Benefit / Unclassifiable 3. Explicit Need present: Yes (quote it) / No 4. Rationale: one sentence explaining the classification **The dominant pattern to flag:** Statements containing phrases like "so you can," "which means you'll," "helping your team," "giving you the ability to," "enabling you to" are structural markers of Advantages. They show use or help — but unless paired with a prior customer-expressed want, they are Advantages, not Benefits. Flag these explicitly when the seller has labeled them Benefits. **Step 3 output:** Classification table, one row per statement. ### Step 4: Produce the Count Summary and Anti-Pattern Flag **ACTION:** Summarize the classification results. Count Features, Advantages, Benefits, and Unclassifiable. Flag the Advantage-as-Benefit anti-pattern if present. **WHY:** The count summary makes the FAB distribution visible at a glance. Most sellers are surprised by how few true Benefits their content contains. A deck with 15 statements that the seller calls "benefit-focused" typically contains 0-2 true Benefits, 8-10 Advantages, and 4-5 Features. Showing this quantitatively is more persuasive than qualitative criticism. **Count summary format:** - Total statements audited: N - Features: N (N%) - Advantages: N (N%) - **True Benefits (Rackham): N (N%)** - Unclassifiable: N (N%) **Advantage-as-Benefit flag:** If any statement was labeled a "Benefit" by the seller (in the deck or script) but classified as an Advantage by this audit, call this out explicitly: > "WARNING: N statements labeled 'Benefits' in this content are Advantages by Rackham's definition. They show how the product can help but do not meet a customer-expressed Explicit Need. In large sales (5,000-call study), Advantages have no statistically significant relationship to call success. True Benefits require a prior Explicit Need from the customer." **Step 4 output:** Count summary + anti-pattern flag (if applicable). ### Step 5: Coaching — Converting Advantages to Benefits **ACTION:** For each statement classified as Advantage, provide a one-line coaching note: what Explicit Need the customer would need to express before this Advantage could become a Benefit, and how to develop that need. **WHY:** The audit is only useful if it tells the seller what to do next. "This is an Advantage, not a Benefit" is a diagnosis. The prescription — "here's the Explicit Need you'd need to develop before presenting this" — is what makes the content actionable. Without this step, the seller knows their deck is weak but not how to fix it. **Coaching note format (per Advantage):** > Statement: "[statement]" > To become a Benefit, your customer would need to have said something like: "[example Explicit Need in customer's words]" > How to develop it: Ask [Problem Question to surface Implied Need] → [Implication Question to build consequence] → [Need-payoff Question to get the customer to articulate the want]. Then present this capability as directly meeting their stated need. **Step 5 output:** Per-Advantage coaching notes. ### Step 6: Write the Audit Report **ACTION:** Compile Steps 3-5 into a single structured report. Write it to `fab-audit-{artifact}.md` (e.g., `fab-audit-q2-deck.md`, `fab-audit-discovery-email.md`). **WHY:** A written report persists across the conversation and can be shared with the team. It also feeds downstream skills: `benefit-statement-drafter` reads a needs log and the audit to draft Benefits for the confirmed Explicit Needs; `objection-source-diagnoser` reads the audit to trace objections back to FAB source. **Report structure:** ``` # FAB Audit — {Content Name} — {Date} ## Sale Context {Large / Small / Unknown} ## Explicit Needs Available {List, or "None confirmed — all Benefits require Explicit Need development first"} ## Statement-by-Statement Classification | # | Statement | Classification | Explicit Need Present | Rationale | |---|---|---|---|---| ## FAB Distribution Summary - Features: N (N%) - Advantages: N (N%) - True Benefits: N (N%) ## Advantage-as-Benefit Flag {If applicable: which statements were miscategorized, and why it matters} ## Coaching: Converting Advantages to Benefits {Per-Advantage coaching notes} ## Recommended Next Step {One paragraph: what the seller should do before the next call/send} ``` ### Optional: Interactive Practice Mode **ACTION:** If the user asks to test their own FAB classification ability, deliver Rackham's 10-item quiz from [references/fab-classification-quiz.md](references/fab-classification-quiz.md). Present all 10 statements, collect the user's answers, then score and explain each one. **WHY:** The quiz uses a real selling dialogue with deliberate classification traps (especially #7 and #10, which sound like Benefits but are Advantages). Users who pass it — especially #7 — have internalized the Type A/Type B distinction. The quiz also grounds future audits in shared vocabulary. ## Key Principles - **A Benefit requires customer speech first.** No matter how aspirational, customer-focused, or value-oriented a statement sounds, it is an Advantage unless the customer has expressed the underlying want in their own words before the statement was made. Pitch decks, by their nature, cannot contain true Benefits — they are written before the customer has spoken. They contain Features and Advantages at best. - **The naming confusion is the problem.** Decades of sales training have used the word "Benefit" to mean what Rackham calls an Advantage. Sellers who were well-trained in "Feature-Benefit selling" are actually Feature-Advantage sellers. Rackham's 5,000-call study showed that what most people call Benefits have no statistical relationship to large-sale success. True Benefits — those meeting customer-expressed Explicit Needs — are strongly correlated with Orders and Advances. - **Advantages create objections in large sales.** Linda Marsh's correlation study showed that Advantages are the most probable source of customer objections. When a seller presents a capability the customer hasn't asked for, the customer evaluates whether it's worth the cost — and in large sales, "not worth it" is a likely response. This is why objection-heavy calls are typically Advantage-heavy calls. - **More Features → more price sensitivity.** From the 18,000-call Features study: heavy use of Features increases customer sensitivity to price. In expensive products, this works against the seller. When classified Features are high, advise shifting from description to need development. - **Development precedes Benefits.** Rackham's advice: "Do a good job of developing Explicit Needs and the Benefits almost look after themselves." You cannot manufacture Benefits from content alone — you develop them from customer conversations. The audit's purpose is to show what's missing and guide what needs to be developed before the content can be benefit-loaded. - **Stay in scope.** This skill classifies existing content. It does not draft new statements (use `benefit-statement-drafter`), generate questions to develop needs (use `spin-discovery-question-planner`), or diagnose objections in depth (use `objection-source-diagnoser`). When the audit points to a development gap, name the right skill. ## Examples **Scenario: Pitch deck audit before a major enterprise demo** Trigger: AE says: "I'm presenting a 15-slide deck tomorrow. Can you check if it's benefit-focused?" Process: - (Step 1) Load FAB definitions. - (Step 2) Read needs-log.md — 2 Explicit Needs documented: "We need to cut monthly close from 5 days to 2" and "We need a single dashboard for all 3 regions." - (Step 3) Classify all 15 slides' key statements. Find: 6 Features (product specs, pricing, company stats), 8 Advantages ("helps your team move faster," "gives you complete visibility," "reduces guesswork"), 1 Benefit (the single-dashboard claim meets the stated Explicit Need), 0 unclassifiable. - (Step 4) Count: 40% Features, 53% Advantages, 7% Benefits. Flag: 8 statements the seller labeled "Benefits" in the deck are Advantages. - (Step 5) For each of the 8 Advantages, provide a coaching note on what Explicit Need to develop. - (Step 6) Write `fab-audit-q2-demo-deck.md`. Output: Audit report showing 1 confirmed Benefit, 8 Advantages mislabeled as Benefits, 6 Features. Recommendation: develop 1-2 more Explicit Needs on the pre-call before tomorrow — at minimum, convert the "monthly close" Advantage into a Benefit by confirming the need directly. --- **Scenario: Sales email review** Trigger: SDR asks: "Is this prospecting email too feature-heavy? I'm not getting replies." Process: - (Step 1) Load definitions. - (Step 2) No needs log — cold outreach, no prior customer speech. Note: no Explicit Needs available → no Benefits possible. - (Step 3) Read the email. Find: 3 Features (product specs), 4 Advantages ("so you can close deals faster," "giving your team complete pipeline visibility," "cutting your reporting time by 50%"), 0 Benefits (no customer has spoken). - (Step 4) Count: 43% Features, 57% Advantages, 0% Benefits. Flag: a cold email structurally cannot contain Benefits — the customer hasn't spoken yet. All value claims are Advantages. - (Step 5) Coach: the email is Advantage-heavy, which in cold outreach is normal but not maximally effective. Recommend opening with a Problem Question or a specific Implied Need trigger ("If your team is finding that...") to earn a reply, then developing needs in the first call before giving Benefits. Output: `fab-audit-prospect-email.md`. Coaching: shift the email to problem-focused language (what problem do they probably have?) rather than solution-focused language (what can our product do?). Follow up with `spin-discovery-question-planner` for the first call. --- **Scenario: Interactive quiz practice** Trigger: "I want to test my FAB classification. Give me the quiz." Process: Present the 10-item dialogue from [references/fab-classification-quiz.md](references/fab-classification-quiz.md). Collect answers. Score. For any misclassified items, explain the rule that applies — especially items 7 and 10, which are the traps (they sound like Benefits, but no Explicit Need was expressed). Output: Score (X/10). Detailed feedback on any misses. Particular emphasis if the user called #7 or #10 a Benefit — these are the most common errors and map directly to the Advantage-as-Benefit anti-pattern in real sales content. ## References - [fab-classification-quiz.md](references/fab-classification-quiz.md) — Rackham's 10-item FAB classification exercise with full answer key and scoring guide - [fab-definitions-and-edge-cases.md](references/fab-definitions-and-edge-cases.md) — Complete FAB definitions, research findings, edge cases, and the FAB-to-customer-response chain (Features → price concerns; Advantages → objections; Benefits → approval) ## License This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/). Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — SPIN Selling by Neil Rackham. ## Related BookForge Skills This skill depends on: - `clawhub install bookforge-need-type-classifier` — Classify customer statements as Implied or Explicit Needs (needed to verify whether an Explicit Need exists before classifying a statement as a Benefit) Skills that build on this one: - `clawhub install bookforge-benefit-statement-drafter` — Draft Benefit statements that link product capabilities to customer-expressed Explicit Needs (the constructive complement to this audit skill) - `clawhub install bookforge-objection-source-diagnoser` — Trace objections back to their FAB-behavior root cause (Feature → price concerns; Advantage → value objections) Or install the full SPIN Selling skill set from GitHub: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

path: references/fab-classification-quiz.md
content: # FAB Classification Quiz — Rackham's 10-Item Exercise

This quiz is drawn from Chapter 5 ("Giving Benefits in Major Sales") of SPIN Selling by Neil Rackham. It is a verbatim reconstruction of the exercise Rackham uses to test readers' understanding of Features, Advantages, and Benefits before they examine the research data.

**Instructions:** Read the dialogue below. Ten numbered statements are made by the seller (marked with italic in the original text). For each one, decide whether it is a Feature, Advantage, or Benefit — then check your answers against the answer key at the bottom of this file.

---

## The Dialogue

The product being sold is a computer system. Statements by the buyer are included to provide context for classification.

**BUYER:** We've been having some power-related quality problems with our data. Is that something your system handles?

**SELLER (1):** Our system includes balanced voltage stabilization.

**SELLER (2):** This means that if you ever have power fluctuations, the stabilization protects your data integrity automatically.

**SELLER (3):** We also have a backup memory capability, so if the power does fail, your data won't be lost.

**BUYER:** What's the cost on a system like this?

**SELLER (4):** The base configuration costs $42,000.

**BUYER:** That's in range. I need to be able to read source data straight into memory — we're doing a lot of imports from external files.

**SELLER (5):** Our direct memory access module handles exactly that — it lets you read source data straight into memory, which is what you said you need.

**BUYER:** We also can't have errors in those imported data sets. Our tolerance is less than 1 error in 100,000 characters.

**SELLER (6):** Our system has been certified to an error rate of fewer than 1 in 500,000 characters — well within the error tolerance you've described.

**SELLER (7):** Beyond accuracy, the low error rate also means your operators spend less time on data validation, so overall throughput improves.

**BUYER:** I see. What about data access speed?

**SELLER (8):** The system uses a 32-bit processor with a 512K buffer.

**SELLER (9):** The standard configuration includes 256MB RAM and dual I/O channels.

**SELLER (10):** We also have time-based coding, which means that every data record is automatically time-stamped, so you can track exactly when any entry was made.

---

## Answer Key

*(Rackham's answers, paraphrased from the original text)*

**1. Feature.** Balanced voltage stabilization is a fact about the system. The statement does not explain how stabilization can be used or can help the customer. No context about customer need is present.

**2. Advantage.** This statement shows how the Feature in statement 1 can be used or can help the customer — protecting data during power fluctuations. However, it is NOT a Benefit because the customer has not expressed an Explicit Need for stabilization. The customer mentioned quality problems, but that is an Implied Need, not an Explicit one.

**3. Advantage.** The statement shows how backup memory can be used or help the customer. But because there is no evidence the customer has expressed an Explicit Need for backup memory, it cannot be classified as a Benefit.

**4. Feature.** Statements of cost are facts or data about the product. They are Features regardless of whether they are positive or negative facts.

**5. Benefit.** In the preceding statement the customer expressed an Explicit Need: *"I need to be able to read source data straight into memory."* The seller's statement shows how the product meets that Explicit Need directly. This is a true Benefit (Rackham's Type B).

**6. Benefit.** The buyer stated an Explicit Need: an error rate less than 1 in 100,000. The seller shows that the product easily meets that need (1 in 500,000). Explicit Need present → Benefit.

**7. Advantage.** The seller shows another way in which having a low error rate can help the customer (less validation time, better throughput). However, as the next buyer statement shows, the customer has not expressed an Explicit Need for throughput improvement. Benefit-sounding language does not make something a Benefit.

**8. Feature.** A piece of data about the product's processor and buffer. No explanation of how it helps the customer.

**9. Feature.** Further product specifications. Facts about the configuration.

**10. Advantage.** The seller shows how the Feature of time-based coding can be used to help the customer (tracking when entries were made). But the customer has not expressed an Explicit Need for record tracking — so it remains an Advantage.

---

## Score Summary

| # | Classification | Key Rule Illustrated |
|---|---|---|
| 1 | Feature | Neutral fact, no explanation of use |
| 2 | Advantage | Shows use but no Explicit Need expressed |
| 3 | Advantage | Shows use but no Explicit Need expressed |
| 4 | Feature | Cost statements are Features |
| 5 | **Benefit** | Explicit Need stated before → this meets it |
| 6 | **Benefit** | Explicit Need stated before → this meets it |
| 7 | Advantage | Sounds useful but no Explicit Need for it |
| 8 | Feature | Raw specification |
| 9 | Feature | Raw specification |
| 10 | Advantage | Shows use but no Explicit Need for tracking |

**Distribution in this exercise:** 4 Features, 4 Advantages, 2 Benefits (20%)

This distribution is intentional. Rackham's research on typical sales calls found similar ratios — most sellers give far more Features and Advantages than true Benefits. The quiz makes the "Advantage-as-Benefit" confusion vivid by including statements (#7, #10) that sound like Benefits but lack the required Explicit Need.

---

## The Core Rule to Memorize

A statement is a **Benefit** if and only if:
1. The **customer has expressed** a specific want, desire, or intention (an Explicit Need) — in *their* words, before the statement was made
2. The seller's statement directly **shows that the product meets** that specific expressed need

If either condition is missing, the statement is an Advantage at best, a Feature at worst.

"If you can get your customers to say, 'I want it,' it's not difficult to make a Benefit by replying, 'We can give it to you.'" — Neil Rackham

---

*Source: SPIN Selling by Neil Rackham (1988), Chapter 5. This reference is part of the BookForge skill set for SPIN Selling — licensed CC-BY-SA-4.0.*


path: references/fab-definitions-and-edge-cases.md
content: # FAB Definitions and Edge Cases

This reference supplements the `fab-statement-classifier` skill. It provides the full definitions for Features, Advantages, and Benefits as derived from Rackham's SPIN Selling research, with edge cases that commonly trip up classifiers.

---

## Authoritative Definitions

### Feature
**What it is:** A neutral fact, data point, or characteristic about a product or service. Features do not explain use; they do not connect to customer outcomes.

**Research finding:** From analysis of 18,000 sales calls, Features are neutral overall — they neither help nor harm significantly. In large sales, Features used *early* in the call have a slight negative effect. Late in long selling cycles, technically sophisticated buyers may develop a "Features appetite" and respond positively to product detail — but this is an exception.

**Classification test:** Does the statement describe a product characteristic without explaining how it helps? → Feature.

**Examples:**
- "This system has 512K buffer storage."
- "Our consultants have a background in educational psychology."
- "The base configuration is $42,000."
- "It runs on a 32-bit processor."
- "There is a four-stage exposure control."

**Price sensitivity note:** Heavy use of Features increases the customer's sensitivity to price. For low-cost products this works in the seller's favor. For expensive products, it works against them — causing more price objections.

---

### Advantage (Rackham's "Type A Benefit")
**What it is:** A statement showing how a product feature *can be used* or *can help* the customer. More than a Feature — it links the capability to potential customer value. However, it does NOT meet a customer-expressed Explicit Need.

**The naming problem:** Most sales training (including the majority of programs over the past 60 years) teaches sellers to give "Benefits." What those programs actually describe and teach are Advantages in Rackham's taxonomy. The term "Benefit" has been so badly degraded in common usage that it is near-meaningless. Rackham's distinction is what separates his research from the consensus.

**Research finding:** From the 5,000-call Benefits study, Advantages had **no statistically significant relationship** to call success in large sales. In small sales, they have a moderate positive relationship. Early in a multi-call selling cycle, Advantages have some positive effect (they "run out of steam" as the cycle progresses). They create objections at higher rates than Benefits — Linda Marsh's correlation study showed that Advantages are the primary source of customer objections.

**Classification test:** Does the statement show how the product can help or be used, but without a prior customer-expressed Explicit Need? → Advantage.

**Examples:**
- "This means you won't lose data during power failures." (no Explicit Need for backup expressed)
- "Our system would eliminate that retyping for you." (only an Implied Need for less retyping expressed)
- "The low error rate means your operators spend less time on validation." (no Explicit Need for validation reduction stated)
- "Time-based coding means you can track when any entry was made." (no Explicit Need for tracking stated)
- "This would speed up your workflow significantly." (general capability claim, no specific Explicit Need stated)

**The Advantage-as-Benefit anti-pattern:** This is the single most prevalent error in B2B sales content. Sellers (and marketers) write statements that sound helpful, aspirational, and customer-facing — and label them "Benefits" — but no customer has ever expressed the underlying want. Examples include:
- "So you can focus on what matters most" (common deck filler — sounds beneficial, meets no stated need)
- "Giving your team the visibility they need" (who asked for visibility? no one, in this context)
- "Eliminating the guesswork from your process" (guesswork was described as a problem = Implied Need at best)

---

### Benefit (Rackham's "Type B Benefit")
**What it is:** A statement showing how the product meets an Explicit Need that the customer has expressed. Two conditions, both required:
1. The customer expressed a specific want, desire, or intention **before** the statement was made
2. The seller's statement **directly links the product capability to that specific expressed need**

**Research finding:** From the 5,000-call study, Benefits (Type B) were significantly higher in calls leading to Orders and Advances. Benefits are the only product statement type strongly linked to success in ALL sizes of sales. The Motorola Canada controlled study showed salespeople trained to use Benefits instead of Advantages increased dollar sales volume by 27%.

**Structural pattern:** A Benefit almost always has two components:
- A reference to what the customer said ("Since you need X..." / "You mentioned you want Y...")
- A demonstration that the product delivers it ("...our product does exactly that")

**Classification test:** Did the customer express this specific want in their own words before this statement? AND does this statement show the product meets that exact expressed want? → Benefit.

**Examples:**
- Customer: "I need to read source data straight into memory." → Seller: "Our direct memory access module does exactly that." → **Benefit**
- Customer: "We need error rates under 1 in 100,000." → Seller: "We're certified at 1 in 500,000, which meets your requirement." → **Benefit**
- Customer: "We'd like a single dashboard for all three regions." → Seller: "Our unified reporting module shows all regions in one view." → **Benefit**

**The development dependency:** You cannot give a true Benefit without first developing an Explicit Need. This is why Benefits cannot be "written in advance" without customer context. A pitch deck can contain Features and Advantages. It cannot contain Benefits — because Benefits require the customer to have spoken first. This is why pre-call deck audits typically find 0% true Benefits and why Rackham's training advice is: "Do a good job of developing Explicit Needs and the Benefits almost look after themselves."

---

## Edge Cases and Common Misclassifications

### Edge Case 1: "They mentioned a problem, then I showed the solution"
Situation: Customer says "Our reporting takes 2 days." Seller says: "Our system cuts reporting time to 2 hours."

**Classification: Advantage, NOT Benefit.**
Reason: "Takes 2 days" is an Implied Need — a problem statement, a dissatisfaction. The customer described a pain, not a want. To be a Benefit, the customer must have said "We need faster reporting" or "We want to get reporting down to under a day" (Explicit Need). Showing a solution to an Implied Need = Advantage.

To convert: Use Implication Questions to develop the consequences of the 2-day delay, then Need-payoff Questions to get the customer to articulate "We need reporting in under a few hours." Once they say it → you can give a Benefit.

---

### Edge Case 2: "I'm just assuming they want this"
Situation: Seller says "Since you're probably looking for something that scales with your business, our platform supports 10x growth without re-architecting."

**Classification: Advantage.**
Reason: "Probably looking for" is the seller's assumption. No Explicit Need for scalability was expressed. Even if this assumption turns out to be correct, the statement does not meet a *stated* need — it meets an *inferred* one.

---

### Edge Case 3: "The customer nodded and seemed interested when I mentioned it"
Buyer engagement, enthusiasm, or non-verbal cues do not convert an Advantage into a Benefit. Classification is based on words expressed, not inferred intent. A customer who seems interested in a capability they haven't asked for is responding to an Advantage. If they then say "Yes, that's exactly what we've been looking for," that statement IS an Explicit Need — and the next product statement you make that addresses it can be a Benefit.

---

### Edge Case 4: "We always include this in our deck as a Benefit"
Common in marketing-produced collateral. Statements like "Reduce costs by 30%" or "Cut time-to-insight in half" are Advantages — they show the product can help, but they do not meet an expressed Explicit Need. No prospect's Explicit Need is present in a deck that hasn't been customized to a specific buyer's stated requirements.

Exception: If you are auditing a deck against a specific deal's `needs-log.md` and a matching Explicit Need is documented, you can reclassify the statement as a Benefit in that context. Without that deal-specific Explicit Need, classify as Advantage.

---

### Edge Case 5: "The customer said they want to improve efficiency"
"Improve efficiency" is usually still vague enough to be borderline. If the customer said "We want to improve efficiency" with no specifics, it is a very general Explicit Need. A matching Benefit would need to show how the product improves efficiency in the specific way the customer described. If the product statement is specific and the customer's Explicit Need is general, look for closer matches.

**Rule of thumb:** The more specific the Explicit Need, the more clearly a matching product statement qualifies as a Benefit. "We need to cut our monthly close process from 5 days to 2" → a statement showing the product achieves this = unambiguous Benefit.

---

### Edge Case 6: "A cost fact followed by context"
"Our system costs $42,000 — which is 30% less than the industry average" — the first part is a Feature (cost fact), the second part is an Advantage (shows comparative value). If the customer had said "We need something under $50,000" before this, then "our system at $42,000 meets your budget" would be a Benefit.

---

## FAB Distribution Norms

From Rackham's research on typical sales calls:

| Behavior | Typical distribution | Impact in large sales |
|---|---|---|
| Features | ~40-50% of product statements | Neutral to mildly negative; creates price sensitivity |
| Advantages | ~40-50% of product statements | Not linked to success; creates objections |
| Benefits | ~5-15% of product statements | Strongly linked to success; generates approval |

A typical pitch deck audited against this framework will show 0-10% true Benefits, 40-60% Advantages, and 30-50% Features. This is normal — not a failure of the sales team, but a structural limitation of content created without specific deal context. The audit's purpose is to surface this gap and guide the seller on which Advantages to convert into Benefits before the next call.

---

## The FAB → Customer Response Chain (Chapter 6)

Rackham's colleague Linda Marsh identified the most probable customer responses to each type:

| Seller uses | Most probable customer response |
|---|---|
| Features | Price concerns / price sensitivity |
| Advantages | Objections (value challenges, "not worth it," "don't need that") |
| Benefits | Support, approval, positive buying statements |

This chain explains why objection-heavy calls are usually high-Advantage calls: the seller is offering solutions before the customer has expressed a want, so the customer raises the value question themselves. The prescription is not better objection-handling techniques — it is better need development so that product statements become Benefits rather than Advantages.

---

*Source: SPIN Selling by Neil Rackham (1988), Chapters 5–6. Part of the BookForge SPIN Selling skill set — licensed CC-BY-SA-4.0.*


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)