/19-research-the-market

name: research-the-market
description: "Go outside the founder brief and research the real market before the plan is written: the exact communities, newsletters, and venues where the user's ICP already sits, how comparable products launched and what worked, the problem in strangers' own words, and the rivals and openings the user never mentioned. Saves docs/gtm-cofounder/market-research.md with a link for every finding. Use right after start-here and before strategy-and-roadmap, before picking channels in first-50-users or planning launch-it, or whenever the plan feels like it only repeats what the user already said."

Research the market (what you didn't tell me)

> The brief is what you know. A plan built only from the brief can only rearrange your own answers back to you. This is the step where the agent goes out and finds what you don't know yet: where your users actually are, how products like yours got their first users, and the openings you haven't seen.

**Use this when:** you've just written the brief and want a plan grounded in the real market, not just your own read. Or you're about to pick channels or plan a launch and "post on Reddit and HN" is the best idea on the table. Or the roadmap you got back felt like a tidy summary of what you said.

The core idea

The interview pulls out what's in your head. Research brings in what isn't: the specific subreddit where your ICP complained about this exact problem last week, the newsletter they all read, the three products in your space that launched in the last two years and what actually brought their first users, the competitor you didn't name.

**Research is planning-grade evidence, not proof.** Public evidence that 40 people asked for this in a GitHub issue is strong enough to plan a channel around. It is not strong enough to call the pain validated or to set a price. So it gets its own tag, `[researched]`, between `[assumption]` and `[validated]`. Only a real conversation with a real user who is not a friend earns `[validated]`.

Before you start: can your agent see the web?

• **If your agent can browse or search the web,** it runs the research for real, and every finding carries a link.
• **If it can't,** it says so up front and hands you a short list of exact searches to run (8 to 12, each a copy-paste query with what to look for). You paste back what you find, and it does the analysis. Same output, you're the browser.

Never fake it. An agent without web access that writes up "communities" from memory is guessing, and invented member counts and dead links destroy trust fast.

How to run this (for the agent)

• **Start from the brief.** Read `docs/gtm-cofounder/founder-brief.md`: the product, the ICP, the alternatives, the stage. That sets what to search for. Then go further than the brief, on purpose.
• **Check the ICP is concrete enough to research.** "Developers" can't be researched; "platform engineers at 50 to 500 person companies running Kubernetes" can. If the ICP is vague, run the research anyway, but aim it at *which segment shows the most pain in public*, and hand that finding to `who-is-this-for`.
• **Every finding has a link and a date.** No link, it doesn't go in. Never invent a community, a member count, a URL, a quote, or a launch result. If you can't verify a number, say "size unknown" rather than estimating.
• **Name venues, never categories.** "Reddit" is not a finding. "r/devops, where three threads in the last month asked for exactly this" is.
• **Rank by fit, not size.** A 4,000-member Discord where your ICP talks about the problem weekly beats a 2 million member subreddit where they never do. For each venue, record the evidence that *your* ICP is there talking about *this* problem.
• **Check the rules of the room.** For every community, note whether it allows self-promotion, and how (a weekly thread, a flair, an outright ban). A channel that bans you on your first post is not a channel.
• **Keep it bounded.** This is a sprint, not a thesis: roughly 20 to 40 searches, an hour of agent time at most. Stop when new searches stop changing the picture.
• **Lead with surprises.** The most valuable part is what the founder didn't say. Put "What I found that you didn't tell me" at the top of the file, and flag anywhere the research disagrees with the brief (they said their users hang out on X, the evidence says Y).
• **Don't rewrite the brief yourself.** Where the research contradicts or sharpens a brief answer, propose the change, and let the founder accept it. Accepted changes go into the brief tagged `[researched]` with the date.
• **Then hand off.** If there's no roadmap yet, go to `strategy-and-roadmap`, which now has to use this file. Offer, never impose.

The five things to find

1. Where your ICP already sits (the watering holes)

Find the 5 to 10 specific places your ICP already goes to discover tools and talk shop. Ways in:

• Search the problem in their words, plus "reddit", "discord", "slack", "forum". Note which rooms keep coming up.
• Search Hacker News (`site:news.ycombinator.com`) for the category and the named alternatives. Who comments, and what do they ask for?
• GitHub: topics, awesome-lists, and the issue trackers of the alternatives. An issue with 50 thumbs-up asking for what you built is a venue *and* a lead list.
• Newsletters, podcasts, and YouTube channels covering the category. Who has the ICP's attention every week?
• Where competitors show up: what they sponsor, which conferences they speak at, which communities their founders post in. Sponsorship spend is a public tell for where they believe the buyers are.
• Integration marketplaces and ecosystems the product plugs into (VS Code, a framework's plugin directory, a cloud marketplace, a Slack app directory).

For each venue: name, link, size and activity signal (members, posts per week, last active), self-promo rules, and the evidence your ICP is there talking about this problem.

2. How comparable product