Customer Segmentation
Divide the market into distinct groups with different needs, budgets, and behaviors to find your best-fit segment.
Why
A product for "everyone" serves no one well. Customer segmentation forces you to identify which specific group has the most acute pain, the most budget, and the most reachable channel — and to build for them first. The same product can be a must-have for one segment and a nice-to-have for another; segmentation tells you which is which. It also prevents the most common startup mistake: building a generic product, getting mediocre feedback from everyone, and never achieving the sharp fit that creates word-of-mouth. The segment you pick first determines your pricing, your messaging, your feature priorities, and your channel — getting it wrong cascades into every other decision.
When
After you have a hypothesis and some initial user conversations. Takes 1-2 days of analysis. Revisit when you hit a growth plateau or before a major pivot.
How
1. Collect segmentation variables - Firmographic (B2B): company size, industry, revenue, tech stack - Demographic (B2C): age, role, experience level, income - Behavioral: current tool, frequency of problem, budget spent - Psychographic: goals, values, attitudes toward risk/new tools 2. Cluster into 3-7 segments - Group users who share variables and have similar needs - Name each segment vividly: "solo GitHub dev", "enterprise DevOps lead" 3. Score each segment on 4 criteria - Pain: how acute is their problem? (1-5) - Budget: can/will they pay? (1-5) - Reach: can you access them cheaply? (1-5) - Fit: does your solution match their exact need? (1-5) - Total = sum; your beachhead = highest total 4. Choose a beachhead segment - The segment you serve first, to the exclusion of others - It should be small enough to dominate, large enough to sustain you 5. Define the segment sharply - Write a 1-paragraph persona: who they are, what they do, their top 3 pains - List 3 channels where you can reach them - Note what they will NOT care about (to prevent feature creep)
Example
Product: a code review bot for GitHub PRs. Initial interviews: 30 devs across different company sizes. Segments identified: 1. Solo/indie devs (1 person) Pain 2 Budget 2 Reach 5 Fit 2 = 11 2. Small team leads (2-10) Pain 4 Budget 3 Reach 4 Fit 5 = 16 ← beachhead 3. Mid-size eng managers (10-50) Pain 4 Budget 5 Reach 2 Fit 4 = 15 4. Enterprise DevOps (50+) Pain 3 Budget 5 Reach 1 Fit 3 = 12 Beachhead: small team leads (2-10 devs) - Pain: they review PRs themselves and it is their biggest time sink - Budget: $20-50/mo per team, they have a tools budget - Reach: active on GitHub, r/ExperiencedDevs, DevOps Discord - Fit: a bot that reviews PRs while they sleep is exactly their need - Will NOT care about: SOC2 compliance, SSO, audit logs (enterprise concerns) Decision: build for small team leads first; enterprise is a later expansion.
Common Problems
- ⚠Choosing the largest segment instead of the highest-scoring one — large segments are often the hardest to reach and serve.
- ⚠Defining segments too broadly — "SMB" includes a 2-person agency and a 200-person firm with completely different needs.
- ⚠Scoring segments on intuition alone — use data from interviews, surveys, and channel research to score each criterion.
- ⚠Trying to serve 2+ segments at once — you split focus, build a generic product, and satisfy neither segment's sharpest need.
Best Practices
- ✓Name segments vividly and write a 1-paragraph persona for each — "solo indie dev on GitHub" is actionable; "small business" is not.
- ✓Score segments on all 4 criteria (pain, budget, reach, fit) — a segment with pain 5 but reach 1 is a research project, not a business.
- ✓Explicitly list what the beachhead segment does NOT care about — this is your anti-roadmap that prevents feature creep.
- ✓Plan the expansion path: beachhead → adjacent segment → next — knowing the sequence prevents premature broadening.