Writing Comparison Pages

Structure every comparison page around this ratio: 70% "here's how we think differently" vs 30% direct feature comparison. Never spend more than one sentence disparaging a competitor's weakness — state the fact, then pivot immediately to your differentiation.

Bad: "Competitor X is clunky, outdated, and their support team is notoriously unresponsive."

Good: "Competitor X is built for enterprise IT teams running complex workflows. We built [Product] for small teams who need to ship in days, not months."

Progress:

• Identify the real buyer question behind the comparison ("which one is right for me" not "which one is better")
• List 3-5 genuine differentiators (not marketing fluff — actual product/philosophy differences)
• Write a neutral positioning statement for the competitor
• Build comparison table with factual, verifiable claims only
• Add "choose us if / choose them if" section
• Remove any adjectives that wouldn't survive a public fact-check
• Have someone unfamiliar with the product read it and flag anything that feels like bashing

Step-by-step:

1. Start with the buyer's job-to-be-done, not the competitor's flaws. Open with "If you're evaluating X and Y, here's how to think about it" rather than "Why X beats Y."

2. Describe the competitor accurately first. State what they're good at and who they're built for. This builds trust and makes your differentiation credible.

3. Differentiate on philosophy/approach, not just features. Feature checklists age badly and invite nitpicking. "We optimize for speed of setup; they optimize for depth of customization" is more durable than "We have 12 integrations, they have 8."

4. Use a comparison table for facts, not opinions. Pricing, platform support, integration counts — verifiable things. Keep subjective claims in prose where they can carry nuance.

5. Add a "choose them if" section. Explicitly naming scenarios where the competitor is the better choice is the single strongest trust signal on the page. It also pre-qualifies leads, reducing churn.

6. End with proof, not claims. Customer quotes, migration stories, or trial CTAs — not another round of "we're better because."

Example 1: Input: "Write a comparison section against [Competitor], a legacy project management tool, for our modern lightweight alternative."

Output:

[Competitor] vs [Product]: Which fits your team?

[Competitor] has been the standard for project management at large organizations for over a decade, with deep customization and admin controls built for IT-managed rollouts.

[Product] was built for small, fast-moving teams who want to be running projects in minutes, not after a weeks-long implementation.

Choose [Competitor] if: you need granular permission structures, have a dedicated admin to manage the tool, or are standardizing across a 500+ person org.

Choose [Product] if: you're a team of 2-50, want to self-serve onboarding, and prioritize speed over configurability.

Example 2: Input: "They're slower and their UI looks dated — can we say that?"

Output: Reframe as fact + context, not insult: "[Competitor]'s interface reflects its enterprise roots — built for dense data views across large teams. If you want a lighter, more visual workflow, that's where [Product] differs." Avoid "dated" or "slower" as standalone adjectives; if speed is a real, measurable differentiator, cite a benchmark instead of asserting it.