Who Is Your Real Customer? A Practical Method for Product Segmentation

Ask five people on a product team who the customer is, and you will often get five different, defensible answers. The executive sponsor says leadership. The designer says the person clicking through the interface every day. The salesperson says whoever signs the check. None of them are wrong. That is exactly the problem. When “the customer” can mean four or five different people depending on who you ask in the hallway, the product has no real customer at all, it has a committee, and committees are notoriously bad at producing a sharp, useful design.

Customer segmentation in product management usually gets treated as a marketing exercise, something that happens in a slide deck with personas and demographic ranges. That version of segmentation is useful for messaging and channel strategy, but it does not answer the question a product team actually needs answered before it writes a line of code: when two requirements conflict, whose need wins? Without a clear answer, teams default to trying to satisfy everyone a little, which is a quieter and slower way of failing than shipping the wrong feature outright.

The Problem with Designing for Everyone

There is a comforting logic to inclusive design targets. If a product serves executives, analysts, and IT administrators, and you build something that works reasonably well for all three, surely that is safer than picking one and under-serving the other two. In practice it rarely works that way. Each of those groups has different mental models, different vocabulary, different tolerance for complexity, and different definitions of a good outcome. A dashboard built to satisfy an executive’s need for a single clean number and an analyst’s need to slice that number eight different ways will usually do both jobs poorly, because the two needs pull the interface in opposite directions.

A product that tries to optimize equally for everybody often becomes weak for everybody.

This is not a claim that other users do not matter. It is a claim about where a limited amount of design and engineering attention should be spent first. A team has a finite number of decisions it can make well in a given release: which workflow gets the default view, which action gets the shortest path, which error gets the clearest message, which metric gets the headline treatment. Every one of those decisions is a small bet on whose experience matters most in that moment. Trying to hedge every one of those bets across three audiences at once does not remove the tradeoff, it just hides it, and it usually gets resolved by whoever complained loudest in the last planning meeting rather than by a deliberate decision.

A Three-Tier Model

A workable alternative is to sort the people who interact with a product, or are affected by it, into three tiers, and to be explicit about which tier gets dedicated design effort. This sits inside the broader question of customer segmentation in the outcome-first sequence, where the segment gets defined before the need, and the need gets defined before any output.

Core customer, roughly 80 percent of focused effort

The core customer is the person or role whose problem the product exists to solve. This is not the person who happens to log in most often, and it is not necessarily the person who pays. It is the person whose desired outcome the team has decided to organize the roadmap around. The rough 80 percent figure is a prioritization guideline, not a mathematical law measured in story points. It is a way of saying: when there is a conflict, the core customer’s workflow, vocabulary, and success criteria should win, most of the time, by a wide margin.

Secondary customer, roughly 20 percent

The secondary customer has real needs the product should address, and ignoring them entirely would be a mistake. But their needs get accommodated within the constraints set by the core customer’s design, not the other way around. A feature for the secondary customer is worth building when it does not compromise the experience of the core customer to build it.

Population or indirect beneficiary

This group benefits from the product existing, sometimes significantly, but receives no dedicated design effort of its own. Their benefit is a byproduct of the core customer’s outcome being achieved well, not a target the team designs toward directly.

The value of naming all three tiers is not the specific percentages. It is that the exercise forces a team to stop treating “who is this for” as a settled, obvious question and start treating it as a decision that has consequences for every subsequent tradeoff.

A Worked Example: The Internal Analytics Tool

Imagine a mid-sized company building an internal analytics tool meant to help the organization make better decisions from its operational data. Three groups have an obvious stake in it.

Executives want a small number of trustworthy numbers they can glance at before a leadership meeting, ideally with almost no configuration required. Analysts want to build custom queries, explore anomalies, and produce ad hoc reports for whatever question came up that week. IT wants the system to be secure, auditable, and cheap to maintain, and cares relatively little about the interface as long as it does not generate support tickets.

All three groups are legitimate stakeholders. None of the three is automatically the core customer. Here is how a team might actually work through the decision, rather than guessing.

Start with the problem, not the persona. What is the specific, painful problem this tool is meant to resolve? If the honest answer is “leadership currently makes decisions on gut feel because pulling numbers takes analysts three days,” the core problem lives with executives, and the analysts are the people who will build the pipes that solve it for them. If the honest answer is “analysts are drowning in one-off report requests and have no self-service tooling,” the core problem lives with the analysts themselves, and executives are downstream beneficiaries of analysts working faster.

Check problem strength, not just presence. A problem existing is not the same as a problem being worth solving first. Frequency, severity, urgency, cost of inaction, and willingness to change all matter here. If IT files occasional tickets about access requests, that is a real but low-severity, low-frequency irritation. If analysts are missing weekly deadlines because of manual data pulls, that is frequent, urgent, and costly. A complaint is not automatically a high-priority product problem, and a comparison across the three candidate groups on these dimensions usually breaks the tie faster than debating personas in the abstract.

Look at who the product fails without. If executives never open the tool, the company survives on existing reporting habits, uncomfortable but not catastrophic. If analysts cannot use it, there is no data pipeline for anyone else to consume, and the tool has no reason to exist. That asymmetry is a strong signal about where the core design effort belongs, even though executives are the more visible, higher-status audience.

Resist the pull of the loudest voice. Executives are often the easiest group to defer to, because they hold budget and attention. That is a reason to listen to them carefully, not a reason to make them the core customer by default. If the actual bottleneck lives with analysts, a tool designed primarily to please an executive audience with a polished summary view, while analysts still fight the underlying data model, will look successful in a demo and fail in daily use.

In this scenario, a defensible conclusion is that analysts are the core customer, executives are the secondary customer who benefit from faster, more reliable numbers once analysts are unblocked, and IT is closer to a population beneficiary, whose security and maintainability requirements act as guardrails on the design rather than a design target in their own right. A different company, with a different bottleneck, might reasonably reach the opposite conclusion. The method matters more than the specific answer, and it connects directly to the next step in the framework: turning a validated customer and problem into a clearly stated desired outcome before anything gets built.

How This Differs from Buyer, User, and Decision-Maker Segmentation

Product and sales teams already use a familiar segmentation, distinguishing the buyer who approves the purchase, the user who operates the product day to day, and the decision-maker who chooses among vendors. That model is useful and often necessary, particularly in enterprise software where the person swiping the card and the person touching the product are rarely the same individual. It answers questions about sales motion, pricing conversations, and who needs to be in the room during a renewal discussion.

It is a different question from the one this three-tier model answers. Buyer, user, and decision-maker segmentation is largely about the commercial relationship: who controls the money and who signs off. Core, secondary, and population segmentation is about design prioritization: whose workflow the interface is built around when tradeoffs appear. A single person can be the buyer, the user, and the core customer at once, or those roles can be split across three different people while the core customer designation still lands cleanly on one of them based on whose problem the product is solving.

The two models are complementary rather than competing. A go-to-market team benefits from knowing who approves the purchase. A product team building the actual workflow benefits from knowing whose success the interface is optimized around when a hard tradeoff shows up in a design review. When both questions get collapsed into a single, vague notion of “the customer,” a team ends up with commercial clarity and design confusion, or the reverse, and rarely notices which one it is missing until a release goes out and satisfies no one in particular.

Key Takeaway

Customer segmentation in product management works best when it produces a decision, not just a description. Naming a core customer, a secondary customer, and a population of indirect beneficiaries forces a team to state, in advance, whose problem wins when tradeoffs appear, which is a very different exercise from cataloguing every group a product touches. This tiered model runs alongside, not instead of, buyer and decision-maker segmentation used for sales and pricing, since the two answer different questions. Getting the core customer wrong is expensive precisely because everything downstream, the desired outcome, the minimum viable output, and the metrics that define success, gets built to serve whoever was named first.