time-to-first-value
Turn a curious developer into an activated one: the docs, the quickstart, and the first-run experience that gets them to their first real win fast, and back again. Use when people sign up or star the repo but never get it working, come once and never return, or you're about to pour traffic into a first-run that leaks.
git clone --depth 1 https://github.com/AIDevGTM/gtm-cofounder /tmp/time-to-first-value && cp -r /tmp/time-to-first-value/skills/08-time-to-first-value ~/.claude/skills/time-to-first-valueSKILL.md
# 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.
## The two thresholds
**The weekend test (Frankl).** A motivated developer should get your product doing something real over a weekend, without a call, a demo, or an email to you. If they cannot, that is your single highest-leverage work, above any channel, launch, or homepage tweak.
**Time to first value (Czakon: "time to Hello World").** Measured in minutes, not hours, and the first meaningful win in the same sitting, not after an onboarding call next Tuesday. The first "Hello World" should be minutes in; the first real "oh, this is useful" should be that same session.
**The win belongs to the developer, not your product (Frankl: the developer is the hero).** The aha is "look what I just did," not "look what our platform can do." Design the first run so the developer feels capable, fast.
## Framework: the friction log (Czakon)
The core tool. Do not try to document every path. Nail the ONE most common path to first value.
1. Pick the single core journey a new developer takes to their first win.
2. Walk it yourself as a stranger: new machine or incognito, no insider shortcuts, no filling in gaps from memory.
3. At every step, log three things: the **question** they have, the **frustration** they hit, the **friction or barrier** that makes them stop.
4. Fix the obvious barriers first. Cut the top three places a motivated dev would quit.
5. Put a **metric on each core moment** so you can see where they drop.
## What removes friction (and what adds it)
Removes it:
- Free tier or trial, **no credit card, no "contact sales"** (Czakon: hard barriers send devs straight to a competitor).
- An idiot-proof install and a **copy-pasteable example** that works on the first try.
- A "get started in 5 minutes" path, and a docs quickstart written for the stranger, not the expert.
- A sandbox or demo populated with data close to **their** real use case, not `foo` and `bar` (Czakon: realistic sandbox data gets you most of the way).
Adds it:
- A signup wall, a sales call, or a credit card in front of the first win.
- Docs written by someone who already understands the product.
- A first run that shows off your architecture instead of getting the developer to their result.
## Decision tree
```
Can a motivated new dev reach a real win alone, in one sitting, without talking to you?
├─ NO → this is your highest-leverage work, above any channel or launch.
│ Run a friction log on the one core path and cut the top 3 barriers.
└─ YES → do they come back the next week?
├─ NO → the first win isn't valuable or sticky enough. Wrong "aha,"
│ or no reason to return. Re-pick the activation moment.
└─ YES → now acquisition is worth scaling. Go to `first-50-users`.
```
## Mistakes that look reasonable
- **Optimizing the homepage or the launch while the first run leaks.** Fix activation before acquisition. A great channel into a broken first run just burns the channel.
- **Celebrating signups.** Signups are vanity if they never activate. Watch time to first value and week-one activation, not the top of the funnel (see `know-if-its-working`).
- **Gating the first win** behind a wall, a demo, or a credit card. Developers bounce and do not come back.
- **Making your product the hero of the first run.** The developer is the hero. The moment is "look what I did," not "look what it does."
- **Writing docs for the expert.** The quickstart is for the stranger who has never seen it. Test it on one.
- **Documenting every path.** Nail the one common path first. Perfect coverage of a journey nobody takes is wasted work.
## Your next 30 minutes
- [ ] Name the ONE core path a new developer takes to their first real win. Just one.
- [ ] Walk it as a stranger (incognito or a clean machine), and time it. Log every question, frustration, and barrier at each step.
- [ ] Circle the first three points where a motivated dev would give up. That is your backlog, ahead of any marketing task.
- [ ] Define the single "I'm awesome" moment, and make it reachable in minutes, in one sitting, with no human help.
- [ ] Put one number on it: time to first value, or the percent of signups that reach the win in week one. Watch it like you watch uptime.
---
Built from real dev-tool GTM experience, with frameworks from Adam Frankl (*The Developer-Facing Startup*) and Jakub Czakon (*markepear.dev*).
When a framework can't make the call, that's what a human is for: [The DevTool GTM Company](https://thedevtoolgtmcompany.com).Interview the user once and write a docs/gtm-cofounder/founder-brief.md that every other skill reads first, so the advice is about their real business, not a textbook. Use this before anything else, or whenever the agent lacks context on the user's product, ICP, market, or stage, or is giving generic GTM advice.
After the founder brief, turn it into an honest diagnosis and a prioritized, stage-aware GTM roadmap saved as docs/gtm-cofounder/gtm-roadmap.md. This is the hub the user returns to every session to see where they are and the single next move. Use right after start-here, whenever the user doesn't know what to work on next, wants a plan instead of a one-off task, or is drowning in disconnected tactics.
Define a real ICP and the developer personas in the sale. Use when the user says the product is \"for developers,\" can't name who would say no, or is marketing to whoever holds the budget instead of who actually adopts.
Run developer customer discovery via a Technical Advisory Board (TAB). Use when the user has never interviewed a user who isn't a friend, is inventing messaging from a conference room, or is guessing at the roadmap instead of hearing the pain firsthand.
Build a positioning and narrative where the developer is the hero and a real trend is the villain. Use when the messaging describes the product instead of the problem, sounds like every competitor, or has no urgency because nothing is at stake.
Position an AI product when everyone claims AI and skeptics call it \"just a wrapper.\" Find the real wedge (data, workflow, trust, domain), make reliability the differentiator, answer \"won't the big labs just build this,\" and stop leading with \"AI-powered.\" Use when your AI or dev tool blends into a sea of similar demos, buyers doubt the accuracy, or you can't say why you win when the model is a commodity.
Write a developer value proposition that is specific, provable, and free of puffery. Use when the messaging leans on \"powerful,\" \"better,\" \"seamless,\" or \"best-in-class,\" when claims have no proof, or when the same line is supposed to reach both the developer and the buyer.
Structure a dev-tool homepage that converts developers into champions. Use when the landing page is written for the buyer instead of the developer, reads as salesy, buries what the product does, or makes it hard to start. Pairs with the ShipReady homepage audit.