Feature descriptions are benefit-focused

A features section that lists only capabilities without explaining their value puts the persuasion burden entirely on the visitor. "Automated backups" tells the visitor what exists; "Automated backups — your work is saved continuously so you can focus on building, not recovery" tells them why it matters. When fewer than 60% of feature descriptions include a benefit framing, the section reads like a spec sheet rather than a sales argument. Visitors who do not see themselves reflected in the copy — because benefits are absent — conclude the product wasn't designed for people like them. The feature-to-benefit translation is the marketer's job, not the visitor's.

For each feature description, add a sentence that completes: "This means you can [benefit]" or "So you never have to [pain] again." You do not need to rewrite everything at once — start with the 3 features most relevant to your primary customer and add benefit framing to those first.

Transformation template:

Before: "Automated backups"
        "We back up your data automatically."

After:  "Automated backups"
        "Your work is saved continuously so you can focus on building,"
        "not recovery."

In practice: find the features component (components/Features.tsx, components/FeatureGrid.tsx, or equivalent). Each feature card typically has a title and description prop. Extend the description string to include the benefit clause. If features are defined in a data array (const features = [...]) or a content file, update the source there.

• ID: marketing-content-quality.value-proposition.feature-benefit-framing

• Severity: high

• What to look for: Locate the features section (commonly a grid or list of feature cards after the hero). Count every distinct feature description (cards, list items, or grid entries that describe individual features or capabilities). For each one, classify it: does it state what the user gets (an outcome, a benefit, a problem solved) or does it only describe what the product has (a capability, a technical attribute)? Look for benefit signals like "so you can", "which means", "never worry about", or direct statements of user value.

• Pass criteria: Count feature descriptions and report the ratio: "X of Y feature descriptions include benefit framing." Pass if the ratio is at least 0.6 (60% or more include a user benefit or outcome alongside the feature description). A partial or placeholder implementation does not count as pass.

• Fail criteria: Fewer than 60% of feature descriptions mention a user benefit. Report the ratio. Example failing pattern: "2 of 8 feature descriptions include benefit framing (25%). Remaining 6 are capability-only labels like 'Automated backups', 'Multi-region support', '99.9% uptime SLA' with no explanation of what these mean for the user."

• Skip (N/A) when: No features section detected (project has no marketing content — API-only or dashboard-only). Signal: no feature grid, feature list, or equivalent marketing section in any page component.

• Detail on fail: Report the ratio and quote an example. Example: "3 of 9 feature descriptions include benefit framing (33%). Example: 'Automated backups' has no benefit — doesn't explain what the user gets."

• Remediation: Features tell visitors what your product has. Benefits tell them why they should care. For each feature, add a sentence that completes: "This means you can [benefit]" or "So you never have to [problem] again."

  Example transformation:

  • Before: "Automated backups — We back up your data automatically."
  • After: "Automated backups — Your work is saved continuously so you can focus on building, not recovery."

  You don't need to rewrite every feature in one pass. Start with your top 3 features (the ones that matter most to your target user) and add benefit framing to those first.

  Review the configuration in src/ or app/ directory for implementation patterns.