---
name: market-research
description: Conduct market research, competitive analysis, and industry intelligence. Use when the user wants market sizing, competitor comparisons, OSS landscape scans, distribution analysis, or research that informs build-or-skip decisions.
origin: ECC (adapted)
---

# Market Research

Produce research that supports build-or-skip decisions, not research theater.

## When to Activate

- evaluating whether a market is worth entering
- sizing a market opportunity
- comparing competitors, adjacent products, or OSS alternatives
- researching a technology, vendor, or infrastructure choice
- pressure-testing a thesis before building or entering a market
- validating pricing before writing code

## Research Standards

1. Every quantitative claim must have a `[SOURCE: ...]` tag or be labeled `[ESTIMATE]`.
2. Prefer recent data. Flag anything older than 18 months as `[STALE]`.
3. Steel-man the opposite conclusion.
4. Translate findings into a decision, not just a summary.
5. For each key assumption, state what evidence would falsify it.
   Example: "Assumption: ML engineers will pay for managed experiment tracking. Kill condition: >60% of community threads recommend self-hosted and cite cost as primary reason."

## Research Modes

Default to **Market Sizing + Competitive Landscape**. Add other modes only when the question demands them.

### Market Sizing

Three lenses, plain language:

- **TAM** (Total Addressable Market) — everyone who could theoretically use this. The ceiling.
- **SAM** (Serviceable Addressable Market) — the slice you can actually reach with your product's scope and geography.
- **SOM** (Serviceable Obtainable Market) — what you can realistically capture in 1-2 years given your distribution, pricing, and team size.

For each:
- state the number and the assumption behind it
- use top-down data (reports, public datasets) cross-checked with bottom-up math (realistic customer counts x price)

Anchor SOM to the go-to-market motion:
- **Solo/indie**: "How many paying users can I reach through channels I can operate alone, at what price?"
- **B2B/enterprise**: "How many teams can I reach given sales cycle length, integration complexity, and deal size?"

### Competitive & OSS Landscape

Collect:
- product reality, not marketing copy
- OSS alternatives (GitHub activity, contributor health, license, adoption curve)
- funding history if public (signals runway and priorities, not a scorecard)
- traction signals (users, revenue, community size) if public
- pricing and packaging
- strengths, weaknesses, and positioning gaps
- build vs. buy vs. fork trade-off for the user's context

Distribution:
- where target users already congregate (communities, forums, marketplaces, conferences)
- realistic customer acquisition cost for the user's go-to-market motion
- existing distribution moats (integrations, marketplaces, API ecosystems)

### Pricing Analysis

Requires user-provided data (links, screenshots, forum threads) for specifics beyond known market structure.

Analyze:
- what do people currently pay for similar solutions?
- pricing tiers and anchoring in the category
- free vs. paid boundary — what features cross the pay threshold?
- for B2B: typical contract size, procurement friction, budget owner

### Technology / Vendor Research

Collect:
- how it works (architecture, key trade-offs)
- adoption signals and ecosystem health
- integration complexity
- lock-in risk, data portability, and exit cost
- security, compliance, and operational burden
- cost trajectory at scale

## Output Format

Default structure:
1. **Decision summary** — build, skip, or investigate further, in one paragraph
2. **Key findings** — with `[SOURCE: ...]` or `[ESTIMATE]` tags on quantitative claims
3. **Assumptions & falsifiability** — each key assumption with its kill condition
4. **Risks and counterarguments** — steel-manned opposing view
5. **Recommendation** — concrete next step
6. **Sources** — linked and dated

## Quality Gate

Before delivering:
- all numbers are sourced or labeled as estimates
- stale data is flagged
- the recommendation follows from the evidence
- at least one steel-manned counterargument is included
- key assumptions have explicit kill conditions
- the output makes a build-or-skip decision easier