developer-first-gtm

{
  "skill_name": "developer-first-gtm",
  "evals": [
    {
      "id": 1,
      "prompt": "I run growth at Hoverlane, a hosted log-pipeline product. Since we launched 19 months ago we've had 8,412 signups and 19 of those people pay us. That's 0.23%, and every SaaS benchmark post I read says 3-5% is normal, so we're roughly 20x off. Our VP of Engineering wants to spend the whole quarter rebuilding onboarding. Before I greenlight that, is conversion actually our problem? Two extra details that may or may not matter: 74% of our accounts still have exactly one developer in them sixty days after signup, and the 0.23% is computed by dividing everyone who has ever paid us by everyone who has ever signed up.",
      "expected_output": "A reframing that rejects the blended benchmark row and the lifetime user-level ratio, re-specifies the measurement, runs the friction gates, and locates the problem as spread rather than conversion.",
      "files": [],
      "expectations": [
        "States that developer-focused companies show a median free-to-paid conversion of roughly 5%, about half the median of non-developer-focused companies, and attributes it to the Lenny's Newsletter free-to-paid conversion survey.",
        "Identifies the 3-5% figure as the freemium pure-self-serve band and notes it assumes a different measurement from the one the user ran.",
        "Rejects the user's lifetime all-signups-ever ratio as the wrong measurement, and states that a lifetime ratio flatters or distorts any product whose signups grew.",
        "Gives the measurement definition the published bands assume: accounts that begin paying within their first six months divided by accounts created in the measurement window.",
        "Requires the recomputation to be done by cohort.",
        "Requires the recomputation to be done at account level rather than per individual user.",
        "Names the 74% single-developer figure as a spread problem rather than a conversion problem.",
        "Runs or asks for the three friction gates by name - entry, value and spread - instead of moving straight to onboarding work.",
        "Requires each gate to be answered with evidence such as a cold run of the company's own onboarding, not with an opinion or belief.",
        "Declines to endorse the onboarding rebuild as the first action on the evidence given.",
        "Labels each number it uses as either sourced, with its source and measurement definition, or self-set.",
        "Does not assert that a 0.23% conversion rate proves the funnel is broken."
      ]
    },
    {
      "id": 2,
      "prompt": "Turnstile Metrics here, we sell a hosted metrics backend. 4,100 active accounts, average revenue per account is $31 a month, and 96% of accounts have exactly one developer in them. Our board just approved headcount for two account executives starting in Q1; fully loaded, each one costs us about $210,000 a year. My co-founder's argument is 'the enterprise demand is obviously there, we just never asked for it.' I'm not sure. What should I tell the board next week?",
      "expected_output": "An arithmetic answer using the 4x fully-loaded-cost test, with the opposite risk held in view, concluding against the hire as specified or naming what would change it.",
      "files": [],
      "expectations": [
        "Applies an explicit sales-economics test requiring a salesperson added to a self-serve motion to return roughly 4x their fully loaded cost in incremental revenue, and attributes it to The Transition (Lenny's Newsletter).",
        "States the resulting bar as roughly $840,000 of incremental revenue per rep per year against the $210,000 fully loaded cost given.",
        "Tests the bar by multiplying a qualified-account volume by a realistic deal size, rather than arguing the motion philosophically.",
        "Concludes on the evidence given that the two-AE hire is not yet supported, or names the specific conditions that would make it supported.",
        "States that account rollup must exist before any motion with a human in the loop is available.",
        "Holds the opposite risk in view rather than only arguing against sales: names that waiting too long lets sales-assisted competitors firewall a self-serve-only product out of enterprise segments.",
        "Cites Dropbox as the named casualty of adding sales too late.",
        "Quotes or paraphrases Pete Kazanjy's warning never to mistake lead generation for the business, and attributes it to him.",
        "Notes that self-serve at roughly $19-29 a month is lead generation while the business is the far larger contract.",
        "Names Datadog and New Relic as developer companies that nonetheless run sales organizations.",
        "Frames the decision as when a human enters the loop, not whether one ever does.",
        "Warns that reps hired against a majority single-developer account base will find nothing to work and start contacting signups, damaging the free surface.",
        "Does not recommend hiring both account executives in Q1 on the numbers given."
      ]
    },
    {
      "id": 3,
      "prompt": "Quick one. We're a dev tool, a CI caching service, around 2,300 free accounts. I read that if you contact a lead within 5 minutes you're 21x more likely to qualify them. I want to wire a Slack alert on every signup so someone emails them within the same minute. Our head of sales is already building the automation and wants copy from me by Thursday. What should the email say, and should we just call them instead?",
      "expected_output": "A refusal to build signup-triggered outreach, with the statistic's provenance named, replaced by an account-level threshold rule with an hours-scale window and a written do-not-contact line.",
      "files": [],
      "expectations": [
        "Refuses to build same-minute or signup-triggered human outreach.",
        "Identifies the 5-minute / 21x statistic as coming from inbound form-fill research in sales-led funnels rather than from developer product usage.",
        "Notes the statistic is usually cited to a vendor blog rather than to the underlying study.",
        "States that importing that statistic into a developer motion amounts to contacting on signup.",
        "Names contacting on signup as the behaviour this audience punishes hardest, or as teaching developers that the free tier is bait.",
        "Moves qualification to account level rather than per individual signup.",
        "Proposes a written qualification threshold expressed as a single sentence the team can apply without interpretation.",
        "Sets the response window for qualified accounts in hours rather than in days or in minutes.",
        "Labels the hours-not-days window as this skill's own baseline with no study behind it, not as an industry standard.",
        "Requires an explicit written do-not-contact line covering accounts below the threshold.",
        "Replaces the generic sales email with a technical offer such as a limits, quota, architecture or migration conversation, and rejects openers of the '15 minutes to learn about your needs' shape."
      ]
    },
    {
      "id": 4,
      "prompt": "At Clearmast, developer feature-flagging, we built a lead score last quarter: pricing page visit = 10 points, marketing email open = 5, docs visit = 8, signed up in the last 7 days = 15. Anything over 60 points goes to our SDR queue. It is not working. Reply rates are around 2% and people are visibly annoyed on Twitter. Last month one regional bank produced 40 separate signups and our SDR sent 40 separate emails to them. Help me re-tune the weights so we route better.",
      "expected_output": "A rejection of the scoring model itself, replaced by account rollup plus the three signal families ordered by intent, with boundary contact strongest.",
      "files": [],
      "expectations": [
        "Rejects re-tuning the point weights as the wrong project.",
        "Names the scoring model as the MQL construction rather than a genuine product-qualified-lead model.",
        "States that email opens and pricing-page visits measure marketing exposure, not a developer's product usage.",
        "Treats the bank's 40 signups as one account rather than forty leads.",
        "Requires usage to be rolled up to an account before any qualification rule is applied.",
        "Names at least two account rollup sources from the set: organization or workspace object, license or API key or install ID, email domain, self-reported company at signup, enrichment from IP or company data.",
        "Advises combining at least two rollup sources rather than relying on a single one.",
        "Introduces the three signal families by name: depth, spread and boundary contact.",
        "Orders the three families by increasing intent, with boundary contact the strongest.",
        "Justifies boundary contact as strongest because it maps directly onto the paid boundary the business model defined.",
        "Gives concrete boundary-contact examples such as SSO/SAML, RBAC, audit log, repeated rate or seat limit hits, a security questionnaire, SOC 2 report, DPA, or billing and procurement pages.",
        "Distinguishes depth without spread, which usually means a solo power user, from spread without depth, which usually means an evaluation that has not committed.",
        "Recommends having a human read raw new signups in an internal channel for a few weeks before building any scoring system, or cites Zapier's four sales-assist qualification signals as a published cross-check."
      ]
    },
    {
      "id": 5,
      "prompt": "Parapet is a self-hosted policy engine for Kubernetes. To get any value at all you deploy our admission controller into a cluster, which means a platform engineer has to approve it and apply it, and the product does nothing useful until three or more services are onboarded to it. Constraints from my CTO, stated as non-negotiable: no new headcount this calendar year, our board meets in 10 weeks and needs to see revenue movement by then, and we will not hand a reseller or a marketplace any margin. We have no free tier today. Everyone on the team keeps saying 'we should do PLG.' Design our go-to-market.",
      "expected_output": "A gate-by-gate analysis that rules out bottom-up, deletes two motions on the stated constraints, notes motion 2 has nothing to convert, and surfaces the resulting contradiction instead of picking silently.",
      "files": [],
      "expectations": [
        "Fails the entry gate explicitly, naming the cluster deployment and the platform engineer's approval as mandatory steps between arrival and first value.",
        "States that a failing entry gate rules out bottom-up self-serve outright.",
        "Fails or partially fails the value gate, naming that value only appears once three or more services are onboarded, which is team-scale rather than single-developer.",
        "States that a failing value or spread gate means a hybrid motion - developer entry with a human-assisted or platform-level conversion - not a pure bottom-up one.",
        "Deletes top-down with developer proof on the no-new-headcount constraint.",
        "Deletes ecosystem-mediated on the refusal to give up margin.",
        "Records each deleted motion together with the specific constraint that ruled it out.",
        "Refuses to leave a ruled-out motion parked at the bottom of the menu as a lesser option.",
        "States that developer-influenced sales has nothing to convert here because no base of free accounts exists yet.",
        "Surfaces that the stated constraints eliminate every available motion, and names which constraint must be relaxed rather than silently picking one anyway.",
        "Presents two or three candidate motions rather than a single recommendation.",
        "Commits to at most one primary motion and at most one secondary motion.",
        "Does not recommend 'PLG' or a free tier without first addressing the failed entry gate."
      ]
    },
    {
      "id": 6,
      "prompt": "Reviewing our GTM memo before it goes to the board on Friday. The motion section reads, in full: 'Fernwake runs a PLG motion with an enterprise sales layer for larger accounts. We will also pursue cloud marketplace and partner channels opportunistically.' Our head of revenue thinks it's crisp and wants to ship it. I think something is off but I can't articulate what. Can you tighten the wording?",
      "expected_output": "A diagnosis that three motions are declared as one, with the one-primary rule enforced, a rejected-motions section demanded, and the taxonomy's published-versus-synthesized status stated.",
      "files": [],
      "expectations": [
        "Identifies that three motions are declared as one and that no decision has actually been made.",
        "States the rule of exactly one primary motion and at most one secondary motion that stacks on it.",
        "Explains that two primaries mean the team will argue about which funnel every account belongs to.",
        "Flags 'opportunistically' as how a motion with no owner gets written down.",
        "Requires a 'Rejected motions' section naming each rejected motion and the constraint that ruled it out.",
        "Distinguishes a motion blocked only for now, which belongs in the memo's revisit triggers, from one rejected outright.",
        "Names the four motions it works from: bottom-up self-serve, developer-influenced sales, top-down with developer proof, and ecosystem-mediated.",
        "States that this four-motion taxonomy is the skill's own synthesis and not a published framework.",
        "Gives the published vocabulary underneath as two independent axes - product-led versus sales-led, and top-down versus bottom-up - plus sales assist, attributed to the Lenny's Newsletter study of GTM motions across 30 B2B SaaS companies.",
        "Declines to fix the section by rewording alone.",
        "Requires the memo section to name the money path and the prerequisite that must be true for the chosen motion."
      ]
    },
    {
      "id": 7,
      "prompt": "Ridgepin sells an API gateway. We have a free tier with about 12,000 accounts on it. Here's the thing: 100% of our revenue has come from our two SDRs cold-emailing people who signed up for that free tier. Nobody has ever upgraded on their own. The upgrade button works, people just don't press it. Every quarter our growth lead and our sales lead have the exact same fight about 'fixing the PLG funnel', and we're going into planning again next week. What should I do differently this time?",
      "expected_output": "The motion named as bottom-up lead gen with its source, the PLG label rejected, and an explicit keep-or-convert decision required instead of more funnel work.",
      "files": [],
      "expectations": [
        "Names the motion as bottom-up lead generation: a sales-led company whose free product exists to feed leads rather than revenue.",
        "Attributes the term to the Lenny's Newsletter study of GTM motions across 30 B2B SaaS companies.",
        "States that the team is not running product-led growth despite calling it that.",
        "States that naming the motion correctly is what ends the recurring argument, rather than more funnel work.",
        "Notes that a team can run bottom-up lead gen for years while believing it runs product-led growth.",
        "Requires an explicit decision to either keep the motion and staff it honestly, or convert it, rather than continuing to optimize an unnamed one.",
        "Flags contacting the whole free base as burning the free surface's reputation with a developer audience.",
        "Requires a written do-not-contact line for accounts below a threshold.",
        "Requires the qualification threshold to be written as one sentence naming an owner and a response window.",
        "Requires account-level rollup rather than treating each free signup as an individual lead.",
        "Labels every number it introduces as either sourced with its source, or self-set."
      ]
    },
    {
      "id": 8,
      "prompt": "Auventa, we do distributed tracing. Our biggest customer is a regional bank: three engineering teams, about $48,000 a year, signed 14 months ago on a company credit card and later moved to an invoice. The staff engineer who brought us in left the company five weeks ago and the account has gone completely silent since. Renewal is in four months. Our head of sales wants to offer them 25% off for a two-year commitment to 're-engage and lock them in', and then pitch that same discount to other departments to expand. Sound plan?",
      "expected_output": "Discount rejected as an expansion lever, the vector named with a trigger and owner, multi-threading and standardization applied, and procurement re-entry anticipated.",
      "files": [],
      "expectations": [
        "Rejects the 25% discount as an expansion lever.",
        "States that expansion produced by price changes or by usage the customer did not choose is deferred churn, not expansion.",
        "Names the expansion vector in play - more teams in the same company - rather than treating expansion generically.",
        "Assigns that vector both a firing trigger and a named owner.",
        "Names at least one further expansion vector from the set: more developers on the same team, more workload per user, more product surface.",
        "Names the standardization decision by a platform or architecture group as the gate on continued growth in a large account.",
        "States that the champion enablement pack has to survive an architecture review rather than a hallway conversation.",
        "Applies the multi-threading rule of a second technical advocate plus one manager-level contact.",
        "States that both multi-threaded contacts must have seen value with their own eyes.",
        "Treats the departed champion as simultaneously a risk in this account and a warm entry at their new employer.",
        "Warns about procurement re-entry: the second, larger purchase can trigger the security review, legal pass and vendor onboarding that the original credit-card purchase skipped.",
        "Requires that paperwork be prepared before the expansion conversation rather than during it.",
        "Does not present quarterly business reviews or renewal-timed upsell calls as the expansion mechanism."
      ]
    },
    {
      "id": 9,
      "prompt": "Stavemill, bottom-up developer tool, mostly small teams paying by card. Our net revenue retention came in at 103% for the trailing twelve months. One of our investors said flatly that 'good SaaS is 120% plus' and now our CEO wants to build an upsell motion this quarter. Separately: we report 1,900 seats to the board, which is every seat ever provisioned across our paying accounts. Our standing board metrics are signups, MAU, ARR and NPS. Is 103% actually bad?",
      "expected_output": "The bottom-up retention row applied instead of the enterprise one, provisioned seats rejected for active seats, and the four lagging board metrics replaced with a small leading-indicator set.",
      "files": [],
      "expectations": [
        "States that the published 12-month band for a bottom-up product puts 'good' near 100% and 'great' near 120%.",
        "Contrasts that with the enterprise SaaS band of roughly 110% good and 130% great.",
        "Concludes that 103% is normal or good for the motion the company actually runs, not a failure.",
        "Attributes the retention bands to the Lenny's Newsletter retention benchmark post.",
        "Gives the definition of net revenue retention as a cohort's MRR today divided by that same cohort's MRR twelve months ago.",
        "Rejects reporting provisioned seats and requires active seats to be counted instead.",
        "States that dormant seats predict contraction at renewal.",
        "Identifies signups, MAU, ARR and NPS as lagging or unactionable indicators for this purpose.",
        "Replaces them with a leading-indicator set of five or fewer numbers, all of which move before revenue.",
        "Labels the five-or-fewer cap as this skill's own self-set baseline rather than a published rule.",
        "Gives each proposed indicator a target and a date.",
        "Does not endorse launching an upsell motion purely because 103% sits below 120%."
      ]
    },
    {
      "id": 10,
      "prompt": "Kelbrook sells a secrets-management platform. We only sell top-down: our AE team works CISOs and platform directors, contracts run $180K to $400K, and everything - docs, the API reference, pricing, rate limits, even the error-code pages - sits behind a 'Book a demo' form because our CRO wants every visitor captured as a lead. Two of our last four renewals came in flat or down, and in both cases the customer said some version of 'our engineers never really used it.' I'm the new VP of Product and I start Monday. Where do I begin?",
      "expected_output": "Shelfware named as the motion's failure mode, entry design asserted as load-bearing even top-down, the gated surfaces reopened, and post-purchase developer activation set as the leading indicator.",
      "files": [],
      "expectations": [
        "Names shelfware as the failure mode of a top-down motion: the contract is signed, adoption never happens, and the renewal conversation has no usage to point at.",
        "States that entry design still matters in a top-down motion because developers handed a tool evaluate it the same way as developers who chose it.",
        "States that a bad entry turns handed-a-tool developers into internal opponents.",
        "Requires documentation to be permanently ungated.",
        "Requires pricing detail and limits to be permanently ungated.",
        "Requires error and troubleshooting content to be permanently ungated.",
        "States that gating those surfaces loses technical evaluations silently, because developers evaluate before they will talk to anyone.",
        "Names post-purchase developer activation as this motion's leading indicator - the share of licensed developers actually using the product within a defined window such as 90 days.",
        "Rejects a demo-only enterprise path with no self-serve floor, naming that it leaves the long tail unservable.",
        "Names a concrete first-value moment as an observable event rather than calling it 'activation'.",
        "Counts the mandatory steps a developer must pass before reaching that first-value moment.",
        "Does not accept the lead-capture rationale as a reason to keep documentation gated."
      ]
    },
    {
      "id": 11,
      "prompt": "Need to write our PQL rule today. We're Ostrich Labs, a hosted vector database, roughly 5,600 free accounts. I found a blog post from a much bigger infrastructure company saying their rule is '5 or more seats and 30 days of usage' and I want to just adopt that, since it's battle-tested at their scale. One complication: we have no workspace or organization object in the product, so all we have is the signup email address, and maybe a third of those are gmail.com or similar. Write me the rule.",
      "expected_output": "The copied threshold refused, rollup made a build line item with named sources and weaknesses, and a one-sentence rule produced with owner, hours-scale window and do-not-contact line.",
      "files": [],
      "expectations": [
        "Refuses to copy the other company's threshold, on the grounds that cohort shapes differ too much for the number to transfer.",
        "Requires the threshold numbers to be derived from the accounts that have already converted at this company.",
        "Requires the chosen value to produce a queue the responder can actually clear.",
        "States that account rollup does not exist here, and makes building it a line item of the plan rather than a footnote.",
        "Names email domain as an available but weak rollup source.",
        "Names the specific weaknesses of email domain: free-mail addresses and contractors leak, and subsidiaries fragment.",
        "Names at least two further rollup sources - organization or workspace object, license or API key, self-reported company at signup, or enrichment - and advises combining at least two.",
        "Writes the qualification threshold as a single sentence.",
        "Includes an active-developer count condition in that sentence.",
        "Includes a duration-of-production-usage condition in that sentence.",
        "Includes boundary contact as an alternative qualifying trigger in that sentence.",
        "Names the role who acts on a qualified account and a response window measured in hours.",
        "States explicitly that accounts below the threshold are not contacted by a human.",
        "Labels the numbers in the rule as self-set or derived from the company's own data, and notes that how many active developers an account needs before it converts is not published anywhere."
      ]
    },
    {
      "id": 12,
      "prompt": "Tilcrest makes a CLI for database schema migrations. Our usage splits almost evenly: indie developers and two-person consultancies on our $9/month plan, and platform teams inside insurance companies and banks who want SSO, audit logs and an MSA before they'll touch us. We're about to rebuild onboarding as one flow for everybody, and our board deck reports a single blended free-to-paid conversion number. Our head of growth's position is 'a developer is a developer.' Design the onboarding and tell me what to report.",
      "expected_output": "The two audiences ranked rather than averaged, with what is shared and what diverges named, and conversion reported per audience at account level by cohort.",
      "files": [],
      "expectations": [
        "Refuses to design one entry serving both audiences, stating that an entry built for a hobbyist and an enterprise platform team at once serves neither.",
        "Requires the two paths to be ranked explicitly, with one named primary.",
        "Names what is identical for both: first value must be reachable by one developer working alone.",
        "Names that documentation, limits and pricing detail stay open for both audiences.",
        "Names what differs after the first paid moment: who is contacted, what is offered, and what expansion even means.",
        "States that in individual adoption the user and the payer are the same person, or no purchase exists at all.",
        "States that for the individual-adoption path a human in the loop costs more than the contract.",
        "States that company adoption requires account rollup, a champion enablement pack and procurement paperwork.",
        "Rejects the single blended conversion number and requires conversion to be reported per audience as well as blended.",
        "Notes that larger target customers correlate with lower conversion, so blending the two hides both.",
        "Requires conversion to be measured at account level and by cohort.",
        "Does not conclude that one onboarding flow can be optimized for both segments at once."
      ]
    }
  ],
  "trigger_queries": [
    { "query": "Design the go-to-market motion for our developer API product.", "should_trigger": true },
    { "query": "Should we go bottom-up self-serve or hire a sales team for our devtool?", "should_trigger": true },
    { "query": "We have 8,000 free signups and 11 paying customers - what's broken?", "should_trigger": true },
    { "query": "When should we contact a free user of our developer tool?", "should_trigger": true },
    { "query": "Three teams at one bank use us. How do we get the rest of the bank?", "should_trigger": true },
    { "query": "Our champion left and the account went quiet.", "should_trigger": true },
    { "query": "Our free-to-paid conversion is 1.2% and the benchmark is 4% - how bad is that?", "should_trigger": true },
    { "query": "How does developer adoption actually turn into revenue?", "should_trigger": true },
    { "query": "Write a developer-first GTM plan for our observability platform.", "should_trigger": true },
    { "query": "What's the right land-and-expand path for our CLI tool?", "should_trigger": true },
    { "query": "How do we decide which free accounts sales should call?", "should_trigger": true },
    { "query": "Our funnel is broken.", "should_trigger": true },
    { "query": "Is product-led growth right for our database company?", "should_trigger": true },
    { "query": "We're a dev tool with tons of GitHub stars and no revenue. What now?", "should_trigger": true },
    { "query": "Should we add a sales-assisted layer on top of our free tier?", "should_trigger": true },
    { "query": "How do we qualify accounts instead of individual signups?", "should_trigger": true },
    { "query": "Our signups are up 300% and paid accounts are flat.", "should_trigger": true },
    { "query": "What motion should we run - PLG or enterprise sales?", "should_trigger": true },
    { "query": "Design the handoff between our free product and our sales team.", "should_trigger": true },
    { "query": "We want to list on a cloud marketplace instead of selling direct. Good idea?", "should_trigger": true },
    { "query": "How do we expand from one team to the whole engineering org?", "should_trigger": true },
    { "query": "Write the qualification rule for our product-qualified leads.", "should_trigger": true },
    { "query": "Our developers love us but procurement keeps killing the deals.", "should_trigger": true },
    { "query": "When does a human enter the loop in a self-serve devtool business?", "should_trigger": true },
    { "query": "How many of our free users should we be emailing?", "should_trigger": true },
    { "query": "Our board wants us to hire two AEs next quarter. Should we?", "should_trigger": true },
    { "query": "Plan how our open-source project starts making money from companies.", "should_trigger": true },
    { "query": "What leading indicators tell us our GTM is working before revenue moves?", "should_trigger": true },
    { "query": "We sell top-down to CISOs but the developers hate the product. Fix it.", "should_trigger": true },
    { "query": "Should our free tier exist to feed sales, or to convert on its own?", "should_trigger": true },
    { "query": "Our net revenue retention is 103%. Investors say that's bad. Is it?", "should_trigger": true },
    { "query": "How do we get from self-serve card payments to six-figure contracts?", "should_trigger": true },
    { "query": "Map the path from a developer running our SDK to a signed enterprise deal.", "should_trigger": true },
    { "query": "Which go-to-market motions should we rule out, and why?", "should_trigger": true },
    { "query": "We have no idea who to call and who to leave alone.", "should_trigger": true },
    { "query": "Is our growth problem a funnel problem or a spread problem?", "should_trigger": true },
    { "query": "we've got loads of installs and basically zero money coming in, help", "should_trigger": true },
    { "query": "should we just email everyone who signs up?", "should_trigger": true },
    { "query": "how do devtools actually make money off free users", "should_trigger": true },
    { "query": "our devs adopt it and then nothing happens, what do we do", "should_trigger": true },
    { "query": "everyone signs up, nobody pays, what's the play here", "should_trigger": true },
    { "query": "do we need salespeople or can the product sell itself", "should_trigger": true },
    { "query": "how do we stop leaving money on the table with our free tier", "should_trigger": true },
    { "query": "we keep switching strategy every quarter and nothing sticks", "should_trigger": true },
    { "query": "what do we do with the 40 signups we just got from one company", "should_trigger": true },
    { "query": "can we actually do land and expand or is that just a phrase", "should_trigger": true },
    { "query": "our biggest account renewed flat, how do we grow it", "should_trigger": true },
    { "query": "the free plan is huge and the paid plan is tiny", "should_trigger": true },
    { "query": "when do we go upmarket", "should_trigger": true },
    { "query": "who should we be talking to inside the customer, the dev or their boss", "should_trigger": true },
    { "query": "Engineers install our thing in five minutes but nobody ever upgrades.", "should_trigger": true },
    { "query": "We have a lot of usage and very little revenue. Where do we start?", "should_trigger": true },
    { "query": "Our product spreads by word of mouth among engineers but the contracts never get bigger.", "should_trigger": true },
    { "query": "People adopt us on side projects and never bring us in at work.", "should_trigger": true },
    { "query": "We can't tell which company a user works for, and that seems to matter.", "should_trigger": true },
    { "query": "Someone opened our SSO settings page yesterday. Does that mean anything?", "should_trigger": true },
    { "query": "How do we decide whether to put a human in front of an account?", "should_trigger": true },
    { "query": "Our tool needs a Kubernetes cluster before it does anything useful. Is a free tier even possible?", "should_trigger": true },
    { "query": "We're deciding whether to put the free version behind a signup form.", "should_trigger": true },
    { "query": "The thing that gets adopted and the thing that gets bought are different. How do we connect them?", "should_trigger": true },
    { "query": "Half our users are hobbyists and half work at banks, and we built one onboarding for both.", "should_trigger": true },
    { "query": "Our first contract came from someone who'd used the free version for a year. How do we make that repeatable?", "should_trigger": true },
    { "query": "We want to stop guessing about which accounts are real.", "should_trigger": true },
    { "query": "How do we prove to the board that adoption will become revenue?", "should_trigger": true },
    { "query": "A partner wants 20% of every deal they source for us. Is that worth it?", "should_trigger": true },
    { "query": "We never wrote down who we're not allowed to contact.", "should_trigger": true },
    { "query": "Write the memo that tells the team how we turn usage into contracts.", "should_trigger": true },
    { "query": "What should we charge for our API's enterprise tier?", "should_trigger": false },
    { "query": "Design our value metric - should we price on seats or on consumption?", "should_trigger": false },
    { "query": "Where should our free tier limits sit, in requests per month?", "should_trigger": false },
    { "query": "Should we be open core or hosted open source?", "should_trigger": false },
    { "query": "Pick a license for our new project.", "should_trigger": false },
    { "query": "Cut our developer audience into named, sized segments.", "should_trigger": false },
    { "query": "Map the developer journey from discovery through to advocacy.", "should_trigger": false },
    { "query": "Build our DevRel measurement framework.", "should_trigger": false },
    { "query": "Which of our DevRel metrics are vanity metrics?", "should_trigger": false },
    { "query": "Write the event taxonomy for tracking our docs and blog.", "should_trigger": false },
    { "query": "Design our developer relations program from scratch.", "should_trigger": false },
    { "query": "Split our DevRel budget across events, content and community.", "should_trigger": false },
    { "query": "Should our product become a platform other companies build on?", "should_trigger": false },
    { "query": "Write a quickstart that gets someone to hello world in five minutes.", "should_trigger": false },
    { "query": "Rewrite our README so a newcomer understands what the project does.", "should_trigger": false },
    { "query": "Where should we distribute our npm package to get more downloads?", "should_trigger": false },
    { "query": "Should we start a Discord for our users?", "should_trigger": false },
    { "query": "How do we measure whether our community is healthy?", "should_trigger": false },
    { "query": "Write a code of conduct for our Slack workspace.", "should_trigger": false },
    { "query": "Design an ambassador program with perks for our top contributors.", "should_trigger": false },
    { "query": "Turn this customer's production deployment into a technical case study.", "should_trigger": false },
    { "query": "Plan our open-source launch on Hacker News.", "should_trigger": false },
    { "query": "Who decides what gets merged in our project?", "should_trigger": false },
    { "query": "Set up issue triage so our maintainers don't burn out.", "should_trigger": false },
    { "query": "Make it easier for a stranger to land their first pull request.", "should_trigger": false },
    { "query": "Which open-source projects should our company sponsor?", "should_trigger": false },
    { "query": "Build sponsorship tiers for our open-source project.", "should_trigger": false },
    { "query": "Should we donate the project to a foundation or keep it in-house?", "should_trigger": false },
    { "query": "How should we engage with the OpenTelemetry specification?", "should_trigger": false },
    { "query": "What should we open source and what stays proprietary?", "should_trigger": false },
    { "query": "Write the release notes for version 4.0.", "should_trigger": false },
    { "query": "Write the migration guide for our breaking v3 change.", "should_trigger": false },
    { "query": "Write a tutorial that teaches people our query language.", "should_trigger": false },
    { "query": "Turn our support tickets into troubleshooting pages.", "should_trigger": false },
    { "query": "Audit our documentation against Diátaxis.", "should_trigger": false },
    { "query": "Set a policy for code samples in our documentation.", "should_trigger": false },
    { "query": "Make our docs readable by coding agents.", "should_trigger": false },
    { "query": "Fix the canonical tags on our versioned docs site.", "should_trigger": false },
    { "query": "Find the error strings developers are actually searching for.", "should_trigger": false },
    { "query": "Write an engineering blog post about our storage engine rewrite.", "should_trigger": false },
    { "query": "Plan a quarter of developer content with owners and dates.", "should_trigger": false },
    { "query": "Benchmark our closest competitor's DevRel motion.", "should_trigger": false },
    { "query": "Which conferences should we sponsor, and at which tier?", "should_trigger": false },
    { "query": "Write a CFP submission for a cloud-native conference.", "should_trigger": false },
    { "query": "Outline my accepted 30-minute conference talk.", "should_trigger": false },
    { "query": "Script a screencast introducing our new SDK.", "should_trigger": false },
    { "query": "Make sure my live demo doesn't break on stage.", "should_trigger": false },
    { "query": "Prep me for a podcast interview next week.", "should_trigger": false },
    { "query": "Pitch our funding round to tech press.", "should_trigger": false },
    { "query": "Should DevRel report to marketing or to engineering?", "should_trigger": false },
    { "query": "Write the job posting for a developer advocate.", "should_trigger": false },
    { "query": "How do I break into developer advocacy?", "should_trigger": false },
    { "query": "Should we build a certification program for our platform?", "should_trigger": false },
    { "query": "Optimize my GitHub profile README.", "should_trigger": false },
    { "query": "How do we get senior engineers to want to work here?", "should_trigger": false },
    { "query": "Should I start posting our revenue numbers publicly?", "should_trigger": false },
    { "query": "Start a monthly meetup in Berlin for our users.", "should_trigger": false },
    { "query": "Route my current DevRel task to the right skill in the collection.", "should_trigger": false },
    { "query": "Which DevRel newsletters and podcasts should I follow?", "should_trigger": false },
    { "query": "Build the go-to-market plan for our HR compliance software sold to CHROs.", "should_trigger": false },
    { "query": "Design a sales funnel for our marketing agency's lead generation.", "should_trigger": false },
    { "query": "I'm a solo founder selling to restaurants - how do I close my first ten deals?", "should_trigger": false },
    { "query": "Which funnel platform should I use for my course launch?", "should_trigger": false },
    { "query": "Set up a self-hosted funnel and email sequence for my info product.", "should_trigger": false },
    { "query": "Price our consumer fitness app's subscription tiers.", "should_trigger": false },
    { "query": "Analyze our mobile game's day-7 player retention curve.", "should_trigger": false },
    { "query": "Write cold outbound emails to 500 CFOs about our expense tool.", "should_trigger": false }
  ]
}

# Worked example: a developer-first GTM memo

Contents: a full memo that passes; the same product's failing memo, annotated; weak-versus-strong lines section by section.

The company below is fictional and the numbers are invented - no company publishes a motion memo with real figures. Use it for the _shape_ of each section and for the positive-versus-negative contrast, never as a benchmark. Published figures that _can_ be quoted live in `sourced-benchmarks.md`.

**Context.** Sprocketd is a hosted feature-flag and configuration service. Open-source SDKs, hosted control plane. Roughly 6,000 free accounts, 40 paying, mostly single-team. Two founders, one engineer doing part-time customer work, no sales hire.

---

# Developer-first GTM - Sprocketd

## Table of Contents

- [Constraints](#constraints)
- [Friction gates](#friction-gates)
- [Rejected motions](#rejected-motions)
- [Primary motion](#primary-motion)
- [Entry design](#entry-design)
- [Handoff rule](#handoff-rule)
- [Expansion path](#expansion-path)
- [Leading indicators](#leading-indicators)
- [Refused](#refused)
- [Revisit triggers](#revisit-triggers)
- [The same product's failing memo](#the-same-products-failing-memo)
- [Weak versus strong, section by section](#weak-versus-strong-section-by-section)

## Constraints

Business model is consumption plus an organization tier; the paid boundary is environments, flag-evaluation volume and the governance features (audit log, approvals, SSO). Product friction is low: the SDK works against a hosted sandbox with a key issued instantly, no infrastructure. Response capacity is one engineer for roughly five hours a week - any rule producing more than a handful of conversations a week is fiction.

## Friction gates

- **Entry - pass.** Cold run on a clean machine: docs to first flag evaluated in 6 minutes, four steps, one of them (create account) deferrable behind a sandbox key. Removing it is scheduled.
- **Value - partial.** A single developer sees a flag flip in their own app, which is real value. Approvals, audit and environment separation only matter once a second team exists. Bottom-up is therefore the entry, not the whole motion.
- **Spread - pass, weakly.** The SDK config lands in a shared repo and flag names appear in pull requests, so a second developer usually sees it. But nothing forces an invite; 71% of accounts still have exactly one active developer after 60 days.

## Rejected motions

- **Top-down with developer proof** (rejected): no existing budget line for feature management at our target accounts; the spend today is inside platform-team salaries.
- **Ecosystem-mediated** (premature, not rejected): cloud-marketplace listing is attractive for procurement drawdown, but we have no partner enablement capacity this year. Revisit when a second person can own it.

## Primary motion

Bottom-up self-serve, with developer-influenced sales as the secondary once account rollup ships. Money path: developer adopts in the sandbox → team adopts in staging → production deployment and a second environment cross the volume boundary → card for the team plan, or a conversation for the organization tier.

Prerequisite that must hold: individual developers can pay the team plan without approval. Verified on 14 of the 40 current paying accounts.

## Entry design

First-value moment: **a flag the developer created flips behaviour in their own running application.** Steps to it: 4 today, 3 after the sandbox-key change. Always open, never gated: full documentation, pricing page with real numbers, all limits, the SDK source, and the error/troubleshooting pages.

## Handoff rule

Account rollup from workspace object plus email domain, shipping this quarter.

> An account becomes qualified when it has **3 or more active developers** and **4 weeks of production evaluations**, or when **anyone in it opens the SSO, audit-log or security-questionnaire page**. Qualified accounts are contacted by **the founding engineer** within **48 hours** with **an environment-and-limits review offer**. Accounts below the threshold are **not contacted by a human**.

Thresholds derived from our own data: paying accounts had a median of 3.5 active developers and 5 weeks of production usage before their first payment. Expect roughly 6 qualified accounts a month, which fits the five-hour budget.

Routing: developer gets the limits review; champion gets the enablement pack (internal case, re-runnable rollout benchmark, migration path from the home-grown flags they usually have, risk answers, cost comparison against building it); security gets the questionnaire pack unprompted.

## Expansion path

- Single-team accounts → _more developers, same team_: product-owned, triggered by a second developer appearing; the fix is an invite prompt at the moment a flag is shared, which does not exist yet.
- Multi-team accounts → _more teams, same company_: founder-owned, triggered by a new workspace on a known domain; requires the platform team to standardize, so the pack must survive an architecture review.
- All accounts → _more workload_: product-owned, triggered by first production deploy and by repeated limit hits.

Multi-threading rule: no account above the qualification threshold has fewer than two engaged contacts, one of them manager-level.

## Leading indicators

| Indicator                                      | Today                            | Target                   | By        |
| ---------------------------------------------- | -------------------------------- | ------------------------ | --------- |
| Accounts reaching first value in first session | 38%                              | 55%                      | end of Q3 |
| Accounts with 2+ active developers at day 60   | 29%                              | 45%                      | end of Q4 |
| Qualified accounts contacted within 48h        | not measured                     | 90%                      | end of Q3 |
| Cohort account free-to-paid at 90 days         | 0.7%                             | 1.5%                     | end of Q4 |
| Net revenue retention                          | not measurable yet (n too small) | report from Q1 next year | -         |

## Refused

No outbound to accounts below the threshold. No gated documentation, pricing or limits. No enterprise-only tier without a self-serve team plan underneath it. No paid tier for basic authentication hardening.

## Revisit triggers

A cloud provider ships a competing managed feature-flag service; qualified-account volume exceeds 15 a month (needs a dedicated responder); day-60 multi-developer share stays below 35% two quarters running (the spread mechanic is the problem, not the funnel); first partner offers co-selling.

---

## The same product's failing memo

This version reads well in a board deck and cannot be executed. Every line below is a real pattern, not a strawman; the annotation says what breaks.

> ## Motion
>
> Sprocketd runs a **PLG motion** with an enterprise sales layer for larger accounts. We will also pursue cloud marketplace and partner channels opportunistically.

Three motions declared as one, no rejection stated, so every one of them gets re-proposed next quarter. "Opportunistically" is how a motion with no owner is written down.

> ## Conversion
>
> Our free-to-paid conversion is 0.7% against an industry benchmark of 3-5%, so conversion is our top priority for the year.

The benchmark is real but it is the wrong row: developer-focused companies convert at a 5% median, half of everyone else, and the 3-5% band assumes account-level cohort measurement over six months. This memo compares a lifetime user-level ratio against a cohort account-level band and concludes the funnel is broken. The number that matters - 71% of accounts still have one developer at day 60 - is a spread problem, and it is not in the memo at all.

> ## Qualification
>
> Sales reaches out to high-intent users. We score leads on pricing-page visits, docs visits, email opens and signup recency, and route anything above 60 points.

Users, not accounts: forty sign-ups from one bank become forty leads and forty emails. The signals are marketing exposure rather than product usage, which is the MQL construction wearing a PQL label. No owner, no response window, and no statement of who is deliberately never contacted - so in practice everyone is.

> ## Expansion
>
> Land and expand. Once we have a foothold we grow the account through quarterly business reviews and upsell conversations at renewal.

No vector, so nobody can tell whether this account grows by seats, teams, workload or surface - and those need different owners. Triggers are calendar-driven, which means the conversation happens when the contract says so rather than when the account does something.

> ## Hiring
>
> We will hire two AEs in Q1 to capture the enterprise demand we know is there.

Never tested against the 4x fully-loaded-cost bar, and the current account base is majority single-developer. The reps arrive, find nothing to work, and start emailing sign-ups - which damages the free surface the whole motion depends on.

> ## Metrics
>
> Signups, MAU, ARR, and NPS.

All four are lagging or unactionable. None of them moves before revenue, so nothing here can tell the team the motion is failing while there is still time to change it.

---

## Weak versus strong, section by section

**Motion choice**

- Weak: "We'll run a PLG motion with a sales-assisted layer for enterprise."
- Strong: names the money path, the prerequisite verified against real accounts, and what was rejected and why.

**Entry design**

- Weak: "Improve onboarding and reduce time to value."
- Strong: names the first-value event, counts the mandatory steps, and states what stays ungated forever.

**Handoff rule**

- Weak: "Sales follows up with high-intent users."
- Strong: one sentence with numbers derived from own data, an owner, a response window, a technical offer, and an explicit do-not-contact line.

**Expansion**

- Weak: "Land and expand into the enterprise."
- Strong: a vector per account segment, a trigger that fires on an observed event, an owner, and a multi-threading rule.

**Indicators**

- Weak: "Track signups, MAU and revenue."
- Strong: a small set that moves before revenue, each with a current value, a target and a date - plus an honest "not measurable yet" where the sample is too small.

# Handoff and expansion playbook

Contents: account rollup; the three signal families; the threshold rule template; contact routing by role; the champion enablement pack; expansion vectors and triggers; enterprise blockers; the numbers that prove expansion is real.

## Account rollup

Qualification happens at account level. Individual usage is the input, an account is the unit. Sources, roughly in order of reliability:

| Source                                       | Strength                               | Weakness                                                        |
| -------------------------------------------- | -------------------------------------- | --------------------------------------------------------------- |
| Organization/workspace object in the product | Authoritative, matches how they use it | Only exists if the product models teams                         |
| License key, API key or install ID           | Ties usage together across users       | Says nothing about which company                                |
| Email domain                                 | Cheap, immediate                       | Free-mail addresses and contractors leak; subsidiaries fragment |
| Self-reported company at signup              | Free text a human can act on           | Frequently blank or joking                                      |
| Enrichment from IP/company data              | Fills gaps at scale                    | Guesses, and looks invasive if quoted back at the user          |

Combine at least two. If none is available, building rollup is the first line item of the plan - every rule below depends on it.

## The three signal families

**Depth - is the product doing real work?**

- Production environment flag.
- Sustained volume over weeks (not a one-day spike).
- Integration into CI/CD or a deploy pipeline.
- Data retained rather than sampled.
- Repeat sessions across several weeks.

**Spread - is more than one human involved?**

- Second and third active developer in the same account.
- Invites sent and accepted.
- A shared workspace or project.
- Several repositories or services instrumented.
- A config file committed to a shared repo.

**Boundary contact - did someone touch something only an organization needs?**

- Visited or clicked SSO/SAML, RBAC, audit-log or compliance pages.
- Hit a rate, seat or retention limit repeatedly.
- Requested a security questionnaire, SOC 2 report or DPA.
- Opened billing, invoicing or procurement pages.
- Asked about self-hosting or data residency.

Boundary contact is the rarest and strongest signal because it maps one-to-one onto the paid boundary the business model defined.

- Depth without spread usually means a solo power user.
- Spread without depth usually means an evaluation that has not committed.

**A published cross-check.** Zapier's four sales-assist qualification signals, reported in _What is good free-to-paid conversion_:

- multiple active users on one domain
- usage growing over time
- a use case indicating the customer would benefit from help
- a role matching the ICP

Three of the four are spread and depth; the fourth is firmographic. Notably, the same source reports that sales touchpoints improved not only conversion but post-purchase retention - the argument against treating assisted contact as a tax on the free surface.

**Two dimensions, not one score.** _The Transition_ scores sign-ups on two axes:

- **observable** factors - title, company and size, corporate versus personal email domain, organisation size
- **behavioural** factors - completed or abandoned sign-up, feature breadth, frequency, activation depth, several users on one domain

Routing follows from the pair:

- high observable with low behavioural is a conversion-assist opportunity
- high observable with high behavioural is an expansion opportunity
- low observable is tech touch only, whatever the behaviour

The same source's advice on where to start is worth taking literally: post new sign-ups into an internal channel and have a human read them for a few weeks before building any scoring system.

Reject the MQL construction while you are here: a lead that accumulates points for opening an email and visiting the pricing page tells you about marketing exposure, not about a developer's product usage. Tuning its weights is the wrong project.

## Threshold rule template

Write one sentence, fill the blanks from your own conversion data - the percentile at which accounts historically start paying - and review it quarterly:

> An account becomes qualified when it has **N or more active developers** and **M weeks of production usage**, or when **anyone in it makes boundary contact**. Qualified accounts are contacted by **<role>** within **<hours>** with **<technical offer>**. Accounts below the threshold are **not contacted by a human**; they receive product and documentation surfaces only.

Rules for choosing N and M:

- derive them from the accounts that already converted
- prefer the value that produces a queue the responder can actually clear
- never copy a threshold from another company's blog post, since cohort shapes differ too much for the number to transfer

Before writing any threshold, check that a human belongs in the loop at all. _The Transition_ offers the arithmetic: a salesperson should return about **4x their fully loaded cost** in incremental revenue. If the qualified-account volume times realistic deal size cannot clear that, the honest answer is a better product surface, not a rule.

One statistic to keep out of this section: the widely repeated "contact within 5 minutes and you are 21x more likely to qualify". It comes from inbound form-fill research in sales-led funnels, usually cited to a vendor blog rather than the underlying study, and importing it into a developer motion argues for contacting on sign-up - the single behaviour this audience punishes hardest.

## Contact routing by role

| Role                                     | First contact should be                                                                                                              | Never send them                                        |
| ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------ |
| Active developer                         | Help with the thing they are actually doing: a limits/quota conversation, an architecture review, a migration hand, a bug they filed | "15 minutes to learn about your needs"                 |
| Technical champion                       | The enablement pack below, framed as material for _their_ internal case                                                              | A pitch deck they cannot re-use internally             |
| Approver (security, architecture, legal) | The risk answers unprompted: license, data handling, SLA, security posture, exit plan                                                | Feature marketing                                      |
| Economic buyer                           | Cost comparison against status quo and the do-nothing option, ideally introduced by the champion                                     | A cold email that bypasses the champion and burns them |

## The champion enablement pack

The highest-leverage artifact in company adoption, because the champion argues in rooms you are not in. Contents:

1. A one-page internal case: problem, what changed after adoption, numbers taken from _their own_ usage.
2. A benchmark or proof they can re-run and defend as their own work.
3. A reference architecture and a migration path from what they run today.
4. Pre-answered risk questions: license terms, data handling and residency, SLA and support tiers, security posture and certifications, exit and data-export plan.
5. A cost comparison including the do-nothing option and the build-it-ourselves option.
6. Named references or public case studies in a comparable environment.

Instrument it. A pack that is sent and never opened is evidence that the person you think is a champion is not one yet.

## Expansion vectors and triggers

| Vector                     | What grows                        | Trigger to wire                                                                                | Natural owner                            |
| -------------------------- | --------------------------------- | ---------------------------------------------------------------------------------------------- | ---------------------------------------- |
| More developers, same team | Seats or active users             | Second/third developer joins; invite sent; a shared artifact opened by a new person            | Product (spread mechanics)               |
| More teams, same company   | Accounts or workspaces            | New workspace/domain appears; internal referral; platform-team enquiry                         | Sales or partnerships, with the champion |
| More workload per user     | Consumption                       | First production deploy; new environment or region; limit hit repeatedly; seasonal volume step | Product plus account owner               |
| More product surface       | Second product or governance tier | Org-level need appears (SSO, audit, policy); a second use case gets instrumented               | Account owner                            |

Additional account-level triggers worth wiring regardless of vector:

- a reorg or acquisition
- a renewal approaching with usage above or below plan
- a champion changing employer, which is simultaneously a risk in the old account and a warm entry in the new one

## Enterprise blockers

- **No standardization decision.** Team-by-team adoption plateaus until a platform or architecture group makes the tool a default. In large accounts, expansion strategy is mostly about reaching that decision - which means the champion pack has to survive an architecture review, not a hallway chat.
- **Procurement re-entry.** The second, bigger purchase triggers the security review, legal pass, vendor onboarding and sometimes an RFP that the first credit-card purchase skipped. Prepare the paperwork before the expansion conversation, not during it.
- **Champion single point of failure.** Multi-thread: a second technical advocate plus one manager-level contact, both of whom have seen value with their own eyes.
- **Pricing that punishes growth.** If the next unit of adoption produces an unpredictable bill, developers cap their own usage silently and the account flattens for reasons that never reach a report.

## The numbers that prove expansion is real

- **Net revenue retention** - a cohort's MRR today divided by that same cohort's MRR twelve months ago, including expansion, contraction and churn. Above 100% it means the installed base grows without new logos, the only honest headline for a land-and-expand claim. Read the band for the motion you actually run: published 12-month figures put a bottom-up product's "good" at around 100% and "great" at around 120%, against 110% and 130% for enterprise SaaS.
- Share of accounts with more than one active team.
- Time from first paid to first expansion.
- Share of revenue from expansion versus new logos.
- Count of multi-threaded accounts (two or more engaged contacts).
- **Counter-metric:** expansion produced by price increases or usage the customer did not choose is not expansion, it is deferred churn. Track active seats, not provisioned seats, for the same reason.

# Motion archetypes and the friction gates

Contents: where this taxonomy comes from; the three friction gates in detail; the four motions (money path, prerequisite, what it forces you to build, leading indicator, failure mode, fit signals); combining motions; sequencing by stage.

## Table of Contents

- [Where this taxonomy comes from](#where-this-taxonomy-comes-from)
- [The three friction gates](#the-three-friction-gates)
- [Motion 1 - Bottom-up self-serve](#motion-1-bottom-up-self-serve)
- [Motion 2 - Developer-influenced sales (product-led sales)](#motion-2-developer-influenced-sales-product-led-sales)
- [Motion 3 - Top-down with developer proof](#motion-3-top-down-with-developer-proof)
- [Motion 4 - Ecosystem-mediated](#motion-4-ecosystem-mediated)
- [Combining motions](#combining-motions)
- [Sequencing by stage](#sequencing-by-stage)

## Where this taxonomy comes from

The four motions below are **this skill's synthesis**, not a published framework. Present them that way. They are built on top of a vocabulary that _is_ published, in the Lenny's Newsletter study _GTM motions of 30 B2B SaaS companies_, which separates two independent axes:

- **Product-led** (the product is self-serve; users convert on their own) versus **sales-led** (someone must onboard you before you try it).
- **Top-down** (target leaders who push the tool down) versus **bottom-up** (target individual contributors who spread it).

Plus two useful compound terms from the same source:

- **sales assist** - a sales team closing and expanding the larger accounts that arrived product-led
- **bottom-up lead gen** - a sales-led company whose self-serve product exists to feed leads rather than revenue; worth naming out loud, because teams run it while believing they run product-led growth

The mapping:

- bottom-up self-serve = product-led × bottom-up
- developer-influenced sales = product-led × bottom-up plus sales assist, which the industry calls product-led sales
- top-down with developer proof = sales-led × top-down, with the developer holding a veto rather than the pen
- ecosystem-mediated has no counterpart in the published axes: it is this skill's own addition and the least evidenced of the four

A second published check, from _The Transition: Layering sales onto a bottom-up self-serve product_: self-serve is plausible as a starting motion if at least one of these is true.

- The product is simple enough for **its own audience** to self-activate; complexity is relative, a technical product can be self-serve when the audience is technical.
- The category is new enough that there is nothing to compare against.
- The product can coexist with an incumbent in the same stack rather than requiring a rip-and-replace.
- You can focus on small organisations that have no incumbent yet.

## The three friction gates

Run these before choosing anything. Each gate is answered with evidence - a cold run of your own onboarding on a clean machine, a read of the actual signup flow, or account data - not with an opinion.

### Gate 1 - Entry

Can a developer reach first real value with no account, no approval, no credit card and no conversation?

List every mandatory step between "arrived" and "value", and mark each one _required_, _deferrable_ or _removable_.

Steps that reliably cost you people:

- mandatory signup before any output
- credit card before trial
- waiting for a quota or key to be approved
- installing infrastructure
- needing a second person's permission
- needing a colleague to accept an invite

A failing entry gate does not mean the product is bad. It means the motion cannot be pure bottom-up, and the plan must say so instead of pretending.

### Gate 2 - Value

Is the value visible to one developer working alone, or does it only appear once a team or organization uses the product?

Single-developer value supports a pure self-serve motion. Team-scale value (shared dashboards, policy enforcement, cross-service correlation, collaboration) means the developer can _enter_ alone but the purchase is an organizational decision - a hybrid motion, with a champion pack and a human step.

### Gate 3 - Spread

Does ordinary use create a reason for a second developer to see the product? Examples:

- a shared artifact
- a config committed to the repo
- a link someone must open
- a status check on a pull request
- an invite that is the natural next action

Without a spread mechanism, self-serve produces a long tail of single-seat accounts that never expand, and land-and-expand is not available as a strategy - growth has to come from new logos, which is a far more expensive plan and should be priced as one.

## Motion 1 - Bottom-up self-serve

**Money path.** An individual developer adopts, usage grows, they or their team pay by card. No human on the vendor side is ever required.

**Prerequisite.** All three gates pass, and the paid boundary triggers at something an individual or small team hits on their own (volume, projects, environments, retention of data) rather than at governance features only an enterprise wants.

**What it forces you to build.**

- A product that onboards itself.
- Documentation that answers every pre-purchase question.
- Transparent pricing and limits.
- In-product upgrade paths.
- Billing and dunning.
- Per-account usage analytics.
- Self-serve support scaled by docs and community rather than headcount.

**Effort to stand up.** A quarter of product and docs work, no new headcount, largely reversible - the lowest of the four. The ranked comparison across all four motions lives in the skill's step 3; the lines here only feed it.

**Leading indicator.** Share of new accounts reaching first value in the first session, and cohort free-to-paid conversion at account level.

**Failure mode.** Volume without depth: thousands of accounts that never reach production, never add a second developer and never hit a limit. The free surface becomes a cost centre with a good-looking chart.

**Fit signals.**

- Small initial contracts.
- An individual who can spend without approval.
- A product with an observable spread mechanic.
- A category developers already search for by name.

## Motion 2 - Developer-influenced sales (product-led sales)

**Money path.** Developers adopt the free surface; account-level usage crosses a written threshold; a human runs the organization-level deal from a position of evidence.

_The Transition_ splits this motion into two jobs that need different people and different rules; pick one to start rather than blending them.

- **Penetration/expansion** - unifies scattered pods of users inside one organisation into a single contract and adds more pods. Fits multi-player products; Slack's and Zoom's "account managers" are the cited pattern.
- **Conversion assist** - raises conversion of high-value accounts that signed up and never activated. Fits when deal value justifies a human touching an individual sign-up.

**Prerequisite.** Usage can be attributed to an account, _and_ someone exists who can act on the signal within days. Both halves are required; the signal without the responder is telemetry.

**What it forces you to build.**

- Account rollup and identity resolution.
- A qualification rule with owner and response time.
- A champion enablement pack.
- Procurement-ready paperwork (security questionnaire answers, DPA, SLA, invoicing).
- A compensation and territory model that does not reward contacting every signup.

**Effort to stand up.** A quarter to build the rollup and write the rule, then a standing job to answer the signal within the promised window. Reversible on the human side, less so once compensation is tied to it.

**Leading indicator.** Number of accounts crossing the threshold per month, and the share of them contacted inside the promised window.

**Failure mode.** Either extreme: nobody is ever contacted because the rule was never written, or everybody is, which teaches a developer audience that signing up costs them their inbox.

**Fit signals.**

- Value gate is team-scale.
- The paid boundary is made of organization features.
- Deals are mid-sized.
- There is already a base of free accounts with more than one active developer.

## Motion 3 - Top-down with developer proof

**Money path.** An executive, platform team or architecture group buys; developers are then convinced not to route around it.

**Prerequisite.** A budget line that already exists - the buyer funds this category today. Creating a new budget category top-down is a multi-year effort, not a motion.

**What it forces you to build.**

- Business-case material in the buyer's vocabulary.
- Compliance and security evidence up front.
- A rollout and migration plan.
- A genuine developer experience, the part teams skip, because mandated tools that developers hate get quietly bypassed and churn at renewal.

**Effort to stand up.** A standing sales job, plus coordination across product, security and legal before the first contract, and a compliance evidence base that has to be maintained. The highest of the four, and the slowest to unwind once a team is hired against it.

**Leading indicator.** Post-purchase developer activation inside bought accounts: share of licensed developers actually using the product within 90 days.

**Failure mode.** Shelfware. The contract is signed, adoption never happens, and the renewal conversation has no usage to point at.

**Fit signals.**

- Large contracts.
- Mandatory compliance or governance drivers.
- A concentrated market of known accounts.
- A product that replaces an incumbent the buyer already pays for.

## Motion 4 - Ecosystem-mediated

**Money path.** A platform, cloud marketplace, systems integrator, agency or complementary vendor puts the product in front of developers it already reaches.

**Prerequisite.** A partner whose developers already have the problem, and a revenue share or strategic reason the partner accepts. Cloud marketplaces additionally offer buyers a procurement shortcut (committed spend drawdown), which is often the real value.

**What it forces you to build.**

- Partner enablement material.
- A listing that meets the platform's technical bar.
- Support and escalation across the boundary.
- Margin room for the share.

**Effort to stand up.** A quarter of partner and listing work, coordination across an external boundary you do not control, and permanent margin. Slow to reverse: a listing withdrawn or an exclusivity unwound is visible to the partner's customers.

**Leading indicator.** Qualified accounts sourced per partner per quarter, and the share of partners that are active rather than merely signed.

**Failure mode.** Dependency on a partner whose roadmap eventually includes your product, or a signed-partner list where nobody sells anything.

**Fit signals.**

- The product is a component inside a larger workflow the partner owns.
- Buyers already have committed spend on that platform.
- The direct motion cannot reach the accounts economically.

## Combining motions

Run one primary and at most one secondary. The combinations that work in practice:

- Bottom-up self-serve **plus** developer-influenced sales - the standard developer-tool pattern; self-serve creates the base, assisted sales monetizes the accounts that outgrow it. The interface between them is the qualification rule.
- Developer-influenced sales **plus** ecosystem-mediated - partners source accounts, the same qualification and champion machinery closes them.
- Top-down **plus** bottom-up entry - the buyer signs, but a self-serve entry exists so developers adopt willingly rather than under protest.
- **Refuse:** top-down enterprise pricing with no self-serve floor and no free surface. It leaves the entire long tail unservable and hands the developer mindshare to whoever does offer an entry.

## Sequencing by stage

- **Pre-revenue.** One motion. A second before the first is repeatable produces two half-built funnels and no learning.
- **First revenue.** Instrument before adding. The usual second motion is developer-influenced sales layered on an existing self-serve base, because the accounts already exist and only need rollup and a rule.
- **Scaling.** Motions specialize into different owners (product/growth versus sales), and the handoff rule between them becomes the most valuable artifact the company has. Re-read it every quarter; it decays as the paid boundary moves.

# Sourced benchmarks, and what this skill sets itself

Contents: how to read this file; published free-to-paid conversion bands; the developer-specific conversion finding; measurement definitions; published net-revenue-retention bands; the sales-economics test; numbers this skill sets itself; numbers nobody publishes.

## How to read this file

Two kinds of number appear in a GTM memo and they must never be mixed:

- a **sourced** number comes from a published study or benchmark post; quote it with its source and its measurement definition
- a **self-set baseline** is a defensible starting point with no study behind it; present it as adjustable and say so out loud

Everything in the first four sections is sourced. Everything after "Numbers this skill sets itself" is not.

The published figures below come from Lenny's Newsletter benchmark posts, treated as well-attributed; re-check the live post before publishing as fact:

- _What is good free-to-paid conversion_
- _What is good retention?_
- _The Transition: Layering sales onto a bottom-up self-serve product_

## Free-to-paid conversion, by free-surface model

From _What is good free-to-paid conversion_, described as based on a survey of 1,000+ products.

| Free surface               | GOOD  | GREAT  |
| -------------------------- | ----- | ------ |
| Freemium, pure self-serve  | 3-5%  | 6-8%   |
| Freemium with sales-assist | 5-7%  | 10-15% |
| Free trial, time-limited   | 8-12% | 15-25% |

Related findings from the same source:

- sign-up rate is lower for free-trial products than for freemium (5% vs. 9%)
- reverse trials convert at roughly twice classic freemium at similar sign-up rates
- larger target customers correlate with lower conversion
- 40-60% of new users never return after day one
- 44% of free-trial companies have sales contact more than half of sign-ups, against 24% of freemium companies

## The developer-specific finding

**Developer-focused companies show a median free-to-paid conversion of 5% - half the median of non-developer-focused companies** (same source).

This is the single most useful published number for this skill. A developer tool converting at 2% is not obviously broken and a blended B2B benchmark will tell it that it is. Use the figure to reset expectations, not as a target: a median is the middle of a distribution that includes products with a very different paid boundary from yours.

## Measurement definitions the bands assume

Quoting a band while measuring differently is how these get misused.

- Free-to-paid = accounts that begin paying within their first six months ÷ accounts created in the measurement window.
- Measure by cohort. A lifetime ratio flatters any product whose sign-ups grew.
- Define at account level - one user or a group of them - not per user.
- Report per audience as well as blended.
- Net revenue retention = a cohort's MRR today ÷ that same cohort's MRR twelve months ago.

## Net revenue retention, 12-month

From _What is good retention?_ - a survey of roughly twenty named growth practitioners, not a single published headline figure. Each expert gave their own GOOD/GREAT number per business model; the row below is this skill's compression of that spread into one representative point per cell, generally set at or near the low end of the reported range.

| Business model                       | GOOD  | GREAT |
| ------------------------------------ | ----- | ----- |
| Bottom-up SaaS                       | ~100% | ~120% |
| Land-and-expand, very small business | ~80%  | ~100% |
| Land-and-expand, SMB and mid-market  | ~90%  | ~110% |
| Enterprise SaaS                      | ~110% | ~130% |

Read the row that matches the motion actually chosen, not the aspirational one. A bottom-up product measuring itself against the enterprise row will conclude that expansion has failed when it is performing normally.

## The sales-economics test

From _The Transition_: a salesperson added to a self-serve motion should return roughly **4x their fully loaded cost** in incremental revenue.

Apply this before arguing about which motion to run. It converts "should we hire a rep?" into arithmetic: incremental revenue per rep must clear four times salary plus overhead, which for most single-developer-account products means the answer is no until account rollup exists and multi-developer accounts are common.

The same source names the opposite risk: waiting too long to add sales lets sales-assisted competitors firewall a self-serve-only product out of enterprise segments - Dropbox is the cited casualty. Both failure directions are real; the 4x test is what tells you which one you are in.

## Numbers this skill sets itself

These are this skill's own baselines. They are internally consistent and reasoned, and **no published study supports them**. Move them when your data says otherwise.

- One primary motion, at most one secondary.
- Two or three candidate motions presented before a recommendation, never one.
- A qualification threshold expressed as one sentence.
- A response window measured in hours, not days, for accounts above the threshold.
- Multi-threading defined as two engaged contacts, one of them manager-level.
- A leading-indicator set of five or fewer numbers.
- Quarterly review of the threshold sentence.
- The step 3 motion ordering - effort, value and efficiency across the four motions, and the effort magnitudes behind it. Reasoned from what each motion forces a company to build, hire and coordinate; nothing published ranks GTM motions this way, and the order is meant to be re-ranked against what a given team already has.

## Numbers nobody publishes

Searched for and not found, so derive them from your own cohorts and label them accordingly:

- deal-size cut-offs separating self-serve, inside and field sales
- time-to-first-value targets for developer products
- PQL-to-opportunity conversion for developer tools
- the share of accounts that should reach a depth signal
- how many active developers an account needs before it converts

That last one is the number a threshold rule depends on most, and it is company-specific by construction - a product whose paid boundary is volume and one whose boundary is seats will disagree by an order of magnitude.

---
name: developer-first-gtm
description: Designs the go-to-market motion for a developer-facing product - bottom-up self-serve adoption, developer-influenced sales, top-down with developer proof, or ecosystem-mediated distribution - plus the self-serve entry, the developer-to-buyer handoff rule and the land-and-expand path. Use whenever a founder, devrel or growth owner asks how developer adoption turns into revenue, whether to go bottom-up or hire sales, when to contact a free user, why signups are high and paid accounts flat, or how landed teams expand across an enterprise - even if they only say "our funnel is broken". Not price points - use samber/developer-relations-skills@devtools-pricing-strategy.
license: MIT
metadata:
  author: Samuel Berthe
  version: "1.0.1"
---

# Developer-First GTM

You are a go-to-market strategist for developer-facing products. You decide **how a developer's first success becomes an organization's purchase**, and you write that path down as a motion with rules a team can execute without you.

Developer-first GTM fails in a specific way: adoption is real, loved, and public, and revenue does not follow. That happens because the motion was assumed rather than designed - usually assumed bottom-up, because bottom-up sounds cheap. Every recommendation here has to survive one test: name the moment usage becomes a reason for someone with budget to act, and name who acts.

This is a strategy skill. You produce a motion decision with its handoff rules, expansion path and leading indicators - not a pricing page, not a campaign calendar, not a launch plan.

## Typical invocations

- "We have 8,000 free signups and 11 paying customers - what's broken?" → run the full workflow; the friction gates in step 2 and the handoff rule in step 5 usually locate it.
- "Should we hire a sales rep or double down on self-serve?" → step 1 constraints, then step 3 with those two motions as the candidate set.
- "When should we contact a free user?" → step 5 alone; output the qualification rule, the routing and the deliberate do-not-contact line.
- "Three teams at one bank use us. How do we get the rest of the bank?" → steps 6 and 7; expansion by vector, not a bigger discount.
- "Our champion left and the account went quiet." → step 6's multi-threading and champion-change trigger.
- "Our conversion is 1.2% and the benchmark is 4% - how bad is that?" → the measurement section; re-measure at account level by cohort first, then compare against the developer-specific median rather than the blended one.

## Interview

Ask one question at a time, multiple-choice where you can. Stop as soon as you can name the product surface, the current adoption evidence and who signs; confirm the rest as you go.

**Memory: Store a few info about the current task or project context. When memory lives in a file, use `devrel-context.md`; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.**
1. What does a developer install, call or run - a library, CLI, self-hosted server, hosted API, IDE/agent extension, platform?
2. What has to happen before they get value the first time: an account, a credit card, an API key, infrastructure, a security review, a colleague?
3. Is the value visible to one developer alone, or only once a team or org uses it?
4. What is the business model and where is the paid boundary today (free vs paid, self-hosted vs hosted, individual vs organization features)?
5. What is the current evidence: signups, active accounts, paying accounts, expansion, and how confident are those numbers?
6. Can you tell which company a free user belongs to, and can you roll usage up to an account today?
7. Who has ever signed a contract for this product, and what triggered it - did they contact you, or did you contact them?
8. Who exists on your side to act on a signal: nobody, a founder, one rep, a team? How fast can they respond?
9. Which developer audiences matter - individuals and small teams, engineering teams inside companies, or platform/infrastructure groups?
10. What is off the table: no sales team, no gated docs, no cold outbound, a public promise about the free tier, a partner exclusivity?
11. By when must this show revenue movement - a board meeting, a runway date, a renewal, or nothing fixed?
12. Do you want a one-off win this quarter, or a compounding asset that keeps paying: a free surface that grows itself, a partner channel, a repeatable qualification machine?
13. What is your effort ceiling: hours of product work, headcount you can actually hire this quarter, coordination you can get from security and legal, and how reversible the choice has to stay?

Those last three set the ranking in step 3, so ask them before any motion is discussed.

- A hard near date promotes developer-influenced sales when a free base already exists, and demotes anything needing a hire.
- A compounding mandate promotes bottom-up self-serve, whose base every other motion later draws from.
- A ceiling of no new headcount deletes top-down with developer proof outright.
- A refusal to give up margin deletes ecosystem-mediated.

Record the answers. If your harness has persistent memory, store the motion chosen, the qualification rule and the refused options - every later content, community and pricing decision reuses them.

## Step 1 - Fix the constraints before exploring anything

Three facts narrow the field before any brainstorming, and getting them wrong invalidates everything below.

- **The business model already decides who can be in the loop.** Deal size sets whether a human can afford to touch a deal at all, and the paid boundary sets when a human becomes necessary. If the model is undecided, stop and settle it first - see `samber/developer-relations-skills@devtools-business-model`.
- **Product friction is a property, not a preference.** If first value needs infrastructure, approval or a second person, no amount of funnel work makes the motion bottom-up.
- **Capacity to respond is real.** A qualification signal nobody can act on within days is telemetry, not a motion. Design the motion the team can actually staff this quarter.

Run the sales arithmetic before debating motions: a salesperson added to a self-serve motion should return roughly 4x their fully loaded cost in incremental revenue (Lenny's Newsletter, _The Transition_). If qualified-account volume times realistic deal size cannot clear that bar, no motion with a human in it is available yet.

Then hold the opposite risk in view. Pete Kazanjy (Founding Sales, Atrium): never mistake your lead gen for your business - self-serve at $19-29 a month is lead generation, the business is the $50K-$250K contract, and even Datadog and New Relic run sales organizations. The question is _when_ a human enters, not whether.

State all three constraints out loud before proposing anything.

## Step 2 - Run the three friction gates

Bottom-up viability is testable. Answer each gate with evidence - a cold run of your own onboarding counts as evidence, a belief does not.

1. **Entry gate** - can a developer reach first real value with no account, no approval, no card and no call? List every mandatory step and mark which are removable. Hila Qu (Reforge, previously GitLab) gives the test in the user's own terms on Lenny's Podcast: no approval from a boss needed - "You can use it today."
2. **Value gate** - is the value there for one developer, or only at team scale? Collaborative value means bottom-up is the _entry_, not the _motion_.
3. **Spread gate** - does normal use create a reason for a second developer to see it (a shared artifact, a config in the repo, a link, a PR)? Without spread, self-serve produces single-seat accounts that never expand.

- Failing gate 1 rules out bottom-up outright.
- Failing gate 2 or 3 means you need a hybrid: developer entry, human-assisted or platform-level conversion.

## Step 3 - Brainstorm the motion space, do not jump to an answer

Enter brainstorming mode explicitly and say so.

Widen first: walk the four motions in [references/motion-archetypes.md](./references/motion-archetypes.md) - bottom-up self-serve, developer-influenced sales, top-down with developer proof, ecosystem-mediated. **Delete** every motion a step 1 constraint, a failed gate or an interview answer rules out, and record each deletion under "Rejected motions" with the constraint that killed it - a motion carried at the bottom of the menu instead of removed comes back as scope next quarter. A motion blocked only for now goes to the memo's revisit triggers, not back onto the menu.

Present the taxonomy as what it is: these four motions are this skill's synthesis, not a published framework. The published vocabulary underneath is two independent axes - product-led versus sales-led, and top-down versus bottom-up - plus _sales assist_ (Lenny's Newsletter, _GTM motions of 30 B2B SaaS companies_).

The same source names _bottom-up lead gen_: a sales-led company whose free product exists to feed leads rather than revenue. Use the term - a team running bottom-up lead gen while calling it product-led growth will argue about its funnel for years until someone names the motion correctly.

Then rank what survives, and say the ranking out loud. Effort is what the company must build or hire, the coordination it needs from security and legal, and how reversible the choice is - never a budget figure.

- effort: top-down with developer proof > ecosystem-mediated > developer-influenced sales > bottom-up self-serve
- value: top-down with developer proof > developer-influenced sales > ecosystem-mediated > bottom-up self-serve
- efficiency: developer-influenced sales > bottom-up self-serve > ecosystem-mediated > top-down with developer proof

Read those as orders of magnitude:

- Bottom-up self-serve is a quarter of product work and no new headcount, and each account it lands is card-sized.
- Developer-influenced sales is a quarter to build the rollup and the rule, then a standing job to answer the signal; it leads on efficiency without leading on either input, because it converts accounts you already paid to acquire.
- Ecosystem-mediated is a quarter of partner work plus permanent margin, and a listing is slow to walk back.
- Top-down with developer proof is a standing sales job plus compliance evidence, and it commits product, security and legal before the first contract.

The efficiency order starves top-down with developer proof: highest value, highest effort, so it loses every round it is ranked in. Promote it anyway when:

- the buyer already funds this category today
- the market is a concentrated list of known accounts
- a compliance mandate rather than a developer decides the purchase

Promote ecosystem-mediated the same way when buyers' committed cloud spend is the only procurement path into them, because no direct motion reaches that budget at any effort.

Treat all three lines as a default, not a law - they move with context and with who executes them. Re-rank against what the interview already told you:

- an existing base of free accounts with rollup in place pushes developer-influenced sales further ahead
- no free surface yet, with a passing entry gate, puts bottom-up self-serve first, since motion 2 has nothing to convert
- an in-house partner team or a marketplace listing already live promotes ecosystem-mediated past both

Then present **two or three candidate motions**, never one, in efficiency order and led by your recommendation. For each, cover:

- the money path
- the prerequisite that must be true
- what the company must build or hire
- what it gives up
- the earliest evidence it works
- where it sits on the three lines above

Let the user choose before you detail anything further.

Commit to one **primary** motion and at most one **secondary** that stacks on it. Two primaries mean the decision has not been made, and the team will argue about which funnel every account belongs to. The candidate count and the one-primary rule are this skill's own baselines, not published rules.

## Step 4 - Design the entry the chosen motion needs

Work backwards from first value, and count the steps a developer must survive.

- Name the **first-value moment** concretely ("a passing test run against their own repo", "a trace visible in their own dashboard"), not as "activation".
- Remove or defer every step that is not required to reach it. Signup, card, quota approval and team creation are each a measurable drop; defer what can be deferred until after value.
- Decide what stays open forever: documentation, pricing detail, limits and error/troubleshooting content are read _before_ anyone talks to you. Gating them loses technical evaluations silently.
- For top-down and ecosystem motions the entry still matters - developers who are handed a tool evaluate it the same way, and a bad entry turns them into internal opponents.

Execution detail for this surface belongs to the tactical skills, not here: `samber/developer-relations-skills@developer-quickstart-guide` for the path itself and `samber/developer-relations-skills@readme-optimization` for the first screen.

## Step 5 - Write the developer-to-buyer handoff rule

Adoption is measured per developer and revenue is booked per account; this step writes the rule that bridges them.

1. **Roll usage up to an account** - email domain, workspace/organization object, license or API key, self-reported company. Imperfect beats absent; if none exists, that is a build item, not a footnote.
2. **Pick the signals**, in increasing order of intent: depth (production use, sustained volume, CI integration), spread (second and third active developer, invites, shared workspace), boundary contact (someone touched SSO, audit, limits, security questionnaire, billing). Boundary contact is the strongest because it maps directly onto the paid boundary.
3. **Write the threshold as one sentence** the team can apply without interpretation, with numbers taken from your own conversion data rather than a published benchmark.
4. **Say what happens above it**: who reaches out, within how many hours, with a technical offer (architecture review, limits conversation, migration help, security pack) - never "15 minutes to learn about your needs". Jeanne DeWitt Grosser (Vercel, previously Stripe and Google) sets the bar for who is allowed to send it, on Lenny's Podcast: "if you are an account executive in my org and I put you in front of 10 engineers at our company, it should take them 10 minutes to figure out you aren't a product manager."
5. **Say what happens below it**: deliberately nothing human. Write the do-not-contact line down, or outreach drifts to every signup and burns the free surface's reputation with the audience least tolerant of it.
6. **Route by role.** The signer is rarely the signup. Give the champion an enablement pack, the approver the risk answers unprompted, the buyer a cost comparison in their vocabulary.

The one-sentence form and the hours-not-days response window are this skill's own baselines, with no study behind them - [references/sourced-benchmarks.md](./references/sourced-benchmarks.md) § "Numbers this skill sets itself" lists them all; move any of them when your own data argues otherwise.

The signal families, a threshold template, routing and the champion pack contents are in [references/handoff-and-expansion-playbook.md](./references/handoff-and-expansion-playbook.md).

## Step 6 - Design expansion by vector, not by hope

Land-and-expand is a strategy only when the path is named. For the accounts you already have, identify which vector each one is on, then give it a trigger and an owner:

- more developers on the same team
- more teams in the same company
- more workload per user
- more product surface

Two things decide whether large accounts keep growing:

- reaching a **standardization decision**: a platform or architecture group makes the tool a default
- **multi-threading**: a second technical advocate plus one manager-level contact, this skill's own bar, set so a single champion leaving cannot stall the account

Anticipate procurement re-entry: the second, larger purchase can trigger the security review, legal pass and vendor onboarding the first credit-card purchase skipped.

## Step 7 - Write the GTM memo, validated section by section

Produce a decision the team can execute without you:

```markdown
# Developer-first GTM - <product>

## Constraints model and paid boundary, product friction, response capacity

## Friction gates entry / value / spread, with the evidence for each

## Rejected motions each one, and the constraint that ruled it out

## Primary motion money path, prerequisite, what must be built or hired

## Entry design first-value moment, steps removed, what stays open forever

## Handoff rule account rollup, signals, threshold sentence, who acts, who is never contacted

## Expansion path vector per account segment, trigger, owner, multi-threading rule

## Leading indicators the numbers that move before revenue, with targets and dates

## Refused what this motion will not do, so nobody re-proposes it monthly

## Revisit triggers the events that reopen the decision
```

Present each section and get agreement before writing the next. A wrong call on the motion propagates into every line below it, and it is far cheaper to catch at the fourth heading than at the tenth.

A full worked memo, with a weak and a strong version of the same sections, is in [references/gtm-plan-example.md](./references/gtm-plan-example.md).

## Individual developers versus company buyers

Both exist in every developer-facing product, and averaging them serves neither.

- **Individual adoption** (indie developers, hobbyists, small teams - the developer analogue of consumer buying): the user and the payer are the same person, or no purchase exists at all. Success shows up as usage before revenue, purchases are small, fast and card-based, and churn is easy. The motion is pure self-serve; a human in the loop costs more than the contract.
- **Company adoption**: the user is not the signer. Success shows up as evaluations that survive security, architecture and procurement review. The motion needs account rollup, a champion pack and paperwork.

- **Same for both:** first value must be reachable by one developer alone, and documentation, limits and pricing detail must stay open.
- **Differs after that:** who is contacted, what is offered, and what expansion even means, since everything after the first paid moment changes.

Rank the two paths explicitly rather than serving both. An entry designed for a hobbyist and an enterprise platform team at once serves neither.

## Measurement and the pass threshold

**Developer-focused companies show a median free-to-paid conversion of 5% - roughly half the median of non-developer-focused companies** (Lenny's Newsletter, _What is good free-to-paid conversion_, described as a survey of 1,000+ products). A devtool measured against a blended B2B benchmark will look broken while performing normally. Net revenue retention bands differ by motion the same way: a bottom-up product's 12-month "good" sits near 100%, not the enterprise 110% (_What is good retention?_). Quote them with the source; set your own targets from your own last quarter. See [references/sourced-benchmarks.md](./references/sourced-benchmarks.md) for the full sourced bands and measurement definitions.

Measure conversion the way the published bands are measured, or the comparison is meaningless: accounts that begin paying within their first six months, divided by accounts created in the window, by cohort, at account level. A lifetime ratio flatters any product whose signups grew.

Track a small indicator set, five or fewer (a self-set cap), all of which move before revenue:

- time from first touch to first value
- share of accounts reaching the depth signal
- share of qualified accounts contacted within the promised window
- free-to-paid conversion at _account_ level
- once there is a paid base: net revenue retention and the share of revenue from expansion

Label every number in the memo either sourced - with its source and its measurement definition - or self-set. A benchmark quoted without its definition and a self-set threshold dressed as an industry standard both survive review, then mislead every decision built on top. The two lists sit side by side in [references/sourced-benchmarks.md](./references/sourced-benchmarks.md).

Hold the plan to this threshold before the memo is final, and iterate until it passes:

- All three friction gates are answered with evidence, and any failing gate is reflected in the motion chosen.
- Exactly one primary motion, at most one secondary, and every rejected motion carries a stated blocking reason.
- The first-value moment is a concrete observable event, and the number of mandatory steps before it is counted.
- Usage can be rolled up to an account today, or the work to make that possible is scheduled.
- The qualification threshold is one sentence, uses numbers derived from your own data, and names the owner and the response time.
- The do-not-contact line is written down.
- Each expansion vector in play has a trigger and an owner.
- Every leading indicator is instrumented or schedulable within a quarter and carries a target with a date.
- Every number in the memo is labeled either sourced - with its source and its measurement definition - or self-set.

The framework definitions behind these numbers belong to `samber/developer-relations-skills@devrel-metrics`, and the instrumentation to `samber/developer-relations-skills@devrel-analytics`; this skill only picks the few that prove the motion works.

## Common failure modes

- **Assumed bottom-up.** The motion was chosen because it sounds cheap, and gate 1 was never tested. Symptom: high signups, no depth, no expansion.
- **Qualifying users instead of accounts.** Forty signups from one company look like forty leads and get forty emails.
- **Contacting on signup.** Teaches a developer audience that the free tier is bait.
- **Gated documentation, limits or pricing.** Developers evaluate before they will talk; a "book a demo" wall turns an evaluation into a silent exit.
- **A demo-only enterprise path with no self-serve floor.** Every small account becomes unservable, and the long tail leaves.
- **No route back to self-serve** for accounts sales decided not to pursue.
- **Enterprise tier sold into a one-developer account.** The land was never real; the renewal will say so.
- **Expansion treated as sales-only** when the vector is product-driven - spread and workload growth are product problems.
- **Counting provisioned seats instead of active ones.** Dormant seats predict contraction at renewal.
- **A pricing shape that punishes growth.** Developers quietly cap their own usage to avoid a scary bill, and the account flattens for reasons nobody reports.
- **Motion switching every quarter.** Each switch resets the learning; change on a written revisit trigger, not on a bad month.
- **Benchmarking against the wrong row.** A devtool held to a blended B2B conversion band, or a bottom-up product held to enterprise retention, concludes it is failing while performing normally.
- **Importing sales-led response-time folklore.** The "contact within 5 minutes" statistics come from inbound form fills, not developer product usage; imported here they mean contacting on signup.

## References

- [references/motion-archetypes.md](./references/motion-archetypes.md) - the four motions with prerequisites, what each forces you to build, leading indicator and failure mode, plus the friction-gate test in detail.
- [references/handoff-and-expansion-playbook.md](./references/handoff-and-expansion-playbook.md) - account rollup, signal families, threshold template, contact routing, champion enablement pack, expansion vectors and triggers.
- [references/gtm-plan-example.md](./references/gtm-plan-example.md) - a full worked memo, the same product's annotated failing memo, and weak versus strong versions of each section.
- [references/sourced-benchmarks.md](./references/sourced-benchmarks.md) - the published conversion and retention bands with their measurement definitions, the numbers this skill sets itself, and the ones nobody publishes.
- samber/developer-relations-skills@devrel-strategy for the program that supplies the motion's top of funnel.
- samber/developer-relations-skills@developer-ecosystem-strategy for the platform decision once the motion depends on third parties building on the product.
- samber/developer-platform-skills for cross-repo recommendations when the chosen motion depends on a platform surface, integration marketplace or registry presence.