AIDevGTM/gtm-cofounder

# Start here (your founder brief)

> Every other skill is only as sharp as what the agent knows about *your* business. This is that context. Do it once, and every skill after it gets personal.

**Use this when:** it's your first time here, or the advice you're getting feels generic and textbook because the agent doesn't actually know your product, your users, or your stage.

## The core idea

Answer **five core questions** and the agent writes a **`docs/gtm-cofounder/founder-brief.md`** in your project, enough to give you a real diagnosis and a roadmap in minutes. Everything else is optional and answered as you go: each skill pulls the deeper questions it actually needs, when it needs them, and tells you what answering unlocks. So you start seeing value fast, and the brief gets richer the more you use it, instead of facing a wall of questions on day one.

And the part that matters most: separate what you have **validated** (a real user who is not your friend told you) from what you are **assuming** (your best guess for now). Assumptions are completely fine to start with. They just get sent to `talk-to-users` to become real, so you never build a beautiful go-to-market on a guess.

## How to run this (for the agent)

# Strategy and roadmap (your plan)

> A pile of tactics is not a go-to-market. This turns your brief and the market research into a diagnosis and a prioritized plan, and becomes the one place you come back to when you don't know what to do next.

**Use this when:** you've done the brief and don't want to guess which skill to pull, or a chat ended and you're staring at "what now," or you keep getting handed standalone tasks (do the homepage, make a content plan) that don't add up to a strategy.

## The core idea

The other skills are moves. This is the game plan that decides which move, and when. It does three things:

1. **Diagnose.** Read the brief and the research honestly. Where are you actually strong? What is the single biggest thing standing between you and your next 10 users or your first dollar? Name one bottleneck, not five.
2. **Prioritize by stage.** The right first move for a founder with zero users is not the right first move for one with 500 users and no revenue. Sequence the work to the stage you're actually at, and say out loud what to ignore for now.
3. **Persist.** Write it to `docs/gtm-cofounder/gtm-roadmap.md` so it survives the chat. Next session you read the roadmap, not a dead thread.

# Who is this for?

> "Developers" is not a market. It's a medium. If your ICP doesn't exclude anyone, it isn't one.

**Use this when:** you describe your user as "developers" or "engineering teams," you can't name a person who is clearly *not* a fit, or you're aiming your messaging at the VP of Engineering because they have the budget.

## The core idea

A usable ICP is specific enough that some people are obviously **out**. "Every developer" gives you nothing to say, because a message that speaks to everyone speaks to no one. Sharpen until exclusion is possible.

And in almost every AI/dev-tool sale there is **more than one person**: the developer who adopts is rarely the person who pays. Market to the adopter; sell to the buyer. Confuse the two and you get great meetings and no decisions.

## Framework 1: The personas in the sale (Frankl)

# Talk to users (the TAB system)

> The best marketing to developers comes from talking to developers. That's it. Everything else in this repo is downstream of this skill.

**Use this when:** you've never done a real user interview, your messaging is clever but unverified, or you keep debating the roadmap internally instead of asking the people who feel the pain.

## The core idea

Stand up a **Technical Advisory Board**: 30-50 people who *represent your users and buyers*, not grey-haired advisors telling you how to build. You interview them, on repeat, and let their words become your positioning, roadmap, and homepage copy.

A TAB call is **not a demo and not a sales call.** It's an interview. You never mention the product.

## Framework: the TAB system (Frankl)

# Positioning & story

> Your story is boring without a villain. And you are not the hero of it. The developer is. You're the wise advisor who hands them a better weapon.

**Use this when:** your homepage explains what your product *does* before it names the problem, your positioning is interchangeable with three competitors, or nobody feels any urgency to act now.

## The core idea

Developers don't buy features; they hire a tool to defeat something that's making their life worse. Get the roles right:

- **Hero** = the developer (never the vendor, never the product)
- **Villain** = the undeniable *trend* making the pain worse every day
- **Wise Advisor** = you, arriving with a gift (the product)
- **Inciting event** = the change in the world that forces the hero to act *now*

# Beyond the wrapper (positioning an AI product)

> "AI-powered" is the new "powerful." When the model is a commodity anyone can call, your positioning cannot be the model. It has to be the problem you solve, the trust you earn, and the last mile nobody else does.

**Use this when:** people call your product "just a GPT wrapper," you blend into fifty tools that demo the same thing, buyers worry about accuracy or where their data goes, or you cannot answer "why won't OpenAI or Anthropic just build this?"

> **Not building an AI product? Skip this one.** It is the one skill here that is not for everyone, and nothing else in the pack depends on it. Move straight on to `value-prop-that-converts`. Come back only if the "is this just a wrapper?" question ever lands on you.

## The core idea

Half your competitors have the same model behind them, so the model cannot be your pitch. The "wrapper" objection is not a technology problem, it is a positioning problem: you are being described at the feature level (see `positioning-and-story`), and features that call the same API are interchangeable. The work is to move up a level, to the specific problem, the specific buyer, and the specific reasons a developer would trust you over a weekend prototype and their own API key.

And a hard truth from developer psychology: **developers will test your claims and find the truth.** If you overclaim what the AI does, they will find the case where it fails, and you lose them for good. So in AI, honesty about limits is not a weakness. It is the differentiation.

# The value prop that converts

> "Better" is sloppy thinking. Better how, along what dimension, by how much, proven by whom? Developers test every claim you make. Give them numbers or give them nothing.

**Use this when:** your value prop contains puffery, your claims aren't attributed, or you're trying to make one sentence do the job of two audiences.

## The core idea

Developers have a finely tuned BS detector and they *will* verify you. Specificity is credibility. Every strong dev value prop is: **specific + provable + spoken in their language.**

## Framework: the value-prop rules (Frankl)

1. **Never say "better."** Say better *how*, by *how much*, versus *what*.
2. **Time savings must be specific.** ❌ "saves developer time" · ✅ "8× faster builds, 2 hrs → 15 min" (attributed).

# The homepage

> Write your homepage for the person who actually reads it: the **end-user developer**, not the CTO who signs the check. The developer becomes your champion and sells it internally for you.

**Use this when:** your homepage speaks to buyers/ROI, it's clever but vague about what the thing does, or a developer can't tell in 5 seconds whether to care, and can't start in 5 minutes if they do.

## The core rule (Czakon)

**Address end-user developers on the homepage; put enterprise/ROI/buyer messaging on separate pages** (enterprise, pricing, case studies). If you write the homepage for the buyer, you've written it for someone who isn't there.

## Framework: the sections, in order (Czakon)

1. **Hook / core message**: immediately: what *is* it? Use a category ("CI for monorepos"), a known-incumbent comparison ("a Datadog alternative"), or a plain statement. **Headline = what it is · subhead = for whom / what job.**
2. **Hero**: a real product shot; two CTAs: **Get started** (signup) *and* **Docs**. Answer "what's in it for me?" up top. Lead with the **how**, not the why.

# Time to first value (get them to the first win)

> For a dev tool, the product is the pitch. A developer tries it alone and decides in minutes. Acquisition without activation is just a faster way to lose people.

**Use this when:** people sign up or star the repo and then nothing, they get it working once and never come back, your docs assume the reader already understands it, or you are about to spend on a launch or a channel while the first ten minutes still leak.

## The core idea

You can nail your positioning, your homepage, and your launch, and still lose everyone in the first ten minutes. For a dev tool the first run *is* the sale: the developer tries it, alone, without talking to you, and decides. Two gates, straight from Frankl's DREAM funnel:

- **Evaluation:** can they get it working over a weekend, with zero human help? (the weekend test)
- **Activation:** how fast do they reach their first real win, the "I'm awesome" moment (time to first value)?

Fix this before you scale acquisition. Pouring users into a leaky first run just loses them faster, and `know-if-its-working` will show you that retention, not signups, is the number that matters.

# Your first 50 users

> You don't get your first 50 users by posting more. You get them by going where your users *already* discover tools, and, at the start, by doing things that don't scale.

**Use this when:** you launched to silence, you're spraying every channel hoping one works, or you're about to buy ads to fix a problem ads can't fix.

## The core idea

Every developer audience has an existing **technology-discovery loop**: the specific places they already go to find new tools. Your job isn't to invent demand; it's to position yourself *inside that loop*. And your first cohort is hand-to-hand: the TAB members from `talk-to-users` are your first users.

## Framework: the top of the DREAM funnel (Frankl)

- **Discovery**: be where developers look: the communities, newsletters, influencers, and searches your ICP already uses. Metric: unique humans, not pageviews.
- **Research**: give the interested dev a next step *before they forget you*: newsletter, Discord, free tier, docs. Developers can sit in Research for months, so sustain the relationship.

# Launch it

> Developer communities reward the honest, technical, slightly humble builder and punish the marketer instantly. A Show HN is not an announcement. It's *"I built this thing, here's how it works and what's still rough."*

**Use this when:** you're scared to launch, you're hoping to "go viral," or you're about to drop marketing copy into a room that eats marketing copy for breakfast.

## The core idea

The bar is **usefulness + honesty**, not polish. Developers will test your claims and read your code. Show up as a real engineer sharing real work, be present to answer everything, and never, ever fake it. One genuine launch beats ten hype posts.

## First, learn from launches like yours

Before you pick a venue, read "How comparable products launched" in `docs/gtm-cofounder/market-research.md` (run `research-the-market` if it's missing). Where did products like yours launch, what got upvoted, and what got flamed in the comments? Not every dev tool belongs on Product Hunt, and some belong in a single niche community long before HN. Let the evidence pick the rooms, then use the anatomy below for each one.

# Market to devs, sell to buyers

> The developer who adopts your tool is almost never the person who pays for it. Win the developer's heart; then hand them the ammunition to win the budget conversation for you.

**Use this when:** you have stars, signups, and a beloved free tier, and a revenue line of zero.

## The core idea (Czakon)

**Market to developers, sell to decision-makers.** Developers evaluate and adopt; buyers (CTO/VP/procurement) approve money. Your growth engine is the developer *champion* who sells internally, so your job is to make them look smart to their boss.

## Framework: GTM models that work (Czakon)

Pick the one that fits your product and ICP; don't run all four half-heartedly.

# Pricing (what to charge, and how)

> Price is not a number you pick at the end. It is a positioning decision: it tells the market who you are, what you replace, and how much you believe you are worth. Get it from evidence, not fear.

**Use this when:** you are guessing at a price, you priced on a gut feeling and now feel stuck with it, you don't know where the free line goes, developers use it and nobody pays, or you believe "developers won't pay for this" so you have never charged at all.

## The core idea

Three decisions, in order. Most founders skip to the third and wonder why nothing converts.

1. **The value metric** (what you charge *per*). The single most important pricing decision. Get this wrong and no tier structure saves you.
2. **The packaging** (what is free, what is paid, what is enterprise, and what triggers the upgrade).
3. **The number** (the actual price on each tier).

# Founder-led sales (close your first customers yourself)

> Nobody can sell it before you can. The first ten deals are not a hire, they are how you learn what you are actually selling and to whom. Do them yourself, badly at first, until the motion repeats.

**Use this when:** developers love it and live in the free tier but nobody pays, you have never sold anything and freeze on the actual conversation, every deal dies on "let me think about it," or you are tempted to hire a salesperson to do the part you have not figured out yet.

## The core idea

`market-to-devs-sell-to-buyers` told you *who* to sell to (the dev adopts, the boss pays). `pricing` set the number. This is the part nobody warns technical founders about: actually doing it. And it is not slimy. Selling a dev tool well is discovery plus helping a champion get budget. You are not convincing anyone of anything false, you are finding the people who already have the pain and making it easy for them to say yes.

One rule under all of it: **do this yourself until it repeats.** You cannot outsource a motion you have not cracked. Founders who hire a rep at deal one hire someone to fail at a job that does not exist yet.

## Every real deal has four things

# Founder-led content

> You don't have to "do marketing." You have to become the person developers trust on *the problem*. Sell the category, not the product, and let the authority pull people in.

**Use this when:** content feels slimy so you avoid it, your "blog" is a changelog, or a competitor is quietly becoming the go-to voice while you ship in silence.

## The core idea

Developers reward **technical depth, honesty, and a real point of view**, and punish polished fluff. The move isn't promotion; it's education. Be the trusted expert on the problem, take a stance on where the space is heading, and the product sells itself as the obvious answer.

Before product-market fit, **only the founder can do this**. It's the #2 hire (DevRel) later, not now.

## Framework: authority positioning (Frankl)

# Know if it's working

> The only early metric that matters is **net developer retention**. Without it, you're not running a funnel; you're running a colander.

**Use this when:** you're tracking GitHub stars and pageviews and still can't answer "is GTM working?", or you're pouring effort into acquisition while new users quietly churn.

## The core idea

Acquisition is worthless if users don't come back. Prove **retention** first; only then does spending on **acquisition** make sense. Most early founders optimize the top of the funnel while the bottom leaks. Fix that order.

## Framework: net developer retention (Frankl)

> Of all the developers who first used the product in **Month 1**, how many used it in **Month 2? Month 3?**

# Market scan (keep your read current)

> Positioning rots. The competitor you sized up six months ago has since rebranded, raised, repriced, or renamed the category. This is the habit that keeps your brief honest about the world outside it.

**Use this when:** a rival just rebranded or repositioned, a new tool is getting attention in your space, your `docs/gtm-cofounder/founder-brief.md` competitor answers are more than a quarter old, or you just have the feeling the ground moved and your messaging is answering last year's market.

## The core idea

`research-the-market` is the first full pass on the market: venues, launches, the problem in public, rivals, openings. This skill is the refresh after that, focused on what changed.

Your `docs/gtm-cofounder/founder-brief.md` captured the market as it was the day you wrote it. Markets don't hold still. A scan re-checks the outside world against your brief and surfaces the deltas: what changed, and which changes actually threaten or help your positioning. Most don't matter. The scan's job is to find the two or three that do, not to produce a competitor spreadsheet.

## Before you start: can your agent see the web?

# Review the work (the self-check gate)

> The person who wrote it is the worst judge of whether it is good. Before this reaches the founder, stop being the author and become the skeptic.

**Use this when:** you are about to present any substantive deliverable, or the founder asks "is this actually good?" It is a gate, not a stage. It has no place in the linear sequence. Run it around any piece of work, every time.

## The core idea

An agent that just wrote something is biased to ship it. That bias is how generic, plausible, quietly wrong work reaches a founder who does not yet know enough to catch it. So separate the two jobs: the author drafts, a different lens judges. You do not present work because you made it. You present it because it survived a skeptic.

Steal the one rule that makes this work: **the author may submit the work, the author may not issue the verdict.** Switch roles on purpose. Become the developer who is skeptical, the buyer who is busy, the reviewer who has seen a hundred of these, and try to break it before the market does.

## How to run this (for the agent)

# Growth loops (the next 5,000 without you)

> You got your first 50 users by hand: DMs, favors, one good launch. That was the right way to get them, and it was never supposed to scale. A growth loop is what comes next: one user's ordinary use of the product exposes it to the next user, and that user repeats it. Not a one-time referral; a continuous cycle.

**Use this when:** growth flatlines every time you stop posting, you can trace every user to a founder DM or a launch day, or you're about to add a third channel when the users you already have produce zero new ones.

## The core idea

A channel is linear: effort in, users out, stop pushing and it stops. A **loop** feeds output back into input: usage creates an artifact, a public trace, or an invitation that a new developer finds, and that developer's usage restarts the cycle. Channels deplete; loops compound.

**The rule that keeps it non-slimy:** every loop must do the *user* a service, not just you. A branded report the user is proud to send is a loop; a watermark they resent is spam with extra steps. If the loop degrades the experience, it is not a loop, it is a leak in your trust.

**The gate:** a loop amplifies whatever you feed it. If week-2 retention is broken, a loop compounds churn, not growth. Before this skill: first value in under an hour (`time-to-first-value`), first 50 real users in hand (`first-50-users`), and cohorts that come back (`know-if-its-working`, Frankl's net developer retention). If any of those fail, that failure is your Now move, not this.

# 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?