Competitive Teardown skill for Codex

A teardown is done well when it compares products on the same customer task, every claim cites a dated source or screenshot, the feature matrix distinguishes “has it” from “does it well”, and the report ends with implications for our product rather than a tour of theirs.

Ground rules

• Use public information (website, docs, pricing page, changelog, app store listings, public reviews, public talks) and trial accounts signed up honestly under the competitor’s terms of service.
• Do not impersonate a customer to extract sales materials, bypass paywalls, scrape against terms, or use leaked or confidential documents.
• Record the date for everything; products change monthly.
• Facts and opinions are labelled separately. Teardowns get shared; avoid disparaging language that would embarrass the team if a competitor read it.

Codex usually cannot browse or create accounts on its own in a sandbox with network off; the user supplies screenshots, recordings, exported pages or notes, or enables network access for public pages. Account sign-up and any terms acceptance are done by the user.

Pick the lens

Goal	Focus
Losing deals to them	Buying journey, pricing, sales claims, the features prospects cite
Losing activation / trials	Signup, onboarding, time to first value
Planning a feature they have	That workflow end to end, edge cases, settings, docs
Positioning refresh	Homepage, messaging hierarchy, category language, proof points

State the lens and the customer task in the report header. A teardown without a task becomes a screenshot album.

Teardown sections

1. Positioning

• Homepage headline, subhead and primary call to action (quoted with date).
• Who they say it is for; category name they use; top three claimed benefits.
• Proof: logos, numbers, case studies. Note which claims are verifiable.

2. Signup and onboarding

Record each step:

| # | Screen | User action | Required fields | Time | Notes |
|---|---|---|---|---|---|
| 1 | Signup | Email + password or Google | 2 | 0:20 | No credit card |
| 2 | Role survey | Pick role, team size | 2 | 0:15 | Drives template choice |
| 3 | Template picker | Choose "Marketing" | 1 | 0:10 | Preview on hover |
| 4 | Invite prompt | Skip | 0 | 0:05 | Skippable, returns on day 2 |
First value moment: sees populated board with sample tasks at step 3 (0:45 total)

Note emails received over the following days (timing, subject, call to action).

3. Core workflow on the shared task

Do the same realistic task in both products (ours and theirs), e.g. “plan a two-week campaign with four people”. Count steps, clicks, time, errors and dead ends. Capture where each product needed docs or help.

4. Feature and packaging matrix

Rate depth, not just presence:

Capability	Them	Us	Notes
Recurring tasks	Strong: custom rules, skip holidays	Basic: daily/weekly only	Cited in 3 lost deals
Guest access	Paid add-on, Business plan	All paid plans	Pricing page, 2026-10-12
API	Read/write, rate limit 100/min	Read/write, 300/min	Their docs

Scale: none, basic, adequate, strong, with a note on what makes it so.

5. Pricing and limits

Plan names, prices (monthly vs annual), value metric, free tier limits, gated features, overage rules. Note how they push upgrades (limits hit, trial expiry, feature gates). Pricing decisions for us belong in $pricing-strategy.

6. UX patterns

List patterns worth adopting and ones to avoid, each with a screenshot reference and the reason. Copying a pattern because a competitor has it is not a reason; explain the user problem it solves.

7. Market signals

Changelog cadence and recent themes, public reviews (common praise and complaints with counts), job postings that hint at direction. For ongoing monitoring rather than a one-off teardown, use $competitive-intelligence.

Workflow

- [ ] 1. Agree lens, competitor(s), and the shared customer task
- [ ] 2. Collect public sources with dates; user creates trial accounts if needed
- [ ] 3. Walk signup and onboarding; log steps and times
- [ ] 4. Run the shared task in both products; log steps and friction
- [ ] 5. Fill the feature matrix with depth ratings and sources
- [ ] 6. Capture pricing, positioning and patterns
- [ ] 7. Write strengths, weaknesses and implications for us

Report template

# Teardown: <competitor> - <lens>
Date: <date> | Version/plan tested: <...> | Task: <shared customer task>

## Summary (5 bullets: where they win, where we win, what to do)
## Positioning
## Onboarding walkthrough (table, time to first value)
## Shared task comparison (steps, time, friction: them vs us)
## Feature matrix (depth-rated, sourced)
## Pricing and packaging
## Patterns to adopt / avoid
## Implications for us
| Implication | Evidence | Suggested action | Confidence |
## Sources (dated links, screenshot index)

Gotchas

• Comparing their best-case demo to our real product is unfair in both directions; use the same task and the same plan tier.
• Feature checklists reward breadth; customers buy depth on the few things they use.
• Review sites skew to extremes; report counts and themes, not cherry-picked quotes.
• Screenshots and recordings may include personal data from sample workspaces; keep them internal.
• A teardown ages quickly; put the date in the title and a “revisit by” date in the header.

Verification

Check that every row in the feature matrix and pricing section cites a dated source or screenshot, the shared task was run in both products under comparable conditions, facts and opinions are labelled, and each implication links back to specific evidence in the report.