developer-segmentation

Choose exactly two dimensions: one that changes what you build and one that changes how you reach them. Brainstorm two or three whole candidate cuts, rank them on effort, value, and efficiency, then size, score, and commit to one primary, one secondary, and one anti-segment.

Write each size as a range with a method, date, and confidence tier: measured from your telemetry, estimated from public research, or inferred from judgement. Cross-check every estimate against a source of a different class plus a bottom-up build from your own funnel.

Usually no. A junior and a staff engineer on the same stack and workload typically need the same SDK, docs, and samples. Seniority earns a place only when it maps to authority over tool standardization or to a distinct learning need; otherwise record it as a descriptive field.

No. First-party data is survivorship-shaped and describes only who already got through your funnel, so an unserved segment always looks small in it. Build an external estimate from public surveys or rankings, then run a cheap falsifiable test before funding the segment.

An anti-segment is a named audience you explicitly refuse to serve this horizon, with the reason recorded. Without it, every audience stays theoretically in scope and effort spreads back out within a quarter; the gate requires it to include at least one audience the team wanted to keep.

Re-read it at the scheduled review date, typically quarterly, and diff it against the stored previous version. Force an early re-read on a pricing or packaging change, a new language target, a change in the funded driver, a competitor taking your primary segment's default position, or the primary segment hitting its goal.