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. 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).

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 day or two when you have to instrument for them, longer when you have to ask users and wait for answers - and it changes the most expensive artefacts you own, the SDK and the docs track.
• The workload cut is a few days of ticket coding to a quarter of interviews, 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 and 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); 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.

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.
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.

Invocation examples

"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; 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 - the six dimension families with developer-specific values, the test each must pass, and the seven scoring criteria.
• 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 - the user/champion/approver/buyer roles, what convinces each, and how individual and company adoption change the segment definition.
• 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 - 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