Section 1
Why this is a teardown, not a literature search
There are two ways to research competitors and they produce different artifacts. The deep design research workflow on this site reads what has been written — articles, reviews, documentation, analyst takes — and synthesizes it into a brief. A teardown walks the products themselves: signs up, clicks through onboarding, screenshots the pricing page, counts the steps, and records what the product actually does rather than what anyone says about it.
Teams need both, and they get into trouble when they substitute one for the other. A literature search will tell you a competitor is loved for its onboarding; only a teardown tells you it is a three-step flow that defers account creation until after the first project is made. This workflow is the second kind, and it deliberately treats marketing copy as a claim to verify rather than a fact to record.
The work is evidence collection at a scale one designer does not enjoy: five to eight competitors, each with an onboarding flow, a pricing page, a positioning story, and a handful of core flows worth capturing. One agent per competitor collects evidence into a folder; an extraction agent pulls patterns across the folders; claims that came from marketing copy get cross-checked against what the walkthrough actually showed.
Section 2
When to reach for this workflow
Reach for it when a design decision depends on knowing what the rest of the category actually does: before designing onboarding or pricing pages, when positioning is being rewritten, when an agency is preparing pitch research on a client's category, or when the team suspects its mental model of the competition is two years out of date.
Do not reach for it to settle strategy by imitation. The output is a map of what exists and where the gaps are; deciding whether a gap is an opportunity or a graveyard is a product judgment the matrix cannot make.
- Onboarding redesigns: how the category handles signup, first value, and activation.
- Pricing and packaging work: tiers, anchors, what is gated, and how the page argues for the upgrade.
- Positioning refreshes: what each competitor claims, and whether the product backs the claim.
- Agency pitch research: a structured read of a prospective client's category in an afternoon.
Section 3
Decide what evidence counts before you collect any
A teardown drifts into screenshot hoarding unless the dimensions are fixed up front. Pick the dimensions the design decision needs — onboarding steps, pricing structure, key flows, positioning claims — and define what evidence each requires. Every cell in the eventual matrix should trace to a file in a competitor's evidence folder.
Be deliberate about access and ethics. Use trial accounts and public pages, respect terms of service, never misrepresent who you are to get access, and keep competitor screenshots as internal evidence rather than republishing them. If a competitor requires a sales call to see the product, record that as a finding about their go-to-market, not a gap in your evidence to fill by other means.
# Teardown dimensions: PM tools onboarding, June 2026 Every competitor folder must contain evidence for each dimension, or a note explaining why it could not be collected (paywall, sales-gated, region-locked). ## ONBOARDING - Ordered screenshots from signup to first meaningful action. - Step count, required fields, whether account creation can be deferred. - Time from signup to an empty-state or template choice. ## PRICING - Full-page screenshot of the pricing page. - Tiers, prices, billing toggle, what is gated at each tier, trial terms. ## POSITIONING - Homepage headline and subhead, verbatim. - The three claims the marketing leans on hardest (verbatim, with URL). ## CORE FLOWS - Screenshots of: creating the first project, inviting a teammate, the main board or list view. ## CLAIM CROSS-CHECK - For each positioning claim: what the walkthrough showed (supports, contradicts, could not verify).
Section 4
The orchestration pattern: one agent per competitor
This runs as a Claude Code dynamic workflow: a JavaScript script Claude writes and runs in the background, orchestrating subagents while intermediate results — every evidence manifest, every per-competitor summary — stay in script variables rather than Claude's own context. That is what lets eight competitors get the same systematic treatment instead of detailed notes on the first three and a shrug for the rest.
Each competitor gets a collection agent that fills its evidence folder against the dimensions file, working from the live products via Playwright (or a capture script you run for anything behind a login) plus public pages via WebSearch where dates and announcements matter. Workflows can run up to 16 agents concurrently and up to 1,000 per run, runs are resumable, and the prompt becomes reusable once saved to .claude/workflows/ in the project (or ~/.claude/workflows/ personally) — most teams save it as /teardown. You trigger a run by including the word workflow in the prompt or via /effort ultracode; if your teardown leans heavily on published sources rather than walkthroughs, the bundled /deep-research workflow command (which requires WebSearch) is the better starting point, and the two pair well. The collector and extraction agents are defined in .claude/agents/*.md.
After collection, an extraction agent reads every folder and pulls cross-competitor patterns; a cross-check agent then audits any cell whose evidence is marketing copy rather than an observed walkthrough, and marks it supported, contradicted, or unverified. Only then does the comparison matrix get assembled.
Design decision
Pick competitors and dimensions
Design decision
Collect evidence per competitor
Design decision
Extract patterns
Design decision
Cross-check marketing claims
Design decision
Build comparison matrix
Design decision
Name opportunity gaps
Design decision
Team review
Per-competitor collection feeds extraction and a marketing-claim cross-check before the matrix and gaps are written.
Section 5
The workflow prompt
The prompt names the competitors, the dimensions file, where evidence lands, and the rule that does the most work: every matrix cell cites evidence, and cells sourced from marketing copy are labeled as claims until the cross-check confirms them.
Run this as a workflow. Input: ./competitors.json lists 5 project-management tools with their URLs and trial-account notes. ./dimensions.md defines what evidence each competitor folder must contain. Evidence I captured behind logins is already in ./evidence/<competitor>/ ; public pages may be visited and captured with Playwright, and WebSearch may be used for pricing changes and launch dates. Stage 1 - Collection: For each competitor, launch one agent that fills ./evidence/<competitor>/ against dimensions.md: ordered onboarding screenshots, the pricing page, verbatim positioning claims with URLs, and the core-flow captures. It writes a manifest.md listing every file, what it shows, and the date collected. Anything that could not be collected is recorded with the reason, not guessed. Stage 2 - Extraction: One agent reads all folders and extracts cross-competitor patterns: onboarding step counts and sequence patterns, pricing structures and anchors, positioning themes, and recurring UI patterns worth naming in the pattern library. Stage 3 - Cross-check: One agent audits every extracted statement whose evidence is marketing copy rather than an observed walkthrough, and labels it supported, contradicted, or unverified, citing the walkthrough evidence either way. Output: comparison-matrix.md (competitors as columns, dimensions as rows, every cell citing evidence files), pattern-library.md (named patterns with which competitors use them), gaps.md (things no competitor does well, with the evidence that suggests it), and unverified-claims.md. Do not include any cell without evidence; write 'not collected' instead.
Section 6
What the orchestration script roughly does
Claude writes the orchestration script when the prompt runs; the sketch below shows the shape with an agent() pseudo-API so you can see where the per-competitor fan-out, extraction, and cross-check sit. It is illustrative, not the literal generated code.
const fs = require("node:fs")
const competitors = JSON.parse(fs.readFileSync("./competitors.json", "utf8"))
const dimensions = fs.readFileSync("./dimensions.md", "utf8")
// Stage 1: one collection agent per competitor fills its evidence folder.
const manifests = await Promise.all(
competitors.map((c) =>
agent(
"Collect teardown evidence for one competitor into ./evidence/" + c.slug + "/.\n" +
dimensions +
"\nCompetitor: " + c.name + " (" + c.url + "). Use the captures already in the " +
"folder, public pages via Playwright, and WebSearch for dates and pricing news. " +
"Write manifest.md listing every file, what it shows, and the collection date. " +
"Record what could not be collected and why; never invent evidence.",
{ model: "sonnet" }
)
)
)
// Stage 2: extraction agent pulls cross-competitor patterns.
const patterns = await agent(
"Extract cross-competitor patterns (onboarding, pricing, positioning, UI patterns) " +
"from these evidence manifests. Cite the evidence file for every statement.\n" +
JSON.stringify(manifests),
{ model: "opus" }
)
// Stage 3: cross-check agent audits anything sourced from marketing copy.
const checked = await agent(
"Audit every statement whose source is marketing copy. Label each supported, " +
"contradicted, or unverified, citing walkthrough evidence.\n" + patterns,
{ model: "opus" }
)
fs.writeFileSync("./output/comparison-matrix.md", checked)Section 7
Define the collector as a subagent
The collector's rules — evidence over claims, manifests over memory, gaps recorded rather than filled in — belong in a subagent definition under .claude/agents/ so every teardown applies the same standard.
--- name: competitor-collector description: Collects teardown evidence for one competitor into its evidence folder, against the shared dimensions file. tools: Read, Glob, Bash, WebSearch model: sonnet --- You collect evidence for exactly one competitor. Rules: - Follow the dimensions file; every dimension gets evidence or an explicit note on why it could not be collected. - Prefer what the product shows over what the marketing says. Record marketing claims verbatim, with URLs, labeled as claims. - Name files predictably: onboarding-01.png, onboarding-02.png, pricing-page.png, flow-create-project.png. - Write manifest.md: every file, what it shows, the URL or screen it came from, and the collection date. - Stay within terms of service: trial accounts and public pages only; never misrepresent who you are. - Never invent, estimate, or fill in evidence you did not collect.
Section 8
Step by step through one teardown
Pick the competitors with the team and write the dimensions file from the design decision at hand; a teardown without a decision behind it becomes a museum. Create trial accounts yourself and capture anything behind a login with the capture script, since that is faster and cleaner than having an agent negotiate signup forms.
Run the workflow and let collection, extraction, and cross-check finish; for five competitors the run typically lands inside an hour, and the full teardown including your review fits in two to four hours. Read unverified-claims.md and gaps.md before the matrix — the edges of the evidence are where teardown conclusions go wrong.
Then do the human work: open a sample of evidence files and confirm the matrix cells they support, decide which gaps are opportunities and which exist for good reasons, and write the one-page recommendation the matrix cannot write. Archive the evidence folders with the matrix; the next teardown of this category starts by diffing against them.
Run the teardown
Verify sampled evidence
Decide on gaps
Ship the design work
Archive evidence
Re-run next quarter and diff
feeds next cycleTeardowns age quickly; the archived evidence makes the next pass a diff rather than a restart.
Section 9
Case study: onboarding in five project-management tools
A team redesigning onboarding tore down five project-management tools in an afternoon. The matrix made the category's shape obvious: step counts from signup to first meaningful action ranged from 4 to 11, three of five tools deferred team invitations until after the first project existed, and the two tools with the shortest paths both opened into a populated template rather than an empty state.
The cross-check earned its keep on positioning. Two competitors claimed AI-powered setup on their homepages; the walkthroughs showed one generated a real project structure from a text prompt while the other relabeled its existing template picker. The matrix recorded both claims verbatim and both observations, which kept the team's planning discussion grounded in what users would actually meet.
The gaps file surfaced the opportunity the team pursued: no competitor handled the second teammate's first-run experience well — every tool designed onboarding for the account creator and dropped invitees into a bare board. That became the focus of the redesign, and the archived evidence folders became the baseline for a re-run two quarters later.
Section 10
Case study: a pricing-page teardown across eight SaaS competitors
A B2B team rewriting its pricing page tore down eight competitors' pricing pages and upgrade flows. Eight collection agents ran concurrently; the human time went into verifying the matrix and arguing about what it meant. The structural findings were quick: seven of eight used a three-tier layout with the middle tier visually anchored, six gated SSO behind the top tier, and annual-billing toggles defaulted to annual on five of eight pages.
The more useful findings came from walking the upgrade flows rather than the pages: three competitors advertised transparent pricing but routed any team above 25 seats to a sales form, and one published price did not match the price shown in the in-product upgrade dialog. Both went into unverified-claims.md with screenshots, and the second one reshaped the team's assumption about what the category considered acceptable.
The team kept three tiers but moved SSO down a tier as a deliberate wedge, and wrote the page so that the seat threshold for sales contact was stated up front. Six months later the teardown re-ran as a saved /teardown command; the diff showed two competitors had copied the SSO move, which was its own kind of validation.
Section 11
Case study: agency pitch research on a retail client's category
An agency preparing a pitch for a grocery retailer's loyalty program tore down the loyalty and checkout experiences of six retailers in the client's market — mobile flows, signup, points visibility, and offer redemption — using public apps and store-locator-level accounts. The constraint was time: the pitch was nine days out and the strategist had two days for category research.
The teardown produced a comparison matrix, a pattern library of twelve named patterns (points-at-checkout placement, offer-clipping flows, tier celebration moments), and a gaps page showing that only one competitor surfaced points value in currency terms before checkout. The agency built the pitch's central argument on that gap, illustrated with its own concept work rather than competitor screenshots, and used the matrix as an appendix that demonstrated rigor without giving the thinking away.
The cross-check mattered for credibility in the room: when the client pushed back that a named competitor already does this, the strategist could answer from the evidence folder — the competitor's marketing said so, the walkthrough showed points expressed only as abstract stars until the receipt. The agency won the work, and the dimensions file was reused as the starting point for the discovery phase.
Section 12
Good vs bad teardown output
A matrix cell is useful when someone can open the evidence behind it and see the same thing. The recurring failure is laundering marketing claims into observed facts; the second is filling cells the evidence does not cover because an empty cell looks like unfinished work. Both are worse than a cell that says not collected.
Competitor A has the best onboarding in the category
Competitor A: 4 steps from signup to a populated template; team invite deferred until after first project (onboarding-01..04.png, manifest dated 2026-06-02)
Competitor B offers AI-powered project setup
Competitor B claims AI-powered setup on its homepage (URL, verbatim); the walkthrough shows a template picker with no generation step - claim marked contradicted
All competitors offer transparent pricing
3 of 8 route teams above 25 seats to a sales form despite a published per-seat price; screenshots in evidence, listed in unverified-claims.md
Pricing for Competitor F: approximately $30 per seat (not collected, estimated)
Competitor F pricing: not collected - page is region-locked and the trial requires a sales call; recorded as a go-to-market observation
Evidence-linked cells can be checked; claims and guesses cannot.
Section 13
Limits: what a teardown cannot prove
A teardown shows what competitors built, not why, and not whether it works for them. A pattern shared by seven competitors might be a best practice or a herd error; usage data, churn, and strategy are invisible from the outside, and the matrix should never be read as evidence that a pattern performs.
The evidence also decays. Pricing pages change without notice, onboarding gets rebuilt, and a teardown older than a quarter is a historical document. Date every manifest, treat the archive as a baseline to diff against, and re-run before any decision that leans on the matrix heavily.
Humans own the judgment and the ethics: which gaps are opportunities rather than graveyards, what a fair reading of a competitor's product is, how competitor material is used inside the company, and what is appropriate to show externally. The workflow collects and organizes; it does not decide.
- Cannot explain why a competitor made a choice, or whether it is working for them.
- Cannot see usage, conversion, or retention; structure is not performance.
- Cannot stay current; evidence is dated and decays within a quarter.
- Cannot decide which gaps are worth pursuing; that is a product judgment.
Section 14
The reusable teardown workflow
Save the prompt to .claude/workflows/ as /teardown and the collector definition to .claude/agents/. With the dimensions file and the archived evidence in the repo, the next pass on the same category is a diff that takes an hour, not a fresh project.
1. Name the design decision the teardown serves and pick 5-8 competitors with the team. 2. Write the dimensions file: what evidence every competitor folder must contain. 3. Capture anything behind a login yourself; agents handle public pages and trials. 4. Run the workflow: one collection agent per competitor, each writing a dated manifest. 5. Extract patterns across folders, then cross-check every claim sourced from marketing copy. 6. Verify a sample of matrix cells against their evidence files by hand. 7. Decide which gaps are opportunities; write the one-page recommendation yourself. 8. Archive the evidence folders and matrix; re-run and diff before the next major decision.
Sources

