{
  "title": "Developer Marketing field guide — sections",
  "updated": "2026-07-27",
  "count": 9,
  "sections": [
    {
      "id": "00-start-here",
      "title": "Start here: the mental model",
      "order": 0,
      "summary": "The one rule that changes everything about marketing to developers, and the three habits that separate campaigns that compound from ones that get blocked.",
      "updated": "2026-07-11",
      "url": "https://developer-marketing.vercel.app/guide/00-start-here/",
      "body": "Developers are the hardest audience in marketing and the most rewarding. They have finely tuned detectors for spin, they don't read your ad, and they'll route around your funnel entirely. But when they trust you, they build on you, tell their peers, and carry you into their next company. Everything in this guide is in service of earning that.\n\n## The one rule\n\n**You don't market *at* developers — you reduce the distance between their problem and a working solution.** Every asset, every campaign, every event either shortens that path or gets in the way. A quickstart that gets them to a successful API call in five minutes *is* the marketing. A gated \"request a demo\" wall in front of the docs is anti-marketing.\n\nThe corollary: **the product experience is the campaign.** For a developer audience, the docs, the SDK, the free tier, and the error messages do more selling than any landing page. Marketing's job is to remove friction and then get out of the way — not to manufacture desire for something that doesn't deliver.\n\n## Three habits\n\nEverything else in this guide is in service of these:\n\n1. **Lead with utility, not persuasion.** Ship the tutorial, the open-source tool, the honest benchmark, the reference architecture. Give developers something that works before you ask for anything. Trust is the currency and utility is how you earn it.\n2. **Instrument the path to value.** Know your time-to-first-success and your activation rate the way a growth team knows signup conversion. If you can't see where developers get stuck, you're guessing — and you'll optimize the wrong things.\n3. **Respect the audience's intelligence.** No hype, no vague claims, no dark patterns. Show the code, name the trade-offs, admit the limitations. A developer who catches you overselling once will discount everything you say forever.\n\n## How to read the rest\n\nThe guide is a reference, not a tutorial — jump to what you need:\n\n- **Positioning for developers** — how technical audiences decide who to trust.\n- **Docs as the front door** — the highest-leverage marketing surface you own.\n- **DevRel & community** — the relationship layer that compounds.\n- **Developer experience & activation** — turning interest into working integrations.\n- **Content that earns trust** — technical content that isn't fluff.\n- **Channels & distribution** — where developers actually are, and what reaches them.\n- **Launches** — how to ship an announcement developers amplify instead of ignore.\n- **Measurement** — the metrics that tell you any of this is working.\n\nEach section is stamped with the date it was last reviewed. When something moves in the field, it shows up in [the week](/weekly) — one short digest every Monday on what actually mattered. The dated daily posts from this site's first phase live on in the [radar archive](/radar)."
    },
    {
      "id": "01-positioning-for-developers",
      "title": "Positioning for a technical audience",
      "order": 1,
      "summary": "How developers decide who to trust, why category and clarity beat adjectives, and how to write a positioning that a skeptical engineer will forward instead of eye-roll.",
      "updated": "2026-07-27",
      "url": "https://developer-marketing.vercel.app/guide/01-positioning-for-developers/",
      "body": "Positioning is the answer to \"what is this, who is it for, and why should I care\" — delivered in the first ten seconds, in language the reader already uses. For developers, weak positioning isn't just ineffective; it's a trust penalty. Vague adjectives (\"powerful\", \"seamless\", \"next-generation\") signal that you're hiding something or don't understand your own product.\n\n## Start from the job, not the category buzzword\n\nDevelopers evaluate tools by the job to be done: *\"send transactional email\", \"add auth without building it\", \"search across my data\"*. Name that job plainly. The fastest positioning test: can a developer read your homepage headline and correctly guess what the first API call does? If not, rewrite it.\n\nBorrow the discipline of category design when a real new category exists — but most products slot into a job developers already understand. \"Stripe for X\" clarity beats \"reimagining the future of Y\" every time.\n\n## The three questions every technical buyer asks\n\n1. **Does it actually work?** Show it. A live code sample, an interactive playground, a real benchmark with methodology. Claims without evidence are noise.\n2. **Will it lock me in or slow me down?** Developers price in switching cost and operational risk. Be explicit about standards support, export, self-hosting, and how you fail. Openness is a positioning asset — and that includes pricing: put a real number on the page, and where billing is usage-based, show a monthly cap. \"Contact sales\" and vague tiers read as something to hide; a legible price is a trust signal. AI-assisted features have converged on a two-part shape — a per-seat license plus metered model consumption (by mid-2026 the pattern ran from code generation to code review: Copilot's seats with draining AI credits, GitHub Code Quality's $10/committer plus usage, CodeRabbit's seat plus on-demand credits). If that's your shape, publish both parts *and* the cap: the seat is the floor, not the price, and a meter the buyer discovers on the invoice is a trust debt you chose.\n3. **Who else uses it, and were they glad?** Logos matter less than a credible engineer saying \"we run this in production and here's what happened.\" Peer proof outranks vendor proof — and *verifiable* proof outranks both. A logo wall shows someone signed once; a live weekly-download count, a public star-history graph, or a deploy counter shows the thing is used, and a developer can go check the source. Prefer current, reproducible numbers to social proof they have to take on faith.\n\n## \"Developers\" is not one persona\n\nThe single job title hides buyers who behave nothing alike. An indie hacker spending personal money evaluates you on a weekend, alone, and wants to reach a working result before dinner. A platform engineer on a team spends the company's money, has to fit you into an existing stack, and needs organizational buy-in and a switching-cost story before anything ships. Same headline can't serve both: one wants \"running in five minutes on the free tier\", the other wants \"here's how you migrate, what it costs at scale, and who owns it in production.\" Decide which developer a given page, tutorial, or launch is for, and say so — trying to address every developer at once addresses none of them well.\n\n## Write for the skeptic, not the champion\n\nYour best distribution is a developer forwarding your page to their team with \"this looks legit.\" That happens when the copy respects them: concrete nouns, real numbers, honest scope. Name what you *don't* do. Counter-intuitively, stating limitations up front increases trust and reduces the support and churn cost of mismatched expectations.\n\n## Anti-patterns\n\n- **Adjective soup.** If deleting every adjective leaves the sentence just as informative, the adjectives were doing no work.\n- **Marketing-speak the product team wouldn't say.** If your own engineers cringe at the homepage, developers will too.\n- **Hiding the product.** \"Contact sales to see pricing/docs/the API\" tells a developer you're not for them. Let them read, try, and self-qualify.\n\nPositioning is upstream of everything else in this guide. Get it wrong and even great docs and DevRel are pushing the wrong message efficiently."
    },
    {
      "id": "02-docs-as-front-door",
      "title": "Docs as the front door",
      "order": 2,
      "summary": "Why documentation is the highest-leverage marketing surface you own, what a great quickstart looks like, and how docs-led growth turns reading into adoption.",
      "updated": "2026-07-26",
      "url": "https://developer-marketing.vercel.app/guide/02-docs-as-front-door/",
      "body": "For a developer product, the docs are not a support afterthought — they are the top of the funnel, the demo, and the sales engineer combined. Developers evaluate you by reading. The companies with outsized developer adoption almost all share one trait: documentation good enough to be a competitive moat. Treat docs as a product, staffed and measured like one.\n\n## The quickstart is the most important page you have\n\nEverything hinges on time-to-first-success: how long from landing on the quickstart to a working result the developer produced themselves. Optimize it ruthlessly.\n\n- **Copy-paste to working in minutes.** A developer should reach a real result — a sent message, a returned query, a rendered component — before they're asked to think hard.\n- **One golden path.** The quickstart is not the reference. Show the single most common path end to end; defer the options, edge cases, and configuration to deeper pages.\n- **Real, runnable code.** Snippets that actually run, in the languages your audience uses, with keys pre-filled in a sandbox where possible.\n- **No dead ends.** Every step ends somewhere obvious. The last step points to the natural next thing to build.\n\n## The docs stack, roughly in order of leverage\n\n1. **Quickstart** — get to first success.\n2. **Guides / tutorials** — accomplish real tasks, framed by goal not by feature.\n3. **Reference** — complete, accurate, generated from the source of truth where possible.\n4. **Concepts** — the mental model, so developers can reason about the system.\n5. **Recipes / examples** — copyable solutions to common jobs.\n\nGuides sell; reference retains. Invest in both, but know that the goal-oriented tutorial is what converts a curious reader into an integrated user.\n\n## Docs-led growth\n\nDocs-led growth means treating documentation as a discoverable, indexable, conversion-driving channel:\n\n- **SEO by job.** Developers search for tasks (\"how to verify a webhook signature\"). Structure guides around those queries; you'll capture intent your competitors' gated content can't.\n- **Ungate everything you can.** A login wall in front of docs is a conversion leak. Let developers read and try before they sign up; qualify them with a great free tier, not a form.\n- **Interactive where it counts.** Runnable snippets, an API explorer, and copyable examples convert far better than static text.\n- **Readable by machines.** A growing share of your docs' readers are AI assistants and answer engines acting on a developer's behalf, and what they retrieve becomes the developer's first impression. Structure for retrieval — one section answers one question, the golden path up top, descriptive link text — and publish machine-readable surfaces (llms.txt as a curated index, OpenAPI for the reference). The same structure helps human readers for free, which is why it's worth doing regardless of which indexing convention wins.\n- **Actionable by agents.** Where your product sells or provisions something, the machine-reader logic extends from reading to acting. The pattern — first shipped at mass-market scale by GoDaddy's mid-2026 Developer Platform, and by mid-2026 converging into a small buildable category with a research name (\"pre-action\" or \"runtime\" authorization): serve every docs page as markdown and tell the developer to hand your OpenAPI spec to their LLM, then make the transactional flow agent-safe — a quote step that returns an exact price and a short-lived token before anything commits, per-attempt idempotency keys so a retry can't double-purchase, and an explicit consent record. The through-line is a checkpoint that evaluates a declared policy *before* the agent's call executes, not after. An API an agent can safely act on is the next rung of \"docs as the front door\" — and documenting that transaction flow is a positioning claim competitors mostly can't make yet.\n\n## Measure docs like a product\n\nInstrument search queries with no results, the pages developers land on then bounce, and the drop-off step in the quickstart. A rising rate of \"zero-result\" doc searches is a roadmap. Docs quality is not subjective — it shows up in activation.\n\nThe through-line: your docs are doing more selling than your marketing site. Resource them accordingly."
    },
    {
      "id": "03-devrel-and-community",
      "title": "DevRel & community",
      "order": 3,
      "summary": "What developer relations is actually for, the advocacy–education–feedback split, how to build community that compounds, and why DevRel dies when it's measured like sales.",
      "updated": "2026-07-07",
      "url": "https://developer-marketing.vercel.app/guide/03-devrel-and-community/",
      "body": "Developer relations is the human layer of developer marketing: the people and programs that build a trusted relationship between your company and the developers you serve. Done well it compounds — every talk, tutorial, and answered question keeps working long after it ships. Done badly it's an expensive events calendar. The difference is whether it's built around genuine developer value or around short-term lead capture.\n\n## What DevRel is for\n\nMost functioning DevRel programs balance three jobs:\n\n1. **Advocacy (outbound)** — meeting developers where they are: talks, tutorials, sample apps, streams, conference presence. The goal is awareness and trust, not a pitch.\n2. **Education (enablement)** — docs, workshops, courses, office hours, reference architectures. This is where interest becomes competence and competence becomes adoption.\n3. **Feedback (inbound)** — carrying the developer voice back into product. DevRel sits closest to real usage; a program that doesn't feed the roadmap wastes its best signal.\n\nA program that's all outbound becomes a hype machine with no substance. All education and no advocacy stays invisible. The feedback loop is what earns DevRel a seat at the product table.\n\n## Community that compounds\n\nCommunity is not a Discord server you open and hope. It's a place where developers get value *from each other*, with your team as gardeners, not broadcasters.\n\n- **Seed with utility.** People show up for answers, examples, and early access — not for your brand. Give them a reason that isn't you.\n- **Answer fast, in public.** A visibly responsive team turns a support channel into a trust-building asset that new developers read like reviews.\n- **Recognize contributors.** Champions, ambassadors, and expert programs work when the recognition is real (access, reputation, revenue) rather than swag.\n- **Reduce the cost of contribution.** Good \"good first issues\", clear contribution guides, and templates turn goodwill into pull requests.\n\n## Don't measure DevRel like sales\n\nThe fastest way to kill a DevRel program is to put a monthly lead quota on it. Advocates start optimizing for capture over trust, and the audience feels it immediately. DevRel's value is largely leading-indicator and influence: developers reached, activated, and retained; sentiment; contribution; influenced pipeline. Measure those. (Section 08 covers how without pretending everything is directly attributable.)\n\n## Staffing reality\n\nDevRel advocates are expensive and hard to hire — they need genuine technical credibility *and* the ability to teach and perform. Protect their time from becoming an unpaid support queue or a sales-demo bench. Their leverage is content and relationships that scale; burning them on one-to-one firefighting wastes the role."
    },
    {
      "id": "04-developer-experience-and-activation",
      "title": "Developer experience & activation",
      "order": 4,
      "summary": "Time-to-value as the metric that governs adoption, mapping the developer funnel from first touch to habit, and removing the friction that quietly kills integrations.",
      "updated": "2026-07-20",
      "url": "https://developer-marketing.vercel.app/guide/04-developer-experience-and-activation/",
      "body": "Developer experience (DX) is the sum of every friction and delight a developer meets while trying to build with you — from the first `npm install` to the third production incident. For a developer product, DX *is* the growth engine: great DX turns a curious signup into a paying, retained, referring integration; poor DX loses them silently, and they rarely tell you why.\n\n## Time-to-value is the number that matters\n\nAdoption is gated by how fast a developer reaches a moment of real value — a successful call, a deployed app, a passing test against your API. Measure it as **time-to-first-success** (or time-to-first-hello-world) and **time-to-value** (the first *useful* result, not just any result). Shortening these does more for growth than almost any campaign.\n\nTreat every minute of that path as a conversion surface: account creation, API key generation, environment setup, the first request, the first success. Each step loses people. Instrument each one.\n\n## The developer funnel\n\nA useful frame — adapt the stages to your product:\n\n1. **Discover** — hears about you (search, peer, content, event).\n2. **Evaluate** — reads the docs, scans the pricing, checks GitHub and the community.\n3. **Sign up / install** — creates an account or pulls the SDK.\n4. **Activate** — reaches first success, then first *value*.\n5. **Integrate** — ships something real to production.\n6. **Habit / expand** — uses it routinely, adopts more surface area.\n7. **Advocate** — recommends it, contributes, brings it to the next project.\n\nMost teams over-invest in Discover and under-invest in Activate → Integrate, where the real leaks are. A developer who signs up and never reaches first success is a marketing cost with no return.\n\n## Friction to hunt down\n\n- **Signup and key friction.** Every required field, email verification, and manual approval before the first call bleeds activation. Delay what you can until after first value.\n- **Environment pain.** Broken installs, version conflicts, unclear prerequisites. A containerized or hosted sandbox removes a whole class of drop-off.\n- **Bad error messages.** Errors are documentation at the worst possible moment. An error that says exactly what went wrong and how to fix it is a retention feature.\n- **Stale examples.** Sample code that no longer runs is worse than none — it breaks trust precisely when the developer is committing.\n- **The second-day cliff.** Great quickstart, then a wall when they try something real. Make sure the path from \"hello world\" to \"production\" is paved.\n\n## Free tiers and self-serve\n\nFor most developer products the free tier or open-source core is the top of the funnel, and self-serve is the default motion. Price and package so a developer can go from evaluating to building to paying without talking to anyone — and so the moment they should talk to sales is obvious and well-timed, not forced early.\n\nA free tier is also a contract, and developers build on it literally — hardcoded model names, assumed endpoints, cron jobs that call you at 3 a.m. Changing or sunsetting one is a deprecation event, not a pricing tweak: give it a date, email the people whose integrations will break, return an error that says *deprecated* rather than a silent 404, and offer a migration path. The failure mode is rarely public outrage; it's a quiet re-anchoring on \"this vendor breaks things without telling me\" that surfaces at the next build-vs-buy decision. Sunsetting a free tier is usually defensible — doing it silently is what burns the trust.\n\nDX is where marketing, product, and engineering share a scoreboard. If activation is falling, no amount of top-of-funnel spend fixes it."
    },
    {
      "id": "05-content-that-earns-trust",
      "title": "Content that earns trust",
      "order": 5,
      "summary": "Why technical content is the core of developer marketing, how to make things worth a developer's attention, and the fluff patterns that burn credibility.",
      "updated": "2026-07-21",
      "url": "https://developer-marketing.vercel.app/guide/05-content-that-earns-trust/",
      "body": "Content is where most developer marketing lives, because developers learn by reading and doing. But the bar is high: a developer's time is scarce and their tolerance for filler is zero. Winning content teaches something real, respects the reader's intelligence, and is often useful whether or not they ever buy from you.\n\n## The test: would a developer bookmark this?\n\nIf the answer is no, it's not doing its job. The content that compounds is the content developers save, share, and return to — the definitive guide to a hard problem, the honest comparison, the working reference implementation. Aim for \"the best thing on the internet about this specific problem,\" not \"a blog post that mentions our product.\"\n\n## Formats that work\n\n- **Task tutorials.** \"How to do $specific_thing\" — the workhorse. Ranks in search, matches intent, and demonstrates the product in the reader's own context.\n- **Deep technical explainers.** How a hard thing actually works (consistency, auth, streaming, indexing). These build authority and attract exactly the senior developers who make adoption decisions.\n- **Reference architectures & example apps.** Complete, runnable, production-shaped. Developers copy these; make them copy yours.\n- **Honest comparisons and benchmarks.** With methodology, reproducible, fair to competitors. Publish the noise next to the signal — your false-positive rate, which rule or case produced most of it, even your own weak scores — because a benchmark that hides its noise reads as marketing, and a developer audience checks (HeimWall's July 2026 secret-scan post, run on a public dataset anyone can rerun, is a clean template). A credible comparison you'd trust from a stranger is worth more than ten pages of self-praise.\n- **Teardowns and post-mortems.** How you built or broke something. Vulnerability and specificity read as authenticity.\n\n## Distribution is half the work\n\nGreat content nobody sees is a diary entry. Write for search intent (developers search by task), earn placement where developers already read (see Channels), and make it trivially shareable. One canonical, genuinely-best resource beats a high-volume content mill — quality is the ranking signal *and* the trust signal.\n\n## The fluff patterns that burn credibility\n\n- **Thin \"listicle\" SEO bait** with no real substance — developers spot it instantly and it taxes your brand.\n- **Ghost-written posts the \"author\" couldn't defend.** Technical content needs a technical voice; readers can tell.\n- **Product-shaped \"tutorials\"** that are really pitches. Teach the job honestly; let the product appear where it genuinely helps.\n- **AI-generated filler** shipped without an expert in the loop. Volume without accuracy is negative marketing for a developer audience.\n- **Gated PDFs** for content developers expect to read in a browser. The gate costs you more reach than the emails are worth.\n\n## Sustainability\n\nContent is a compounding asset but a real cost. A smaller volume of excellent, maintained, accurate pieces outperforms a firehose of mediocre ones — especially because outdated technical content actively misleads and erodes trust. Budget for maintenance, not just production."
    },
    {
      "id": "06-channels-and-distribution",
      "title": "Channels & distribution",
      "order": 6,
      "summary": "Where developers actually pay attention, which channels reach them and which repel them, and why earned beats paid for a technical audience.",
      "updated": "2026-07-17",
      "url": "https://developer-marketing.vercel.app/guide/06-channels-and-distribution/",
      "body": "Developers are reachable, but not through the channels most marketing playbooks assume. They block ads, ignore cold email, and distrust anything that feels like a funnel. They *do* pay attention to peers, to genuinely useful content, and to being where the work happens. Distribution for developers is mostly about earning attention, not buying it.\n\n## Where developers are\n\n- **Search.** The default entry point. Developers search by task and land on docs, tutorials, and Q&A. Owning task-intent search is the most durable channel you have.\n- **Peer networks & word of mouth.** The strongest force in developer adoption. Tools spread developer-to-developer and team-to-team. Everything that increases the odds a happy developer tells another is distribution.\n- **Community platforms.** GitHub, Stack Overflow, Reddit (r/programming and niche subs), Hacker News, Lobsters, Discord/Slack communities, and increasingly Bluesky and Mastodon for technical discussion. Presence means participating, not posting brochures.\n- **Content platforms.** Dev.to, Hashnode, personal blogs, YouTube (long-form tutorials and conference talks), and technical newsletters.\n- **Events.** Conferences, meetups, hackathons, and workshops — high cost, high trust, best for depth and relationships rather than reach.\n- **Open source.** A useful open-source project is a distribution channel: it earns stars, contributors, and top-of-mind presence with exactly the right people.\n- **AI assistants & answer engines.** A growing share of first impressions are machine-mediated: a coding assistant or answer engine paraphrases your docs — and, increasingly, compares you against alternatives when a developer (or their agent) is choosing a tool. You can't buy presence here; you earn it with retrievable docs, machine-readable surfaces (llms.txt, OpenAPI), and specific, quotable facts. Measurement of this channel is still immature — the honest check is asking assistants task-shaped questions in your category and seeing whether, and how accurately, you appear.\n\n## Earned beats paid\n\nFor most developer products the ranking is: **earned > owned > paid.**\n\n- **Earned** — a developer's blog post, a HN front page, a conference talk, a GitHub trending spot, a peer recommendation. Highest trust, hardest to manufacture, worth the most.\n- **Owned** — your docs, blog, community, newsletter, and open-source repos. The compounding base you fully control.\n- **Paid** — sponsorships (newsletters, podcasts, conferences, OSS) tend to outperform display/programmatic, because they borrow trusted context. Straight ads to developers are usually a poor return.\n\n## Channels that repel\n\n- **Interruptive ads and pop-ups** on technical content.\n- **Cold sales outreach** to individual developers, especially \"I noticed you use X\" spam.\n- **Gating everything** behind forms — it shrinks reach far more than it grows pipeline.\n- **Astroturfing.** Fake community engagement, undisclosed shilling, or planted reviews. If discovered — and it usually is — the reputational cost dwarfs any short-term gain.\n\n## Pick few, go deep\n\nYou cannot be excellent everywhere. Concentrate on the two or three channels where your specific developers actually are, and earn a real presence there, rather than spreading thin across every platform. Depth builds the trust that breadth can't."
    },
    {
      "id": "07-launches",
      "title": "Launches developers amplify",
      "order": 7,
      "summary": "How to ship an announcement developers share instead of scroll past — substance over spectacle, the assets that matter, and orchestrating a launch across the channels that count.",
      "updated": "2026-07-08",
      "url": "https://developer-marketing.vercel.app/guide/07-launches/",
      "body": "A developer launch succeeds when developers do the amplifying for you. That only happens when there's real substance and they can try it immediately. Spectacle without substance gets ratioed; substance packaged well gets to the front page of Hacker News and into a dozen team Slacks.\n\n## The precondition: something real to try\n\nThe single biggest predictor of a developer launch landing is whether a developer can *use it right now*. Ship the docs, the SDK, the free tier, and a working example *at the moment of announcement* — not \"sign up for the waitlist.\" A launch that developers can only read about, not run, converts curiosity into nothing.\n\n## The asset checklist\n\nBefore you announce, have ready:\n\n- **A working quickstart** for the new thing, tested end to end.\n- **Reference docs** complete enough that early adopters don't hit walls.\n- **A great example / demo app** they can clone and run.\n- **A clear, honest changelog or blog post** — what it is, why it exists, what it does *not* do yet.\n- **A migration path** if this changes existing behavior. Nothing burns goodwill like a launch that silently breaks people.\n- **Someone technical available** to answer questions in the threads for the first 48 hours.\n\n## Orchestration\n\n- **Blog post as the canonical source.** One URL that explains it properly, that everything else points to.\n- **Meet the channels natively.** A HN \"Show HN\" reads differently from a changelog entry, a Bluesky/X thread, a Reddit post, a newsletter blurb. Adapt the framing; don't paste the same copy everywhere.\n- **Enlist the people, not just the brand.** Launches carry further from the individual accounts of the engineers and DevRel who built it than from the corporate handle.\n- **Time it for your audience,** and be present when it lands — the first hours of engagement (especially on HN) shape whether it spreads.\n\n## What developers punish\n\n- **Overclaiming.** \"Revolutionary\", \"10x\", \"the last X you'll ever need\" — provably, and they will check.\n- **Vaporware.** Announcing what you *will* build. Announce what shipped.\n- **Hiding the limits.** State what's beta, what's rate-limited, what's not there yet. Developers respect honesty and resent discovering the gaps themselves.\n- **Launch-and-abandon.** Going quiet in the threads reads as not caring. Show up.\n- **Manufactured chorus.** A coordinated influencer push — the same talking points from ten accounts on the same day — is legible as inauthentic to exactly this audience. Once someone spots the pattern it flips into *negative* social proof. Enlisting the people who built the thing is not the same as buying a synchronized wall of praise; the first is credible, the second is astroturf.\n\n## After the launch\n\nThe launch is the start of the relationship, not the end of the campaign. Fold what shipped into the docs and guide, watch activation on the new surface, gather the feedback the threads surface, and feed it back to product. A launch that quietly improves your time-to-value is worth more than the spike of attention.\n\nRun two campaign cadences, not one. A launch is a **short-burst** campaign — a spike engineered around a moment (the release, a conference, a big integration). It works only on top of a **long-lived** campaign: the always-on changelog, tutorial stream, and product updates that keep you present between spikes. Most teams build only one. Burst-only means you disappear the day after and have to buy attention back for the next launch; always-on-only means steady presence that never converts a moment of peak attention into adoption. The spike is where the compounding content gets its audience; the steady stream is what makes the next spike land."
    },
    {
      "id": "08-measurement-and-metrics",
      "title": "Measurement & metrics",
      "order": 8,
      "summary": "The metrics that tell you developer marketing is working, how to measure DevRel without pretending it's direct-response, and the funnel numbers worth instrumenting.",
      "updated": "2026-07-23",
      "url": "https://developer-marketing.vercel.app/guide/08-measurement-and-metrics/",
      "body": "Developer marketing is measurable — but not with a lead-gen dashboard. Much of its value is leading-indicator (activation, retention, sentiment) and influence (deals it shaped without a clean attribution line). The job is to measure honestly: instrument what you can, be explicit about what you can only influence, and resist forcing everything into last-touch attribution.\n\n## The funnel metrics worth instrumenting\n\nAdapt to your product, but most developer businesses should be able to see:\n\n- **Time-to-first-success** and **time-to-value** — the DX metrics from section 04. Trend them; they gate everything downstream.\n- **Activation rate** — share of signups/installs that reach first value. The single most important growth metric for a developer product.\n- **Signup → integration → production** conversion — where developers drop between trying and shipping.\n- **Retention / active integrations** — are they still calling the API next month? For dev tools, retained usage beats signups every time.\n- **Expansion** — usage and surface-area growth within accounts.\n- **Adoption-phase cohorts, with the passive seat counted** — for seat- or license-based tools, sort users by how far they've progressed (first use → agentic/advanced use → orchestration) and break out the *licensed-but-unengaged* segment explicitly instead of folding it into an \"active\" denominator. GitHub built exactly this into its Copilot admin dashboard (2026-07-22): three engaged phases plus a named \"Passive\" cohort. Naming shelfware gives a renewal buyer an honest number to trust — and a skeptical one a number you've already answered.\n- **Docs metrics** — top landing pages, zero-result searches, quickstart drop-off step.\n\n## Measuring DevRel without breaking it\n\nDon't put a lead quota on DevRel (section 03). Measure it on the layer it actually moves:\n\n- **Reach & awareness** — developers reached through talks, content, streams; qualified traffic to docs and repos.\n- **Activation & enablement** — workshop attendees who activate; tutorial readers who reach first success.\n- **Community health** — contributors, time-to-first-response, sentiment, returning participants.\n- **Product feedback delivered** — issues surfaced, features shaped. Real value, usually uncounted.\n- **Influenced pipeline** — deals where DevRel touchpoints appear in the story, reported as *influence*, not *attribution*. Sourced-lead credit misrepresents how developer trust actually converts.\n\n## Product usage is the signal nobody else can buy\n\nThe same instrumentation that measures activation doubles as go-to-market data. Third-party intent signals — website visits, keyword tracking — are commoditized; every competitor can buy the same feed. First-party product usage is proprietary by definition, and operators who run outbound on it weight it heavily: scoring models built on roughly 80% behavioral signals (usage volume, new users added, in-app engagement) to 20% firmographics, with the play list deliberately capped at a dozen or fewer so sales can actually run it. Get raw usage events into a warehouse you control before you rent anyone's signal layer — the vendors that package these signals keep getting acquired into big GTM suites, and their roadmaps follow their new owners.\n\n## Leading vs lagging\n\nRevenue is lagging and heavily mediated for developer products — the path from a great tutorial to a signed contract is long and multi-touch. Manage to **leading indicators you can move this quarter** (activation, time-to-value, community responsiveness, content that ranks) and hold them accountable to the lagging ones over quarters, not weeks.\n\n## Attribution honesty\n\n- **Peer recommendation and organic discovery are usually your biggest channels and the hardest to attribute.** A model that credits only trackable touches will systematically undervalue exactly what's working and push spend toward what's merely measurable.\n- **Prefer a blended view:** self-reported attribution (\"how did you hear about us\"), cohort analysis, and holdout/geo tests over a false-precision last-touch dashboard.\n- **Report ranges and influence, not invented certainty.** For a developer audience, an honest \"we influenced this, here's the evidence\" is more defensible — and more useful — than a made-up attributed number.\n\nThe point of measurement is better decisions, not a prettier board. Instrument the path to value, watch it honestly, and let it tell you where the next unit of effort goes."
    }
  ]
}