Why segment your users?

In a typical marketplace, not every user has the same needs. But you can usually identify several subgroups of users who have very similar needs to one another. We call these user segments.

To understand why this matters, consider what it takes to launch and maintain a successful product. From its earliest stages, your product must meet the needs of some group of users or it will die.

This may seem obvious, but in practice it’s why many promising products fail. That’s because failing to segment your users is to tacitly accept the myth of the average user. That’s the belief that to successfully prioritize what functionality to build next, you need only build features that address the most frequently voiced needs. Here’s why that’s a recipe for disaster.

Say our product is a new community swimming pool 🏊. The top-requested features (and number of requests) are as follows:

  1. Starting blocks | 17
  2. Ping pong table | 15
  3. Lounge chairs | 14
  4. Concession stand | 12
  5. Swim lanes | 12
  6. Branded swim caps | 11
  7. Water slide | 7
  8. Basketball court | 4

We have the budget and capacity to choose three of these features by opening day so we choose the top three.

The opening day arrives and we eagerly await to see who subscribes for an annual membership to my pool with with starting blocks, a ping pong table, and lounge chairs.

But to our accountant’s horror đŸ˜±, no one subscribes!

The myth of the average user

Why aren’t people subscribing? Did they lie about their needs?!

No, they likely told the truth. But further analysis would have shown that in order to subscribe


  • Competitive swimmers 🏊 need starting blocks AND swim lanes
  • TeenagersđŸš¶need ping pong AND a concession stand AND a basketball court
  • Parents đŸ‘Ș need lounge chairs AND swim lanes for lap swim AND a waterslide (to keep the youngins busy)

By delivering starting blocks, a ping pong table, and lounge chairs, we incidentally met one necessary condition of each segment, but did not deliver sufficient functionality to be good enough for any segment.

If you ignore segmentation, you can build the top-requested feature ideas and STILL no one will be happy.

Implicit in our segment-less prioritization was an assumption that a group of “average users” exists, who would immediately subscribe if only they had starting blocks AND ping pong tables AND lounge chairs. But we’ve discovered that no such average customer exists.

Failing to segment your users is to tacitly accept the myth of the average user.

With poor growth and insufficient revenue, we might be forced to shutter the operation before it got off the ground.

A better strategy (for business to go swimmingly 🌊💰💰💰)

If we could rewind and do it over, when interviewing users we’d do more than just tally requests. We’d also record who asked for what, how important it is to them (must-have? should-have? nice-to-have?), and what need it solves. Doing so will help identify patterns and discover new segments of users with shared needs and must-have functionality.

Since constraints will only allow us to deliver three features by opening date, we should target the needs of one core group of users. In this case we’d do best to choose competitive swimmers; membership across teens and parents may fluctuate due to a number of factors (an especially cool summer, a new mall across town, the pool’s reputation for being a good place for families, and so on
) but the hardcore competitors will keep coming regardless, as long as we deliver their must-have features — starting blocks & swim lanes.

Since we have the capacity for a third feature, we might even consider branded swim caps, which were highly requested by competitors as a nice-to-have. Doing so means forgoing the ping pong table or lounge chairs until later, but it will sweeten the deal for our early adopters and make our offering stickier. As we now know, choosing another top-rated feature like ping pong or lounge chairs would be a waste, since additional must-haves must be delivered before teens or parents will subscribe.

Targeting competitors as early adopters means forgoing the business of teens and parents for now, but doing so will generate the revenue we’ll need to bring our offering to the mainstream.

Not all segments are created equal

It should now be clear why user segmentation is critical. The hard part is formulating accurate segments around real user needs. In our simplified example above, we pretended we had full access to our prospective customer base and could ask them about their needs one-by-one. What a dream it would be if this were so easy in practice!

In reality, we product managers spend our days wading through a cloudy, amorphous, swirling mass of feature requests, user research, and secondhand reports of what end users are asking for (and complaining about).

The elusive and ever-evolving problem space


The sheer challenge of defining accurate, meaningful segments explains the use of demographic segments like 39 year old moms with two kids living in the midwest. After all, it’s much easier to identify and market to groups of users defined around concrete characteristics than shared abstract needs. But at the end of the day, demographic segments are only helpful to product teams if they correlate with certain sets of needs.

Since comprehensive user research across your entire prospective user base is likely impossible, your best bet is to sample your user base by collecting user inputs on an ongoing basis. Save key insights you find in feature requests, customer support tickets, surveys, check-in meetings, sales calls, and user interviews, and search for patterns when it comes to different users’ must-have functionality. In time, these patterns will solidify into user segments, and those segments will form the bedrock of all future prioritization efforts.

Join the discussion!

I recently asked productboard CEO Hubert Palan for his take on user segments, why they’re important, and how they differ from personas. You can check out his full response below. đŸŽ„ We’d love to hear what you think.