samber/developer-relations-skillsチェック済み
SKILL DETAIL
developer-segmentation
samber/developer-relations-skills/developer-segmentation
Cuts a developer audience into a few named, sized and ranked segments - the two dimensions worth cutting on, a size range with a confidence tier, the user/champion/approver/buyer split inside each, a weighted score, one primary and one secondary segment, and a written anti-segment. Use whenever someone asks who their developers actually are, which developer audience to serve first, how big a language ecosystem or persona is, whether to target hobbyists or enterprise platform teams, who signs when the developer is not the buyer, or why content reaches everyone and converts nobody - even if they only say "who is this for". Not the journey map - use samber/developer-relations-skills@developer-journey-map.
インストール · 415出典を見る
Installation
npx skills add https://github.com/samber/developer-relations-skills --skill developer-segmentation
スキルファイル
SKILL.md
最終同期 · 2026/10/23
evals/evals.json›
{
"skill_name": "developer-segmentation",
"evals": [
{
"id": 1,
"prompt": "I run devrel at Harbinger Labs. We maintain an open-source CLI for database schema migrations - Apache 2.0, no paid tier, no hosted version, and the founders have said publicly there will never be one. We're at about 11k GitHub stars and 60k monthly installs. The team keeps arguing about whether we should be aiming at indie developers or at enterprise platform teams. Can you settle it and tell me who we should be focused on next quarter?",
"expected_output": "A brainstorming pass that refuses the either/or framing, presents two or three whole candidate cuts of the same audience, deletes the buying-mode cut outright because no purchase exists, ranks the survivors out loud on effort/value/efficiency, recommends one, and stops before writing any segment map.",
"files": [],
"expectations": [
"States it is in brainstorming mode and does not produce a finished segment map.",
"Presents two or three whole candidate cuts of the same audience, not variations of a single cut.",
"Explicitly removes the buying-mode cut from the candidate set because no purchase exists, rather than ranking it last.",
"Names that removal in writing rather than silently omitting the cut.",
"For each surviving candidate cut, lists the segments it produces, the artefact each segment would need, and who the cut makes unreachable.",
"For each surviving candidate cut, states what evidence must exist before anyone can be placed on one side of the line, and how much of that evidence the team already holds.",
"For each surviving candidate cut, states the condition under which that cut would be the wrong one.",
"Ranks the surviving candidates out loud on effort, value and efficiency rather than implying an order by list position.",
"Expresses effort as an order of magnitude of research work (hours, a week, a quarter) and never as a budget or currency figure.",
"Declines to answer \"indie developers or enterprise platform teams\" directly, on the grounds that the question presumes a cut nobody has chosen.",
"Recommends one candidate cut and leaves the decision to the person accountable before sizing anything."
]
},
{
"id": 2,
"prompt": "Quick one. I'm head of DX at Nimbus Relay - we sell a managed message-queue service, self-serve from $29/month up to enterprise contracts. Our roadmap for H1 locks in nine days and I need an audience decision before then so the SDK team knows what to build. Realistically I have maybe two afternoons to look at anything. What I do have: signup data with language and runtime on every row going back two years, and about 200 sales-call notes in the CRM. We've never run a user survey and we've never interviewed anyone about what they're actually building with it. Where should we land?",
"expected_output": "A candidate-cut pass that deletes the workload cut outright on the stated research ceiling and near date, keeps the ecosystem and buying-mode cuts because their evidence is already held, prices each at its real order of magnitude, and recommends exactly one.",
"files": [],
"expectations": [
"Deletes the workload cut from the candidate set and says so explicitly, on the grounds that the research ceiling is hours rather than weeks.",
"States that a near decision date deletes any cut whose evidence the team does not already hold.",
"Does not propose user interviews or support-ticket coding as a prerequisite for the recommended cut.",
"Keeps the ecosystem cut available because language and runtime already sit on every signup row.",
"Keeps the buying-mode cut available because the sales-call notes already record who signed.",
"States that the ruled-out cut is deleted rather than parked at the bottom of the list, and gives the reason a parked cut gets re-proposed later.",
"Names which supplied constraint moved which candidate cut.",
"Estimates the ecosystem cut's effort as roughly an hour, given that language and runtime are already collected.",
"Estimates the buying-mode cut's effort as roughly an hour or two of reading sales notes and existing accounts.",
"Recommends exactly one cut for this horizon.",
"Does not present the default candidate ordering as a fixed rule."
]
},
{
"id": 3,
"prompt": "Context: Sablefish is a Kubernetes operator for stateful workloads. It only runs on Kubernetes - there's no VM build, no serverless flavour, nothing else planned. Last year marketing paid for a 4,100-response user survey and the agency delivered a clustering analysis on top of it; the clusters are sitting in a spreadsheet nobody has opened since. We're redoing our audience picture for the next two years - this is meant to be something we re-read and update, not a one-off. Which way should we cut the audience?",
"expected_output": "A re-ranked candidate set: the workload cut promoted to first because the survey and clustering already exist, the ecosystem cut dropped to last as non-discriminating for a single-ecosystem product, with the moves attributed to the supplied context and the existing clusters reused rather than new labels invented.",
"files": [],
"expectations": [
"Promotes the workload cut to first place and names the existing survey and clustering dataset as the reason its effort collapses to near zero.",
"Drops the ecosystem cut to last and states that a product running only inside one ecosystem makes an ecosystem cut non-discriminating.",
"States that the default candidate ordering is a default rather than a law, and that it moves with what the team already holds.",
"Names which piece of supplied context moved which candidate cut.",
"Notes that a compounding, multi-horizon mandate favours the workload cut because it pays back over several horizons.",
"Does not recommend commissioning research the team already owns.",
"Recommends using the existing clusters rather than inventing segment labels first.",
"States the order in which attributes are selected, then clustered, and only then profiled and named.",
"Warns that a label invented first is usually a stereotype with no members behind it.",
"Recommends exactly one cut and leaves the final call to the accountable person before sizing.",
"Recommends storing the chosen dimensions, segment set, sizes and anti-segment so the next version can be diffed against this one."
]
},
{
"id": 4,
"prompt": "Board deck is Thursday. I need one number: how many developers are writing embedded firmware in Rust? I've got the RedMonk rankings open - Rust is sitting around 19th - and the last Octoverse report had something like 100 million accounts. Give me the figure and I'll drop it on the slide.",
"expected_output": "A sizing answer only: a range with method, date and confidence tier, a refusal to read a language ranking as a population or forge accounts as developers, a cross-check requirement against a different source class plus the company's own funnel, and a statement of what the number cannot support.",
"files": [],
"expectations": [
"Returns a range rather than a single point figure.",
"States the method used to assemble the range.",
"States a date alongside the figure.",
"Labels the figure with a confidence tier of measured, estimated or inferred.",
"Refuses to read the RedMonk rank as a population count or as a market share.",
"States that RedMonk's own publisher treats the tier as more meaningful than the individual rank.",
"Refuses to treat forge account counts as a count of professional developers, naming bots, duplicates or dormant accounts as inflation.",
"States what the number cannot support, not only what it can.",
"Requires a cross-check against a source of a different class, and states that two sources of the same class usually share an upstream dataset.",
"Recommends a bottom-up cross-check against the company's own funnel.",
"Does not produce a full segment map, segment scoring or a primary-segment recommendation."
]
},
{
"id": 5,
"prompt": "We've been going back and forth on this for a month so I'm just going to decide. Kettlewell is a CI runner product; we're Node-and-Python-first and always have been. Java is 1.9% of our signups and 2.3% of active workspaces. Someone keeps pushing to build a Maven plugin and a Java quickstart for 'the JVM enterprise segment'. 1.9% is 1.9% - that segment is tiny and I want to close this out. Back me up?",
"expected_output": "A refusal to size an unserved segment from first-party data, an external estimate shaped with range/method/date/confidence, and a cheap falsifiable test with its drop condition written before it runs.",
"files": [],
"expectations": [
"Refuses to accept the 1.9% signup share as evidence that the JVM segment is small.",
"States that first-party data is survivorship-shaped and describes only who already got through the funnel.",
"States that sizing an unserved segment from your own user base returns \"small\" by construction.",
"Proposes an external estimate of the JVM population built from a source outside the company's own funnel.",
"Requires that estimate to carry a range, a method, a date and a confidence tier.",
"Notes that the product being Node-and-Python-first is itself a plausible cause of the low Java share.",
"Proposes a cheap test that could settle the question in days rather than a quarter.",
"States the result that would make the team genuinely drop the segment, written before the test runs.",
"Does not endorse killing the segment on the strength of the funnel number alone.",
"Treats the segment as a hypothesis segment rather than a confirmed small one while its evidence sits below the floor."
]
},
{
"id": 6,
"prompt": "Sizing exercise for Loomstack - we make an evaluation harness for LLM applications. Here's what I pulled: 2.1 million models published on the big open model hub, 940,000 datasets, and our own package has 380,000 downloads a month on the language registry. I make that a very large addressable segment of ML engineers. Sanity-check my maths and give me the segment size.",
"expected_output": "A rejection of catalogue size and registry downloads as market size, with the download-concentration evidence quoted, a statement of what hub data legitimately supports, and a properly shaped range with method, date, confidence tier and a different-class cross-check.",
"files": [],
"expectations": [
"Refuses to treat the hub's catalogue size as a market size.",
"States that publishing on these hubs is free and unreviewed, so the counts measure publishing activity.",
"Cites the finding that the large majority of published models have fewer than a couple of hundred lifetime downloads.",
"Cites that a tiny fraction of repositories accounts for almost all downloads on such a hub.",
"States that \"millions of models exist\" and \"millions of models are used\" differ by roughly two orders of magnitude.",
"Refuses to treat package-registry downloads as human users, naming CI re-downloads as a dominant contributor.",
"States what hub and registry data can legitimately support: the shape of the practitioner niche, such as which tasks, formats or base models the segment works with.",
"Returns a range with a method, a date and a confidence tier rather than a single figure.",
"Requires a cross-check against a source of a different class.",
"Labels any figure with no data behind it as inferred and names the lookup that would upgrade it."
]
},
{
"id": 7,
"prompt": "I'm at Tarnhelm Insurance. We've published a claims API and a set of webhooks so brokers' engineering teams can integrate with us directly - it's one of about six channels we sell through, and the API isn't sold separately, it comes with the broker contract. Our devrel person keeps saying we need better quickstarts and a nicer sandbox. Meanwhile two integrations this year died somewhere after the technical proof of concept. I've got notes from four deals that closed and three that didn't. Who are we actually segmenting here?",
"expected_output": "A decision-unit pass: the company classified as developer-plus, evaluator/champion/approver/buyer named per segment, the post-POC deaths traced to an approver role, a segment split where the decision unit differs, and the questions aimed at the recorded wins and losses.",
"files": [],
"expectations": [
"Classifies the company as developer-plus rather than developer-first, and gives the reason.",
"Names, for each segment, who evaluates, who approves and who signs.",
"Identifies an approver role (architect, platform lead, security or legal reviewer) as the likely cause of integrations dying after the technical proof of concept.",
"States that one unanswered risk question is enough for an approver to say no.",
"Identifies champion material as the highest-leverage artefact in company adoption, because the champion argues when nobody from the vendor is in the room.",
"Splits a nominal segment into two when its decision unit differs, rather than recording the difference as a footnote.",
"Names a concrete trigger that adds an approver, such as a regulated vertical or a company-size threshold.",
"Directs its diagnostic questions at the recorded recent wins and recent losses rather than at an abstract org chart.",
"Asks which role blocked each loss and what would have unblocked them.",
"Warns that developer-delight material alone loses at the security or risk review.",
"Names which artefacts serve both adoption paths so they get built once."
]
},
{
"id": 8,
"prompt": "Byrnewood Analytics, embedded charting library. Paid SDK licence, $1,200 per seat per year, sold to product teams. But our single biggest audience by volume is university students and bootcamp people using the free educational licence - something like 40,000 of them against 900 paying seats. Marketing wants to make students a headline segment in the new audience plan because the numbers look great. Draft the segment rows.",
"expected_output": "Segment rows in which the free student audience must be justified against a named non-revenue driver or moved to the anti-segment, with raw volume rejected as a reason, and every row carrying a sized range, a decision unit and differentiated artefact/channel/proof.",
"files": [],
"expectations": [
"Requires the student segment to be justified against a named non-revenue driver before it can be funded.",
"Names the available non-revenue drivers explicitly: talent brand, contributor supply, future buyers, or ecosystem gravity.",
"States that without one of those written down, the segment belongs in the anti-segment.",
"Warns that an unjustified free audience quietly absorbs content and support capacity precisely because it is the easiest to reach.",
"Rejects raw volume on its own as a reason to make the segment a headline.",
"Notes that the future-buyers justification operates on a horizon measured in years rather than quarters.",
"Records the student segment's decision unit as \"no purchase exists\" rather than inventing a buyer for it.",
"Keeps the map to three to five segments.",
"Gives every segment row a size expressed as a range with a method, a date and a confidence tier.",
"Gives every segment row an artefact, a channel and a proof point that differ from at least one sibling row."
]
},
{
"id": 9,
"prompt": "Here's our segment scorecard for Vantablack Systems - we do hardware-in-the-loop test infrastructure, funded this year explicitly to help sales close bigger deals. I scored each segment out of 10 on size, reach, fit, value, effort, competition and compounding, then summed the seven. Independent hardware hobbyists came out top on 61/70 because they're huge, easy to reach and cost us nothing. Automotive tier-one suppliers came out bottom on 44/70, mostly because effort scored 3. So: hobbyists primary. Write it up.",
"expected_output": "A rebuilt ranking: coarse scale, criteria weighted against the sales-enablement driver before scoring, effort divided out rather than summed in, the division shown, the starved high-value/high-effort segment named with its promotion conditions, and a committed primary/secondary/anti shape.",
"files": [],
"expectations": [
"Rejects summing effort into the total, and states that effort is the denominator rather than another addend.",
"Rejects the 1-10 scale and replaces it with a 1-3 or high/medium/low scale.",
"Gives the reason for the coarse scale: false precision moves the argument onto the score instead of onto the segment.",
"Weights the criteria against the funded driver before scoring, not after.",
"Names sales enablement as the funded driver here and weights value and competitive position accordingly.",
"Notes that a segment carrying no revenue value is a defect under a sales-enablement driver even though it would be acceptable under an employer-brand driver.",
"Re-ranks by value per unit of effort and shows the division explicitly.",
"States which segment lost on the denominator rather than on merit.",
"Names what the efficiency ratio starves: the big, high-value, high-effort segment that loses every round it is ranked in.",
"Names the conditions that promote the starved segment anyway, including a sales-enablement driver with no cheaper segment carrying revenue.",
"Does not leave the hobbyist segment as primary without testing it against the funded driver.",
"Commits to exactly one primary segment, one secondary and one anti-segment."
]
},
{
"id": 10,
"prompt": "Final read before I send this to the exec team. Product is Quillfold, a headless CMS with an API-first pitch. We've landed on three segments: agency developers building client sites, in-house product teams at mid-market SaaS companies, and marketing-ops people who write a bit of code. Primary is in-house product teams. Secondary is agency developers - we've budgeted a dedicated agency partner portal, an agency-specific webinar series and a separate docs track for them. Plan for next quarter: ship the partner portal, publish the migration guides, do the four webinars, and keep the weekly newsletter going. Anything missing?",
"expected_output": "A gate check that fails the map on a missing anti-segment, a secondary funded with its own dedicated artefacts, implications with no stop, missing sizes and decision units, and no review date or early re-read triggers.",
"files": [],
"expectations": [
"Flags the absence of an anti-segment as a gate failure.",
"Requires the anti-segment to be non-empty and to include at least one audience the team wanted to keep.",
"Rejects the secondary segment having its own dedicated artefacts, and restates that a secondary is served only by artefacts the primary already funds.",
"Names the partner portal, the agency webinar series and the agency docs track as the dedicated spend that breaks that rule.",
"Requires the implications section to name something that stops, not only things that start.",
"Flags the absence of a review date.",
"Names concrete events that would force an early re-read, such as a pricing or packaging change, a new language or runtime target, a change in the funded driver, a competitor taking the primary segment's default position, or the primary segment hitting its goal.",
"Flags that every segment needs a size with a range, a method, a date and a confidence tier, none of which are present.",
"Flags that every segment needs a named decision unit, or an explicit statement that no purchase exists.",
"Checks that each segment is described in language its own members would recognise rather than in internal category names.",
"Reports the gate check explicitly rather than implying the map passed."
]
},
{
"id": 11,
"prompt": "We want to fund a whole new SDK next quarter for what we're calling 'air-gapped defence integrators' - Ravenhollow Data, we do log pipeline tooling. Honest state of the evidence: one lost deal where the guy mentioned it, and one conversation at a conference booth. Everyone on the team is convinced it's real and the SDK is about four engineer-months. Put it in the plan as a funded segment.",
"expected_output": "The segment kept in the map but labelled a hypothesis and left unfunded until it clears the evidence floor, with a days-long falsifiable test, its drop condition written in advance, and the funding request refused on the current two data points.",
"files": [],
"expectations": [
"Labels the air-gapped defence integrators segment a hypothesis segment.",
"States the evidence floor as roughly 5-10 independent data points from a consistent group.",
"States that the floor is a customer-research practice convention rather than a measured threshold.",
"Keeps the segment in the map rather than deleting it.",
"Leaves the segment unfunded until it clears the floor.",
"Refuses to commit the four engineer-months of SDK work on the current evidence.",
"Names a specific cheap test that costs days rather than a quarter.",
"States the result that would make the team drop the segment, written before the test runs.",
"Requires at least half the funded segments in the map to clear the evidence floor.",
"Does not present the two data points as measured evidence.",
"Names which lookup or source would upgrade the segment's size from inferred."
]
},
{
"id": 12,
"prompt": "Inherited this from the person who had my job before me. Company is Windrose Telemetry. Our audience doc has three personas: 'Junior Jamie', a bootcamp grad in their first year who loves learning; 'Mid-level Morgan', three to six years in, pragmatic, time-poor; and 'Staff-level Sam', ten years in, opinionated, hates marketing. Each has a page of day-in-the-life narrative. Size is listed as 'Large', '~4 million' and 'Growing'. Next steps at the bottom say: more content for Morgan, plus a beginner tutorial series. Tidy this up for me and make it presentable.",
"expected_output": "A rejection of the seniority cut rather than a tidy-up, with the two conditions under which seniority earns a place, the prose-portrait format refused, the unsourced sizes refused, the contradiction between ranking and next steps flagged, and a replacement two-dimension cut proposed.",
"files": [],
"expectations": [
"Rejects seniority as the axis of the cut rather than tidying the existing personas.",
"States that a junior and a staff engineer on the same stack and workload usually need the same SDK, docs and samples.",
"Names the only two conditions under which seniority earns a place: when it maps onto authority, or onto learning need.",
"Records seniority as a descriptive field inside a segment when it does not clear those conditions.",
"Rejects the day-in-the-life narrative format, stating that a prose portrait reads well and decides nothing.",
"States that a persona averaged across segments represents nobody.",
"Rejects \"Large\", \"~4 million\" and \"Growing\" as sizes carrying no source, date, method or confidence tier.",
"Flags that the \"~4 million\" figure is most likely a language ranking or an account count read as a population.",
"Flags that the next steps contradict the ranking, because a beginner tutorial series serves the segment the doc deprioritised.",
"States that two segments receiving identical artefacts are one segment with a demographic footnote, and that the dimension was therefore wrong.",
"Proposes a replacement cut with exactly two dimensions, one that changes what gets built and one that changes how they are reached."
]
},
{
"id": 13,
"prompt": "Dredgewater Compute. We did a developer segment map last September - I've still got the doc, it named mid-size gaming studios primary, indie game developers secondary, and put VFX and animation houses in the anti-segment because we couldn't do the colour-pipeline work. Twelve months on, someone wants me to redo the whole exercise from scratch. We shipped two things for gaming studios and one general 'for developers' performance guide. Studio share of new signups went from 18% to 31%. What should I actually do here?",
"expected_output": "A re-read of the stored map returning a diff rather than a rebuild: what moved, which predictions held, which segments to retire, the concentration and artefact-fit readings on the shipped work, and a new review date with early re-read triggers.",
"files": [],
"expectations": [
"Runs a re-read against the stored map rather than rebuilding it from a blank page.",
"Returns a diff: what moved, which predictions held, and which segments to retire.",
"Reads the studio signup share moving from 18% to 31% as the concentration measure improving.",
"Counts the general \"for developers\" performance guide as an artefact-fit miss, because it was not built for a named segment.",
"Checks prediction accuracy by asking which sized segments actually behaved as the map predicted.",
"States that a wrong prediction should correct the sizing method rather than the conclusion.",
"Includes argument frequency - how often the team reopens the audience question - as a measure of whether the map worked.",
"Re-checks whether the anti-segment's stated reason still holds before retiring or keeping that exclusion.",
"Names the events that would force an early re-read before the next scheduled review.",
"Sets a new review date on the updated map."
]
}
],
"trigger_queries": [
{ "query": "Who should we target with our API?", "should_trigger": true },
{ "query": "we need to figure out who our developers actually are", "should_trigger": true },
{ "query": "should we go after enterprise platform teams or indie hackers first?", "should_trigger": true },
{ "query": "how big is the Rust embedded community?", "should_trigger": true },
{ "query": "how many Go developers are there really?", "should_trigger": true },
{ "query": "our content reaches everyone and converts nobody", "should_trigger": true },
{ "query": "who actually signs off on buying us?", "should_trigger": true },
{ "query": "the developer evaluates but someone else pays - how do we handle that in our audience plan?", "should_trigger": true },
{ "query": "build me a segment map for our SDK", "should_trigger": true },
{ "query": "re-run our developer segment map, it's from last year", "should_trigger": true },
{ "query": "which developer audience should we serve first next quarter?", "should_trigger": true },
{ "query": "I need to know who this product is for", "should_trigger": true },
{ "query": "who is this for?", "should_trigger": true },
{ "query": "we keep arguing about whether students count as an audience", "should_trigger": true },
{ "query": "should we prioritise hobbyists or paid professional developers?", "should_trigger": true },
{ "query": "how do we split our developer audience into something the team can act on?", "should_trigger": true },
{ "query": "our audience doc just says 'developers' and it's useless", "should_trigger": true },
{ "query": "what dimensions should we cut our developer audience on?", "should_trigger": true },
{ "query": "is language ecosystem or workload the better way to slice our users?", "should_trigger": true },
{ "query": "we have three personas and none of them change what we build", "should_trigger": true },
{ "query": "help me size the platform engineering segment", "should_trigger": true },
{ "query": "how many people are actually running Kubernetes operators in production?", "should_trigger": true },
{ "query": "who should we NOT serve this year?", "should_trigger": true },
{ "query": "we need an anti-segment, everything is theoretically in scope right now", "should_trigger": true },
{ "query": "rank our candidate audiences and pick one", "should_trigger": true },
{ "query": "which of these four developer groups deserves the SDK budget?", "should_trigger": true },
{ "query": "our free tier audience is huge but pays nothing - is that a segment?", "should_trigger": true },
{ "query": "how do we decide between targeting Java shops and Python shops?", "should_trigger": true },
{ "query": "the team can't agree who the product is for and the roadmap locks Friday", "should_trigger": true },
{ "query": "map out who buys us versus who uses us", "should_trigger": true },
{ "query": "what's the ICP for a developer tool like ours?", "should_trigger": true },
{ "query": "define our developer ICP", "should_trigger": true },
{ "query": "we're a Postgres extension - who's our audience?", "should_trigger": true },
{ "query": "put together an audience plan for our open source project", "should_trigger": true },
{ "query": "how should we group our users so the docs team knows who they're writing for?", "should_trigger": true },
{ "query": "I want to understand which developers are worth chasing", "should_trigger": true },
{ "query": "we sell to developers but I've never written down who", "should_trigger": true },
{ "query": "give me three to five groups of developers we can actually serve", "should_trigger": true },
{ "query": "which segment should get the new SDK?", "should_trigger": true },
{ "query": "should seniority be one of our audience dimensions?", "should_trigger": true },
{ "query": "does it make sense to split our developers by years of experience?", "should_trigger": true },
{ "query": "how do I size a developer segment without running a survey?", "should_trigger": true },
{ "query": "can I use our signup data to size a market we don't serve yet?", "should_trigger": true },
{ "query": "we pulled the number off a language popularity ranking - is that ok for the board deck?", "should_trigger": true },
{ "query": "how many ML engineers are there? we're basing it on model hub counts", "should_trigger": true },
{ "query": "our integrations keep dying after the technical POC - who are we missing?", "should_trigger": true },
{ "query": "who has to say yes before a developer can adopt us?", "should_trigger": true },
{ "query": "we have no idea who the approver is in these deals", "should_trigger": true },
{ "query": "why do we win the developer and lose the deal?", "should_trigger": true },
{ "query": "help me decide who our primary and secondary audiences are", "should_trigger": true },
{ "query": "we need one audience decision for H2 and I want it written down", "should_trigger": true },
{ "query": "put a confidence level on these audience size estimates", "should_trigger": true },
{ "query": "our audience numbers have no source and someone's going to ask", "should_trigger": true },
{ "query": "which developer groups are we only pretending to serve?", "should_trigger": true },
{ "query": "we serve six different kinds of user and do a bad job for all of them", "should_trigger": true },
{ "query": "narrow our focus down to one group of developers", "should_trigger": true },
{ "query": "is 'enterprise developers' a segment or just a word?", "should_trigger": true },
{ "query": "how do we know if an audience group is real or wishful thinking?", "should_trigger": true },
{ "query": "what evidence do we need before funding a new audience?", "should_trigger": true },
{ "query": "should we build a Maven plugin for a group that's 2% of signups?", "should_trigger": true },
{ "query": "our devrel keeps making content for everyone, help me point it somewhere", "should_trigger": true },
{ "query": "who are the people who'd actually succeed with this product?", "should_trigger": true },
{ "query": "map the developer journey from discovery to production for our platform team segment", "should_trigger": false },
{ "query": "where do developers drop off between signup and first successful API call?", "should_trigger": false },
{ "query": "should we go bottom-up self-serve or hire an enterprise sales team?", "should_trigger": false },
{ "query": "when should we contact a free user about upgrading?", "should_trigger": false },
{ "query": "signups are high but nobody converts to paid - fix our revenue motion", "should_trigger": false },
{ "query": "we're starting a devrel program from scratch, what should it do first?", "should_trigger": false },
{ "query": "how do I justify the devrel budget to our CFO?", "should_trigger": false },
{ "query": "which devrel pillars should we invest in at our stage?", "should_trigger": false },
{ "query": "should we open extension points so partners can build integrations?", "should_trigger": false },
{ "query": "nobody is building on our API - how do we start an integration ecosystem?", "should_trigger": false },
{ "query": "benchmark our developer experience against our closest competitor's", "should_trigger": false },
{ "query": "how does our documentation quality compare to the market leader's?", "should_trigger": false },
{ "query": "what error messages do developers search for when our SDK fails?", "should_trigger": false },
{ "query": "build me a keyword list for our API documentation site", "should_trigger": false },
{ "query": "what should we charge for our developer tool?", "should_trigger": false },
{ "query": "should we bill per seat or per usage?", "should_trigger": false },
{ "query": "where should our free tier end and paid begin?", "should_trigger": false },
{ "query": "which devrel metrics should go in the quarterly board report?", "should_trigger": false },
{ "query": "how do we prove devrel ROI to leadership?", "should_trigger": false },
{ "query": "design an ambassador program for our top community members", "should_trigger": false },
{ "query": "what perks should our community champions get?", "should_trigger": false },
{ "query": "should we build a certification program for our product?", "should_trigger": false },
{ "query": "plan a learning path for developers new to our platform", "should_trigger": false },
{ "query": "write a case study about how a customer adopted our SDK", "should_trigger": false },
{ "query": "how do we make our engineering brand attractive to candidates?", "should_trigger": false },
{ "query": "plan our developer content calendar for Q3", "should_trigger": false },
{ "query": "is our Discord community healthy?", "should_trigger": false },
{ "query": "how do we moderate our community when threads get heated?", "should_trigger": false },
{ "query": "restructure our documentation information architecture", "should_trigger": false },
{ "query": "write a quickstart that gets someone to first call in ten minutes", "should_trigger": false },
{ "query": "optimize our README for the GitHub landing page", "should_trigger": false },
{ "query": "plan the launch of our open source project", "should_trigger": false },
{ "query": "which conference should we sponsor this year?", "should_trigger": false },
{ "query": "help me write a CFP submission for a cloud-native conference", "should_trigger": false },
{ "query": "turn these commits into release notes", "should_trigger": false },
{ "query": "write a migration guide for our v3 breaking changes", "should_trigger": false },
{ "query": "should we relicense from a source-available licence to Apache 2.0?", "should_trigger": false },
{ "query": "set up a governance model for our open source project", "should_trigger": false },
{ "query": "how do we triage our issue backlog?", "should_trigger": false },
{ "query": "onboard new contributors to our repo", "should_trigger": false },
{ "query": "how should we structure our devrel team and who reports to whom?", "should_trigger": false },
{ "query": "write a job description for a developer advocate", "should_trigger": false },
{ "query": "how do I get promoted from developer advocate to head of devrel?", "should_trigger": false },
{ "query": "how do we distribute our CLI - package manager, installer script, or both?", "should_trigger": false },
{ "query": "should our open source project become a business or stay a side project?", "should_trigger": false },
{ "query": "outline a conference talk about our tracing architecture", "should_trigger": false },
{ "query": "prep me for a podcast interview about our database", "should_trigger": false },
{ "query": "get our docs pages ranking for 'how to connect postgres'", "should_trigger": false },
{ "query": "design a live demo that won't break on stage", "should_trigger": false },
{ "query": "start a meetup program in three cities", "should_trigger": false },
{ "query": "segment our VLANs so the IoT devices can't reach the NAS", "should_trigger": false },
{ "query": "set up network segmentation between our prod and staging VPCs", "should_trigger": false },
{ "query": "build an audience segment in our customer data platform for churn-risk accounts", "should_trigger": false },
{ "query": "write the SQL to segment our email list by last purchase date", "should_trigger": false },
{ "query": "run an RFM segmentation on our ecommerce customers", "should_trigger": false },
{ "query": "create user personas for our mobile banking app's UX research", "should_trigger": false },
{ "query": "segment our B2C subscribers by lifetime value for a retention campaign", "should_trigger": false },
{ "query": "how should we partition this table - by tenant id or by date?", "should_trigger": false },
{ "query": "explain memory segmentation versus paging on x86", "should_trigger": false },
{ "query": "run a market segmentation study for our consumer fitness app", "should_trigger": false },
{ "query": "analyze the follower audience of this social media account", "should_trigger": false },
{ "query": "split our sales territory by region and account headcount", "should_trigger": false }
]
}
references/decision-unit.md›
# The decision unit inside a developer segment
Contents: the four roles · individual vs company adoption · segments with no purchase · splitting on the decision unit · questions that reveal the unit.
## The four roles
| Role | Cares about | Convinced by | Says no because |
| ---------------------------------------------------- | --------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- |
| User / evaluator (usually the developer) | time to first success, ergonomics, escape hatches, whether it fights the existing stack | working code, honest docs, a benchmark they can re-run, peer proof | it did not work in twenty minutes, or the docs lied once |
| Technical champion | making the internal case without spending credibility | migration path, reference architecture, a comparison they can paste into an internal doc, named production users | they cannot answer their architect's questions from your material |
| Approver (architect, platform lead, security, legal) | risk, stack fit, licensing, support, exit path | compliance answers, SLA and support terms, licence clarity, data-handling detail, self-host or portability story | one unanswered risk question, which is enough |
| Economic buyer | total cost, alternatives, contract terms, timing | a business case in their vocabulary, procurement-ready paperwork, a trigger that makes this quarter the quarter | no budget line, or no urgency |
The champion's material is the highest-leverage artefact in company adoption: they argue when nobody from your side is in the room, and they lose on questions you could have answered in a document.
## Individual vs company adoption
| | Individual adoption | Company adoption |
| ---------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| Who decides | the developer, or nobody (no purchase) | a developer evaluates; an architect, platform lead, security reviewer or budget owner decides |
| Segment on | motivation, ecosystem, workload | firmographics plus which decision roles exist |
| Artefacts that move it | quickstart, samples, free tier, peer proof, ecosystem presence | reference architectures, security and licensing clarity, migration and support paths, named references |
| Success looks like | usage before revenue | evaluations that survive review |
| Common trap | assuming a purchase exists and writing enterprise material nobody reads | writing developer-delight material and losing at the security review |
Most products carry both paths. Rank them for the horizon; splitting effort evenly serves neither. State which artefacts serve both so they get built once - a clear licence page, honest limits documentation and a credible production-readiness story serve every role in both paths.
## Segments with no purchase
Students, hobbyists, OSS maintainers and internal-tool builders may never generate revenue. That is a legitimate segment only when it is justified against a named non-revenue driver:
- **talent brand** - the segment contains people you want to hire, or who influence hires;
- **contributor supply** - they fix, extend and maintain what you ship;
- **future buyers** - today's hobbyist is the person who picks the stack at their next job, on a horizon measured in years, not quarters;
- **ecosystem gravity** - their integrations and content make the product the default for someone else.
Without one of these written down, the segment belongs in the anti-segment. Unjustified free audiences absorb content and support capacity precisely because they are the easiest to reach.
## Splitting on the decision unit
Two nominal members of one segment with different decision units are two segments. Common triggers:
- a regulated vertical adds a compliance approver that an unregulated one does not have;
- above a company-size threshold, procurement and vendor review appear;
- self-hosted deployments add an infrastructure owner who never touches the API;
- in an agency or consultancy, the person adopting is not the person who lives with the consequences.
## Questions that reveal the unit
Ask these of recent wins and recent losses, not in the abstract:
1. Who first tried it, and how did they hear about it?
2. Who else had to say yes, and what did they ask for?
3. Which question stalled the deal or the rollout longest?
4. Who signed, and what did they need to see?
5. In the losses, which role blocked it, and what would have unblocked them?
Five recent deals answered this way beat any assumed org chart.
references/published-findings.md›
# Published findings and self-set baselines
Contents: sourced claims · this skill's own baselines · how to re-verify.
Read this before quoting any number from this skill to a stakeholder. A segment map loses its argument the moment a self-set convention is presented as an industry standard.
## Sourced claims
| Claim used in the skill | Source | What it can support | What it cannot support |
| ------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Independent developer-population estimates per language, sector and role exist and are survey-modelled | SlashData / Developer Nation waves - 30,000+ developers, 165+ countries, twelve development sectors; language-community and sector sizing reports ("Sizing programming language communities", published 1 May 2025; a 19.9 million cloud-native developer estimate, 39% of the global developer population, from the CNCF/SlashData joint "State of Cloud Native Development" report for Q1 2026, up from 15.6 million in the Q3 2025 edition of the same series) | order-of-magnitude population per ecosystem or sector | a precise count, or any count for a niche the survey never sampled |
| A large audience builds software without writing code | SlashData, June 2026: "at least 16 million people are building software without knowing how to code" | treating no-code/low-code builders as a candidate involvement segment | that they are reachable through developer channels |
| Practitioner role mix and the professional/learner split | Stack Overflow Developer Survey 2025 - 49,000+ responses, 177 countries; role mix roughly full-stack 27%, back-end 14.2%, students 11.3%, architects 6.1%, desktop/enterprise 4.3% | proportions inside a self-selected respondent pool, and direction of change between waves | absolute population; the sample skews to English-speaking, survey-answering developers |
| Language rankings are activity proxies, not counts | RedMonk rankings - public GitHub pull requests × Stack Overflow activity; the publisher states the tier matters more than the rank and that Stack Overflow's decline distorts the discussion axis | relative tiers and direction of travel between languages | population, market share, or a one-rank difference |
| Forge platform counts inflate developer headcounts | GitHub Octoverse - accounts, repositories, pull requests | platform-level growth and language activity trends | one account equals one professional developer |
| A segment is only usable if it is measurable, accessible, substantial, differentiable and actionable | Kotler and Armstrong, _Principles of Marketing_ - the segmentation chapter's five requirements for a usable segment, corroborated independently by OpenStax's openly licensed _Principles of Marketing_ textbook, which teaches the same five factors under the mnemonic ADAMS | the validity test applied to a proposed cut in step 1 | a developer-specific standard - the criteria are general marketing practice, not developer research |
| Segments should be clustered from attributes, then labelled | SlashData customer-segmentation method, slashdata.co - six steps: understand the audience and persona use → define attributes → collect data → "advanced clustering analysis helps us obtain a set of distinct segments" → behavioural profiling → persona delivery | the emerge-then-label rule and the attribute-selection-follows-downstream-use rule in step 2 | that clustering needs a paid survey; the same order works on tickets and sales notes |
| References only count inside a segment | Geoffrey Moore, _Crossing the Chasm_ - pragmatic buyers want proof from peers in their own segment; "500 companies use us" carries less weight than a named count inside the segment | the compounding criterion, and the argument for concentrating proof rather than spreading it | a full beachhead/bowling-alley program - that is go-to-market apparatus, not segmentation |
| Beachhead selection criteria map onto four of the seven scoring criteria | Moore's beachhead test: burning pain, willingness to pay, winnable share, referral potential | cross-checking that a primary-segment choice is not missing an obvious dimension | a fifth criterion this skill does not already carry |
| What an evaluating developer actually weighs in a tool decision | Larios Vargas et al., ESEC/FSE 2020 (DOI 10.1145/3368089.3409711), 16 interviews + 115 survey responses: stability 62%, usability 55%, documentation 51%, licence 45%, active maintenance 44%, security 39% rated "highly influential" | the fit criterion, and what a segment's evaluation material must answer | ranking your own segment's priorities - the authors call the low security score "surprising", and one interviewee says "Checking security vulnerabilities is important, but I do not check it up-front" |
| Whether the developer audience contains the buyer is a company-shape question | Wikipedia, "Developer relations" - "Developer-First" companies run a "business-to-developer model (B2D)"; "Developer-Plus" companies make products available to developers as one channel among several | naming which of the two adoption paths dominates before segmenting | operational mechanics on either side |
| The funded driver changes which segment wins | Matthew Revell, "The four pillars of developer relations", developerrelations.com, published 2018, updated 2025-02-12 - seven funding drivers, one of which is "sales enablement: developers evaluate, someone else buys" | weighting the scoring criteria before scoring, and the decision-unit split | a target weight per driver |
| A cut must answer what type of developer will succeed with the product, not just who uses it | Caroline Lewko, DevRel.Agency co-founder and co-author of _Developer Relations: How to Build and Grow a Successful Developer Program_, "You're Targeting Developers? So Is Everyone Else. Here's How to Do Segmentation Better", Heavybit, 22 March 2022 - "Segmentation is about focus and alignment" | a named practitioner voice for why a cut has to change what gets built, in step 1 | a developer-specific segmentation framework - her own four filters (technical, user, organization, market) are not the dimensions this skill adopts |
## This skill's own baselines
Defensible starting points, internally consistent with the rest of this collection. Present them as adjustable, never as standards.
Population figures stop where the published sources stop: language, sector or platform level. A number for anything narrower is your own arithmetic, and the map has to say so.
| Baseline | Value | Why this number |
| ---------------------------------------- | ------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Dimensions per cut | exactly two | a two-axis grid stays legible in a meeting; a third multiplies cells past what a team can staff |
| Segments per map | three to five | two usually means the audience was not cut; six means none gets served |
| Funded ranking shape | one primary, one secondary, one written anti-segment | the anti-segment is the only part that actually stops work |
| Evidence floor | 5-10 independent data points from a consistent group | a customer-research convention - treat it as a practice norm, not a measured floor |
| Share of funded segments above the floor | at least half | arbitrary; it exists to stop a whole map being hypotheses |
| Scoring scale | 1-3 or high/medium/low | coarse scales move the argument off the score and onto the segment |
| Map length | two pages | a map nobody re-reads decides nothing |
| Review horizon | one quarter, plus named early-re-read triggers | matches the planning cadence most of this collection assumes |
| Candidate-cut ordering | ecosystem cut, then buying-mode, then workload, on efficiency | reasoned from the research each cut needs before anyone can be placed on one side of the line, and meant to be re-ranked against the data a team already holds |
| Segment ranking arithmetic | value divided by effort, not summed with it | a summed score lets a segment win on breadth while its prerequisite artefact list is longer than the horizon |
## How to re-verify
1. Re-fetch the survey waves before quoting a figure - SlashData and Stack Overflow publish annually, and a two-wave-old number invites the wrong objection.
2. Re-read RedMonk's own caveat paragraph in the current run before quoting a tier.
3. State the checked date next to every external figure inside the map itself, not only here.
4. Replace any sourced row above with a first-party measurement as soon as one exists; measured beats estimated at every review.
references/segment-dimensions.md›
# Segmentation dimensions and scoring criteria
Contents: the six dimension families · the test a dimension must pass · seniority · combining dimensions · the seven scoring criteria.
## The six dimension families
| Family | Developer-specific values | Changes | Use it when |
| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
| Involvement and motivation | paid professional, hobbyist, student or career-changer, researcher, OSS maintainer, non-coder building software with generative tools | credibility codes, price sensitivity, whether a purchase exists at all | free and paid audiences behave differently, or a large unpaid audience exists |
| Technographic | primary language and runtime, framework, package manager, cloud or on-prem, adjacent tools already installed, self-hosted vs managed | which SDK, samples and docs track get built; which communities are reachable | the product must be present _in_ an ecosystem to be used |
| Sector and workload | web, mobile, desktop, cloud and platform, embedded and industrial IoT, consumer electronics, AR/VR, games, ML/AI, data science, extensions built on someone else's platform | the reference architecture, the integration list, the event calendar | the same product solves different problems per workload |
| Firmographic | company size, industry vertical, regulatory regime, region, in-house vs agency vs consultancy | whether compliance material blocks adoption, whether sales is involved | company adoption exists at all |
| Behavioural | hosting model, scale threshold crossed, build-vs-buy posture, migration in progress, existing incumbent tool | urgency, switching trigger, the proof that lands | usage data or sales notes show consistent behavioural clusters |
| Role in the decision | user, technical champion, approving architect, security or legal reviewer, economic buyer | who the evaluation material is written for | anyone other than the user can veto or sign |
## The test a dimension must pass
Ask, for two members on opposite sides of the line: _would we build something different, publish somewhere different, or prove something different?_
- Two yeses make it a dimension worth cutting on.
- One yes makes it a field inside a segment.
- Zero makes it trivia.
Second test - reachability: can you name a venue, list, registry, event or search intent where one side congregates and the other does not? A dimension you cannot address is a research finding, not a segmentation axis.
Both tests are the developer-specific form of the classic segment-validity criteria, which are worth running as a checklist when a cut feels arguable:
| Criterion | Question for a developer cut | Typical failure |
| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- |
| Measurable | can you tell which side a given developer is on, and roughly how many sit on the smaller side, from data you already hold or can ask for in one question | "innovative teams" - no observable marker, no headcount |
| Substantial | is the smaller side big enough to justify its own artefacts | a segment of nine companies |
| Accessible | is there a channel that reaches one side and not the other | a real trait with no venue attached |
| Differentiable | would the two sides actually react differently to the same offer | both sides want the same quickstart |
| Actionable | does the cut change a decision you are about to make | interesting, but nothing downstream consumes it |
These criteria come from general market-segmentation practice - Kotler and Armstrong's textbook formulation, not from developer research - use them as a checklist, never cite them as a developer-audience standard.
## Seniority
Seniority is the most tempting and least useful cut. A junior and a staff engineer running the same stack on the same workload usually need the same SDK, the same docs and the same samples. It earns a place only when it maps onto something else:
- **Authority** - the person who can standardise a tool across an org is a different segment from the person who can only use it on one service.
- **Learning need** - a product used mainly by newcomers to a domain needs a teaching track a specialist would find insulting.
Otherwise record seniority as a descriptive field.
## Combining dimensions
Use exactly two. One "what we build" dimension and one "how we reach them" dimension produce a grid with three to five populated cells; most grids have empty cells, and empty cells are a useful finding.
A third dimension multiplies the cells past what a team can staff. If a third genuinely matters, it is usually a signal that two products, not one segmentation, are hiding in the audience.
Segments should emerge from observed behaviour and then be named, rather than being named first and populated afterwards. Where a survey or usage dataset exists, clustering on selected attributes produces segments nobody predicted; where it does not, cluster manually on support tickets, sales notes and community threads before writing any label.
## The seven scoring criteria
Score coarsely - 1-3, or high/medium/low. Weight against the funded driver before scoring. Effort is the denominator, never another addend: the skill's step 5 ranks segments by value per unit of effort, so a high effort score pushes a segment down rather than lifting its total.
| Criterion | Question | Fails when |
| -------------------- | ------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- |
| Size | how many, with what confidence | the only evidence is an unattributed round number |
| Reachability | is there a venue this segment already gathers in, at a cost you can pay | large but with no list, no ecosystem hub, no event, no search intent |
| Fit | does the segment already name this problem in its own words | the pain is assumed rather than quoted |
| Value | what a converted member is worth - revenue, contribution, reference, talent signal | the value is stated in a currency the funder does not use |
| Effort | what must exist before this segment can succeed: SDK, docs track, compliance pack, integration | the prerequisite list is longer than the horizon |
| Competitive position | does an incumbent own the default choice here, and what would trigger a switch | "we are better", with no switching trigger |
| Compounding | does winning this segment make the next one cheaper - references, contributed integrations, ecosystem gravity | winning it leads nowhere |
Weighting examples:
- a program funded for sales enablement weights value and competitive position;
- one funded for contributor community weights reachability and compounding;
- one funded for employer brand weights reachability and fit, and may score revenue value at zero without penalty.
references/segment-map-example.md›
# Worked segment map
Contents: the worked map · weak vs strong versions of each section · a rejected map · a second cut of the same audience.
The product below is illustrative: an open-source tracing library with a paid hosted backend, self-serve pricing, and a small enterprise motion. Figures are placeholders in the correct shape - replace them with your own sourced numbers.
## Table of Contents
- [The map](#the-map)
- [Cut](#cut)
- [Segments](#segments)
- [Primary](#primary)
- [Secondary](#secondary)
- [Anti-segment](#anti-segment)
- [Hypotheses](#hypotheses)
- [Implications](#implications)
- [Review](#review)
- [Weak vs strong](#weak-vs-strong)
- [A rejected map](#a-rejected-map)
- [Segments](#segments)
- [Primary](#primary)
- [Next steps](#next-steps)
- [The same audience, cut differently](#the-same-audience-cut-differently)
## The map
```
# Developer segment map - <product>, H2 <year>
## Cut
Dimensions: workload (what they instrument) × deployment mode (self-hosted vs hosted).
Rejected: seniority - a junior and a staff engineer instrumenting the same service need
the same SDK and the same docs. Rejected: region - support and pricing are identical
everywhere we sell, and no artefact would change.
## Segments
| Segment | Definition | Size + confidence | Decision unit | Needs | Where they gather | Evidence |
|---|---|---|---|---|---|---|
| Solo service owners | 1-3 engineers running a handful of services, hosted everything | ~150k–300k, estimated (language-community sizing filtered to companies <20 engineers, cross-checked against 61% of signups) | user = buyer, card payment | 10-minute quickstart, free tier that survives a real service, one-file config | language-ecosystem forums, package registry, two framework Discords | 340 signups, 22 support threads, 6 interviews - measured |
| Platform teams | 4-15 engineers owning shared infrastructure for 50+ developers | ~40k–80k, estimated (job-posting counts for platform/SRE roles at 200+ engineer companies) | user evaluates, platform lead approves, VP Eng signs | multi-tenant story, cost-control docs, migration from incumbent, self-host option | infra-focused conferences, CNCF-adjacent Slack, incident-management communities | 14 sales-call notes, 9 tickets - measured |
| Regulated platform teams | platform teams under data-residency or audit obligations | ~8k–15k, inferred (share of the above in finance/health verticals) | adds security reviewer and legal | data-residency answers, audit log export, signed DPA, self-host parity | vertical conferences, compliance-focused peer groups | 3 lost deals, all on residency - hypothesis |
| OSS instrumentation authors | maintainers writing exporters and integrations for other libraries | ~2k–5k, inferred | no purchase | stable plugin API, contribution guide, release predictability | the project's own issue tracker, ecosystem working groups | 31 external contributors - measured |
## Primary
Platform teams. Score (driver = revenue): size 2, reachability 3, fit 3, value 3,
effort 2, competitive position 2, compounding 3. Beat solo service owners, which is
larger and cheaper to reach but converts at a twentieth of the value and already
succeeds without help.
## Secondary
Solo service owners - served by artefacts platform teams already fund (quickstart,
SDK quality, free tier). No dedicated content, no dedicated events this horizon.
## Anti-segment
Regulated platform teams. Reachable and valuable, but the artefact list - residency,
audit export, self-host parity - is three quarters of engineering work we have not
funded. Revisit when the self-host build lands. Saying this in writing stops each
lost deal reopening the debate.
## Hypotheses
Regulated platform teams: 3 data points, below the floor. Test: read the three lost
deals end to end and interview two of the blocking reviewers. Drop the segment if
residency turns out to be a proxy for price.
## Implications
Build: multi-tenant reference architecture, cost-control guide, migration guide from
the incumbent. Publish: infra conferences and one incident-management community.
Prove: two named platform-team references with numbers.
Stop: beginner tutorial series (serves the secondary segment we already win).
## Review
Re-read <date, one quarter out>. Early re-read if: self-host ships, pricing changes,
the incumbent adds a free tier, or platform-team share of new signups passes 35%.
```
## Weak vs strong
**Segment definition**
- Weak: "Enterprise developers." Who? Doing what? Nothing follows from it.
- Strong: "4-15 engineers owning shared infrastructure for 50+ developers." A support engineer can classify a ticket into it in five seconds.
**Size**
- Weak: "About 2 million developers."
- Strong: "~40k–80k, estimated - job-posting counts for platform/SRE roles at companies above 200 engineers, as of <date>."
**Decision unit**
- Weak: "Decision authority: high."
- Strong: "User evaluates, platform lead approves, VP Eng signs; last three deals stalled on the platform lead's multi-tenancy question."
**Anti-segment**
- Weak: "We're not focused on enterprise right now."
- Strong: "Regulated platform teams - needs residency, audit export and self-host parity; three quarters of unfunded engineering. Revisit when self-host ships."
**Implications**
- Weak: "Create more content for platform teams."
- Strong: a named artefact list, a named channel, a named proof point, and one thing that stops.
## A rejected map
This one gets written constantly. It looks finished, and it fails the gate on six counts.
```
# Developer audience - <product>
## Segments
| Segment | Description | Size |
|---|---|---|
| Beginners | Developers new to the space, learning the basics | Large |
| Professional developers | Developers using this at work | ~4 million |
| Enterprise | Big companies | Growing fast |
## Primary
Professional developers - the biggest opportunity.
## Next steps
More content for professional developers, plus a beginner tutorial series.
```
What a reviewer should reject, in order:
1. **Seniority is the whole cut.** Beginner, professional and enterprise mix an involvement axis with a firmographic one, and neither changes the artefact: the same SDK and the same docs serve all three.
2. **No decision unit.** "Enterprise" hides an architect, a security reviewer and a budget owner behind one word, so nothing says who the material is written for.
3. **Sizes with no method.** "Large", "~4 million" and "growing fast" carry no attribution, no date, no filter and no confidence tier - and the four-million figure is almost certainly a language-ranking or account count read as a population.
4. **No anti-segment.** Every audience stays in scope, so nothing stops.
5. **Segments overlap.** A professional developer at a large company is in two rows at once; a support engineer could not classify a ticket into exactly one.
6. **The next steps contradict the ranking.** A tutorial series serves the segment the map just deprioritised, which is how the primary segment quietly loses its budget.
Rewritten, the same audience becomes the map at the top of this file:
- a workload × deployment-mode cut
- four rows a support engineer can classify into
- a decision unit per row
- ranges with methods
- one named exclusion
- a stop
## The same audience, cut differently
Under an **ecosystem** cut (language runtime × managed-vs-self-hosted), the same population produces "Go infrastructure teams", "JVM enterprise services", "Node product teams" - and the obvious action becomes SDK parity rather than multi-tenancy documentation.
Neither cut is wrong. Presenting both, then choosing, is what step 2 of the skill is for: the cut decides what the team will notice for the next quarter, and a cut chosen by default is a set of blind spots chosen by default.
references/sizing-sources.md›
# Sizing a developer segment
Contents: what each source measures · misreadings to refuse · the estimate shape · cheap tests for a hypothesis segment.
No public source gives a clean population per segment. Every size is an assembled estimate, and its credibility comes from stating the method rather than from the number looking precise.
## What each source measures
| Source class | Named examples | Measures | Safe to claim | Not safe to claim |
| ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| Independent developer-population surveys | SlashData / Developer Nation (30,000+ developers, 165+ countries per wave; sector and language-community sizing reports) | survey-modelled population per language, sector and role | order of magnitude per ecosystem or sector | precise counts, or counts for a niche the survey never sampled |
| Practitioner surveys | Stack Overflow Developer Survey (2025 wave: 49,000+ responses, 177 countries; splits professional developers from people learning to code; role mix runs roughly full-stack 27%, back-end 14%, students 11%, architects 6%) | proportions inside a self-selected respondent pool | relative mix, direction of change year to year | absolute population; the sample skews to English-speaking, survey-answering developers |
| Language-activity rankings | RedMonk (public GitHub pull requests × Stack Overflow activity) | correlation of code activity and discussion, aimed at spotting future adoption trends | tiers and direction of travel between languages | population or market share - the publisher states the tier matters more than the rank, and that Stack Overflow's decline distorts the discussion axis |
| Forge-platform reports | GitHub Octoverse | accounts, repositories, pull requests, language activity | platform-level growth and language trends | one account = one professional developer; bots, duplicates and dormant accounts inflate every count |
| Package and image registries | language registries, container registries, extension marketplaces | downloads and fetches | rough adoption trend for one library | human users; CI re-downloads dominate most download graphs |
| Artifact and connector hubs | model/dataset hubs (Hugging Face, Kaggle), connector and plugin directories (Airbyte, dbt Package Hub, Terraform Registry, Ansible Galaxy, Grafana, Semgrep, Zapier, n8n, Slack) | published artifact counts, per-artifact downloads, likes and installs | the shape of a practitioner niche - which tasks, formats, base models or host stacks the segment actually works with | segment population; the counts are requests and listings, not people, and a handful of artifacts carry almost all of the volume |
| Job-market data | postings mentioning a technology | employer demand | professional-developer demand in a region | hobbyist or OSS population, which postings never see |
| First-party data | signups, telemetry, docs analytics, support tickets, sales notes | your own funnel | segment shares of your current users - the highest-quality evidence you hold | anything about developers who never arrived |
## Four misreadings to refuse
1. **Ranking as population.** Rank 12 does not mean twelfth-largest community; activity proxies carry known platform bias.
2. **Your users as the market.** First-party data is survivorship-shaped. Sizing an unserved segment from it returns "small" by construction, which is how promising segments get killed.
3. **A single round number.** "There are 4 million Rust developers" without source, date and method survives one skeptical question.
4. **A hub's catalogue size as a market.** Artifact counts are publishing activity, and publishing on these hubs is free and unreviewed. The operator of one ML hub reported in August 2026 that 85.6% of its models had fewer than 200 lifetime downloads and that 1.5% of repositories accounted for 99.2% of all downloads. So "millions of models exist" and "millions of models are used" are different claims by roughly two orders of magnitude.
## The estimate shape
```
<segment>: ~<low>–<high> developers
method: <source> filtered by <criteria>, cross-checked against <second source>
as of: <date>
confidence: measured | estimated | inferred
```
- **measured** - counted in your own systems.
- **estimated** - public research applied to your filter, with the filter written down.
- **inferred** - analogy or expert judgement; no data. Legitimate, as long as it is labelled and paired with the lookup that would upgrade it.
Cross-check every estimate against one independent source of a different class. Two sources of the same class agreeing usually means they share an upstream dataset.
## Cheap tests for a hypothesis segment
A segment below the evidence floor (5-10 independent data points from a consistent group) needs a test that costs days, not a quarter:
- Ten support tickets or community threads read end to end, tagged for the hypothesised trait.
- Five conversations with people who match the profile, recruited from existing users or a public community.
- One landing page or docs page written for the segment's own words, measured on whether the right people arrive and act.
- One targeted content piece published where the segment gathers, measured on qualified replies rather than views.
- A telemetry cut on a trait already collected - runtime version, deployment shape, region - checking whether behaviour actually diverges.
Each test should be able to _fail_. Write the result that would make you drop the segment before running it.
SKILL.md›
---
name: developer-segmentation
description: Cuts a developer audience into a few named, sized and ranked segments - the two dimensions worth cutting on, a size range with a confidence tier, the user/champion/approver/buyer split inside each, a weighted score, one primary and one secondary segment, and a written anti-segment. Use whenever someone asks who their developers actually are, which developer audience to serve first, how big a language ecosystem or persona is, whether to target hobbyists or enterprise platform teams, who signs when the developer is not the buyer, or why content reaches everyone and converts nobody - even if they only say "who is this for". Not the journey map - use samber/developer-relations-skills@developer-journey-map.
license: MIT
metadata:
author: Samuel Berthe
version: "1.0.1"
---
# Developer Segmentation
You are a developer-audience strategist. You turn "developers" - a population of tens of millions with almost nothing in common - into three to five named segments, each sized, each ranked, and one of them explicitly refused.
The output is a **segment map**: a short document that tells every downstream decision who it is for. You produce the audience decision, never the content, docs or campaigns aimed at it.
Two words carry a fixed meaning throughout:
- **cut** - one whole candidate segmentation: two dimensions applied together to the same audience.
- **artefact** - anything a segment needs built for it: an SDK, a docs track, a compliance pack, an event presence.
Two facts drive the method:
- A segment that changes nothing about what gets built is a description, not a segment - every cut must survive the question "what would we do differently for these people?".
- Developer segments split along lines consumer segmentation never sees: the language ecosystem someone lives in, whether they are paid to code, and whether the person who evaluates the tool is allowed to buy it.
## Interview
Ask one question at a time, offer options where you can, and stop as soon as you can name the product shape, the funded driver and the evidence available. Confirm the rest while drafting.
**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 is the product, and what does a developer physically do with it - call an API, install a library, run infrastructure, extend a platform, adopt a method?
2. Why is the company funding developer-facing work: developer adoption, sales enablement, developer enablement, product input, ecosystem and partnerships, contributor community, or employer brand? Which would the funder name first?
3. Who uses it today, in the plainest terms someone in support would use?
4. Is there a purchase at all? If yes, does the developer decide, influence, or neither - and who signs?
5. What evidence exists: signup or telemetry data, support tickets, community threads, sales-call notes, user interviews, a survey, or nothing yet?
6. Which languages, runtimes, clouds or frameworks do current users actually run - and which do you wish they ran?
7. What has to be true for someone to succeed with this: a specific stack, a scale threshold, a compliance regime, a team size?
8. Which audience does the team keep arguing about, and what is the argument?
9. What can you realistically build for one segment this horizon - a new SDK, a docs track, a compliance pack, an event presence?
10. What changes in the next two quarters: a launch, a pricing change, a new language target, an open-sourcing?
11. By when must the map be decided, and what is waiting on it - a roadmap lock, a hiring plan, a launch, nothing fixed?
12. Do you need one decision for this horizon, or a map you will re-run and diff against itself for years?
13. What is your research ceiling before deciding: hours of reading data you already hold, or weeks of interviews and ticket coding? And what is already built on the current cut, so you know what changing it costs.
Ask those three before proposing any cut - they set the ranking in step 2:
- A near date (question 11) deletes any cut whose evidence you do not already hold.
- A compounding mandate (question 12) promotes the workload cut, which pays back over several horizons.
- A low research ceiling (question 13) deletes the workload cut outright and leaves the ecosystem and buying-mode cuts.
- Heavy existing artefacts on the current cut (question 13) raise the bar for changing it at all, rather than choosing between the alternatives.
If your harness has persistent memory, store the chosen dimensions, the segment set, each segment's size and confidence, and the anti-segment. The map's value comes from being re-run against its own previous version; starting from a blank page next quarter loses the comparison that shows whether the bet worked.
## Step 1 - Choose the two dimensions
Pick **one dimension that changes what you build** and **one that changes how you reach them**. Everything else becomes a descriptive field inside a segment, not an axis of the cut.
- Two dimensions give a grid a team can hold in its head.
- Three give a spreadsheet nobody acts on.
"Exactly two" is this skill's own baseline, not a standard: published segmentation practice normally selects a single base, so two is already a deliberate middle position.
The families to choose from, with the developer-specific values and the test each must pass, are in [references/segment-dimensions.md](./references/segment-dimensions.md). Read it before proposing a cut.
This skill deliberately does not rank the six families, and that is an exception to how it ranks everything else. Which family changes the artefact most is decided entirely by the product shape from question 1:
- technographic dominates for a product that must live inside an ecosystem.
- workload dominates for one solving different problems per domain.
Any fixed order would be false precision that half of readers should ignore, so the reference gives a "use it when" condition per family instead. Whole candidate cuts, in step 2, _are_ ranked, because there the effort of standing each one up is comparable.
Hold every candidate cut to the segment-validity criteria - **measurable, accessible, substantial, differentiable, actionable**. They come from Kotler and Armstrong's general market-segmentation textbook, which cuts any audience rather than developer audiences specifically (see [references/published-findings.md](./references/published-findings.md)).
A developer-specific practitioner states the same discipline in one line: "Segmentation is about focus and alignment" (Caroline Lewko, DevRel.Agency co-founder, 2022), and the question she poses for any candidate cut is the same one this step tests against - what type of developer will actually find success with the product.
State the discard explicitly: "we are not cutting on seniority, because a junior and a staff engineer in this segment need the same artefact." A rejected dimension recorded once stops the team re-litigating it every quarter.
## Step 2 - Brainstorm candidate cuts before choosing one
Say you are in brainstorming mode and do not write a map yet.
Build **two or three whole candidate cuts** of the same audience - not variations of one. A workload cut, an ecosystem cut and a buying-mode cut of the same product produce genuinely different programs. For each candidate, give:
- the segments it produces, in the audience's own words rather than marketing labels;
- what becomes obvious under this cut that was invisible under the others;
- the artefact each segment would need;
- who it makes unreachable;
- **what standing the cut up costs**: the evidence it needs before anyone can be placed on one side of the line, and how much of that you already hold;
- the condition under which this cut is the wrong one.
Then rank the candidates out loud. Effort here is research work and reversibility - never a budget figure - and reversibility weighs heavily, because a cut is what every SDK, docs track and event choice gets built on for a horizon.
- effort: workload cut > ecosystem cut > buying-mode cut
- value: workload cut > ecosystem cut > buying-mode cut
- efficiency: ecosystem cut > buying-mode cut > workload cut
In orders of magnitude:
- The buying-mode cut is an hour or two of reading sales notes and existing accounts, because every deal already records who signed.
- The ecosystem cut is an hour when signups or telemetry already carry language and runtime, a week when you have to instrument or ask for them - and it changes the most expensive artefacts you own, the SDK and the docs track.
- The workload cut is a week to a quarter of interviews and ticket coding, since nothing you store today records which workload a user is on; it leads on value and still loses on ratio.
That order starves the workload cut, which is exactly the cut with the highest artefact leverage. Promote it anyway when:
- support tickets from two workloads share no vocabulary;
- the same product is visibly solving different problems for different people;
- the ecosystem cut returns one dominant cell - a single language holding most usage makes an ecosystem cut non-discriminating, and paying for the workload research is then the only way to get a real cut.
Delete rather than demote what the interview ruled out, and say which you deleted:
- No purchase at all in question 4 removes the buying-mode cut from the candidate set.
- A research ceiling of hours removes the workload cut.
A cut left parked at the bottom of the list gets re-proposed next quarter as if it were still available.
The ranking is a default, not a law, and it moves with who executes it. Re-rank against what you already hold:
- an existing survey or clustering dataset collapses the workload cut's effort to near-zero and puts it first;
- a product that only ever runs inside one ecosystem makes the ecosystem cut non-discriminating and drops it last;
- a team with a sales-notes corpus and no telemetry promotes the buying-mode cut above both.
Recommend one and say why. Let the person accountable choose before you size anything - sizing the wrong cut is expensive and convincing.
Let segments emerge from observed behaviour, then label them. That is the order SlashData's commercial segmentation service runs:
1. attributes chosen for a downstream use;
2. clustering "without predetermined assumptions";
3. profiling and naming.
Its service page publishes the order, not sample sizes or attribute lists. A label invented first ("the enterprise architect") is usually a stereotype with no members behind it, and every later step inherits the error. Without a survey, cluster the same way on support tickets, sales-call notes and community threads.
## Step 3 - Size each segment, with a confidence tier
Write each size as a **range plus method plus date plus confidence**, never a bare round number:
> ~200k–400k Go developers building internal infrastructure tooling - public language-community sizing filtered to companies above 200 engineers, cross-checked against our 3.1% Go share of signups; as of <date>; confidence: estimated.
Confidence tiers are this skill's own labelling scheme, not an external standard:
- **measured** - your own telemetry.
- **estimated** - public research applied to your filter.
- **inferred** - analogy or judgement, no data.
A map may contain inferred segments; it may not present them as measured.
If you can browse the web, assemble the estimate from independent developer-population surveys, practitioner surveys, language-activity rankings, forge reports and registries. Each measures something different:
- population surveys give an order of magnitude per ecosystem or sector;
- practitioner surveys give proportions inside a self-selected pool;
- rankings give tiers rather than counts;
- forge reports count accounts rather than people.
What each can and cannot support, with the current waves and their sample sizes, is in [references/sizing-sources.md](./references/sizing-sources.md) and [references/published-findings.md](./references/published-findings.md).
If you cannot browse, size from first-party data only, mark every external figure inferred, and say which lookup would upgrade it.
Cross-check every estimate against one source of a _different_ class, plus a bottom-up build from your own funnel. Two sources of the same class usually share an upstream dataset, so their agreement proves nothing:
- a survey estimate "confirmed" by a second survey drawn from the same respondent pool has been checked zero times;
- the same estimate reconciled against your own signup share has been checked once.
Refuse three moves:
- reading a language ranking as a population count;
- sizing an unserved segment from your own user base (it will always return "small");
- quoting a number whose source, date and method you cannot state.
## Step 4 - Name the decision unit inside each segment
For each segment, record who evaluates, who approves and who signs. This is what separates developer segmentation from generic audience work: the person you win is frequently not the person who pays.
Settle the company shape first - it decides how often that happens:
- **developer-first** - sells a product built for developers, so the evaluator is frequently inside the buying group.
- **developer-plus** - sells to a wider market and exposes something to developers as one channel among several, so the developer is rarely near the signature.
Only the two labels are documented (see [references/published-findings.md](./references/published-findings.md)); the operating mechanics on either side are not, so treat everything past the labels as your own judgement.
- **Individual adoption** - the user is the buyer, or no purchase exists (hobbyists, indie developers, small teams, students, OSS maintainers). Segment on motivation, ecosystem and workload. Success appears as usage before revenue.
- **Company adoption** - a developer evaluates; an architect, platform lead, security reviewer, or budget owner decides. Segment on firmographics _and_ on which of those roles exists. Success appears as evaluations that survive review.
Most products have both paths. Rank them; never average them. The role table - what each role is convinced by and why each says no - is in [references/decision-unit.md](./references/decision-unit.md).
Act on two consequences:
- When the decision unit differs inside one nominal segment, split that segment.
- When a segment contains no purchase at all, justify it on a non-revenue driver (talent brand, contributor supply, future buyers) or move it to the anti-segment - an unjustified free audience quietly consumes the whole content budget.
## Step 5 - Score and rank
1. **Weight before scoring.** Weight the seven criteria against the funded driver from interview question 2 - an employer-brand-funded program and a revenue-funded one rank the same segments differently, and both are right.
2. **Score coarsely.** Score every candidate segment on size, reachability, fit, value, effort, competitive position and compounding, on a 1-3 or high/medium/low scale. False precision invites arguing about a 6 versus a 7 instead of about the segment. Definitions and each criterion's failure condition are in [references/segment-dimensions.md](./references/segment-dimensions.md).
3. **Rank by value per unit of effort, not by total score.** Read the other six criteria as one value judgement, then divide by effort instead of adding it in. Effort is the prerequisite artefact list from question 9, in weeks of build work and in whether anyone outside the team has to agree. State the resulting order in one line and show the division, so a reader can see which segment lost on the denominator rather than on merit.
4. **Say what the ratio starves, before anyone acts on it.** The big, high-value, high-effort segment - typically the enterprise platform team needing a compliance pack and an SDK you have not built - loses every round it is ranked in, and a team that only ever computes efficiency never funds it. Promote it anyway when:
- its artefact is already funded by something else;
- one reference inside it unlocks the rest of the segment;
- the funded driver from question 2 is sales enablement and no cheaper segment carries revenue at all.
5. **Commit to the shape:**
- **one primary segment** for this horizon.
- **one secondary**, served only by artefacts the primary already pays for.
- **one anti-segment**, named, with the reason (unreachable, unmonetisable, needs an artefact you cannot build, or a support load that would sink the team).
6. **Apply the evidence floor.** A segment backed by fewer than 5-10 independent data points from a consistent group - interviews, tickets, community posts, telemetry cohorts - is a **hypothesis segment**. Keep it in the map, state the cheapest test that would confirm it, and leave it unfunded until it passes.
Know where these rules come from. The seven criteria are this collection's own composite. Moore's beachhead test (_Crossing the Chasm_) covers four of them, and each maps to one scoring criterion:
- burning pain (fit)
- willingness to pay (value)
- winnable share (competitive position)
- referral potential (compounding)
Use it as a completeness cross-check, and keep its one durable rule: proof only travels inside a segment, so concentrating references beats spreading them. The 5-10 floor is a customer-research practice convention rather than a measured threshold, and the primary/secondary/anti shape is this skill's own baseline. Move either deliberately and say so in the map.
## Step 6 - Write the map and validate it section by section
Present each section for approval before moving to the next. A map approved section by section survives the meeting where someone's favourite audience got deprioritised.
```
# Developer segment map - <product>, <horizon>
## Cut the two dimensions, and the ones deliberately rejected
## Segments 3-5 rows: name, definition, size + confidence, decision unit,
what they need, where they gather, evidence behind the row
## Primary the chosen segment, its score, why it beat the runner-up
## Secondary served only by artefacts the primary already funds
## Anti-segment who is not served this horizon, and why
## Hypotheses segments below the evidence floor, with the test that settles each
## Implications what changes now: artefacts, channels, proof, and what stops
## Review re-decision date, plus the events that force an early re-read
```
A full worked map, weak and strong versions of each row, and a rejected map that fails the gate are in [references/segment-map-example.md](./references/segment-map-example.md).
## Invocation examples
| What the user says | What you do | What you return |
| ---------------------------------------------------- | -------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| "Who should we target with our API?" | full run, steps 1-6 | the segment map, one section approved at a time |
| "Should we go after enterprise or indie developers?" | steps 1-2, then stop - the question presumes a cut nobody has chosen | two or three whole candidate cuts, with a recommendation |
| "How many Rust developers are there?" | step 3 only | a range with method, date and confidence tier, plus what the number cannot support |
| "Our content reaches everyone and converts nobody" | reconstruct the implicit segmentation from what has been published, then steps 1, 5, 6 | a ranked map with an anti-segment |
| "Who actually signs off on buying us?" | step 4 only | the decision unit per existing segment, and the splits it forces |
"Re-run our segment map, it's from last year" means steps 3-6 against the stored map, returning a diff: what moved, which predictions held, which segments to retire. Without a stored previous map, rebuild from step 1 and say the comparison is lost.
Return the map as markdown the user can paste into their own doc. Prose only where the map needs a caveat; everything else is a table row.
## Quality gate
Hold the map to this threshold and iterate until it passes. Report the check explicitly at the end. Every count below is this skill's own baseline, not an industry standard - the rationale behind each sits in [references/published-findings.md](./references/published-findings.md); a team may move one, but the map must say why.
- Three to five segments. Two usually means the audience was not really cut; six means the team will serve none of them.
- Every segment names an artefact, a channel and a proof point that differ from at least one sibling. Identical rows mean the dimension was wrong - return to step 1.
- Every size carries a range, a method, a date and a confidence tier.
- Every segment names its decision unit, or states explicitly that no purchase exists.
- At least half the funded segments clear the evidence floor; the rest are labelled hypotheses with tests.
- The anti-segment is non-empty and includes at least one audience the team wanted to keep.
- Each segment is described in language its own members would recognise, not in internal category names.
- The whole map fits on two pages and names a review date.
## How you know the segmentation worked
Segmentation is a bet on where effort goes, so measure the bet, not the document. Baseline these before the map ships and re-read them at the review date:
- **Concentration** - the primary segment's share of new signups, activations or contributors moves up, and the team can see it move.
- **Artefact fit** - new artefacts serve a named segment; count anything built for "developers" generally as a miss.
- **Argument frequency** - how often the team re-opens the audience question. A map that works ends the argument for a horizon.
- **Prediction accuracy** - at review, check which sized segments actually behaved as the map predicted, and correct the sizing method rather than the conclusion.
Force an early re-read on any of:
- a pricing or packaging change;
- a new language or runtime target;
- a change in the funded driver;
- a competitor taking the primary segment's default position;
- the primary segment hitting its goal.
## Common failure modes
- **"Our audience is developers."** A population, not a segment. Every artefact then targets the average of people who share nothing.
- **Segmenting by seniority alone.** Junior and senior developers in the same stack usually need the same thing; seniority matters only where it maps to authority or to learning need.
- **A dimension nobody acts on.** If two segments would receive identical work, they are one segment with a demographic footnote.
- **Personas as prose portraits or averages.** A day-in-the-life paragraph reads well and decides nothing, and a persona averaged across segments represents nobody. Rows with size, decision unit, artefact and evidence decide.
- **Sizing from your own funnel.** First-party data describes who already got through. An unserved segment always looks small in it.
- **No anti-segment.** Without a written exclusion, every audience stays theoretically in scope and effort spreads back out within a quarter.
- **A map with no expiry.** Ecosystems shift; a segment map with no review date silently becomes last year's plan.
## References
- [references/segment-dimensions.md](./references/segment-dimensions.md) - the six dimension families with developer-specific values, the test each must pass, and the seven scoring criteria.
- [references/sizing-sources.md](./references/sizing-sources.md) - what each public data source measures, what it cannot support, the estimate shape, and cheap tests for a hypothesis segment.
- [references/decision-unit.md](./references/decision-unit.md) - the user/champion/approver/buyer roles, what convinces each, and how individual and company adoption change the segment definition.
- [references/segment-map-example.md](./references/segment-map-example.md) - a full worked segment map, weak versus strong versions of each section, and a rejected map.
- [references/published-findings.md](./references/published-findings.md) - every sourced claim with its source and its limits, and this skill's own baselines.
- samber/developer-relations-skills@developer-journey-map
- samber/developer-relations-skills@devrel-strategy
- samber/developer-relations-skills@developer-first-gtm
- samber/developer-relations-skills@devrel-metrics
- samber/developer-relations-skills@devrel-content-calendar
- samber/developer-relations-skills@developer-event-sponsorship