Lesson 5: Users vs. Customers

Here is a question that sounds trivial until you try to answer it under pressure: when a PM says "the user," do they mean the same person as when a stakeholder says "the customer"? In many products, no. And the gap between those two words is where some of the most expensive prioritization mistakes in the industry originate.

A user is the person who directly interacts with the product. A customer is the person or entity that pays for it. In a large number of real products — most enterprise software, most ad-supported consumer apps, most marketplaces — these are not the same person. When they diverge, a PM who conflates them will optimize for the wrong signal at exactly the moment it matters most: when user needs and customer/buyer needs pull in different directions.

This lesson exists because the Accountability Triangle introduced in Lesson 1 has a hidden trap. "Desirability" sounds like a single, unified question — do people want this? — but the moment users and customers are different people, "desirability" splits into at least two separate questions that can have two different answers. A PM who hasn't separated these will misdiagnose why a product is failing, misassign a success metric, or build a roadmap that pleases the wrong audience. This shows up constantly in real companies: enterprise software optimized purely for procurement checklists that end users hate; ad-supported apps optimized purely for engagement metrics that advertisers pay for, at user experience's expense; parental-control apps where the "user" (a child) has essentially no say over what gets built at all. Understanding this distinction — and knowing where your own product sits on the spectrum — is foundational to nearly every prioritization decision from here forward.

Learning Objectives

1
Define "user" and "customer" precisely, and identify which one (or both) a given stakeholder request actually concerns.
2
Classify a product along the User-Customer Alignment Spectrum, from fully aligned (user = customer) to fully divergent (user and customer have opposing interests).
3
Explain why conflating users and customers leads to systematically biased prioritization decisions, using at least one real-world mechanism (e.g., attention economy, procurement dynamics).
4
Apply a structured method for deciding whose need takes priority when user and customer needs genuinely conflict.
5
Identify the specific interview and case-study failure pattern that results from treating "the user" as a single, homogeneous stakeholder.

Lesson 1 (What is Product Management?). This lesson assumes familiarity with the Accountability Triangle (desirability, feasibility, viability) and the Output vs. Outcome distinction, and extends "desirability" into a more precise, multi-audience concept.

The Core Definitions

A user is the person who directly interacts with the product — clicks the buttons, reads the screen, receives the notification, experiences the friction or delight of the interface.

A customer is the person or entity that makes the purchasing decision and pays for the product, directly or indirectly.

In consumer products with a direct-purchase model (a single person buys and uses a paid mobile game, for instance), these two roles usually collapse into one person, and the distinction barely matters day to day. But as soon as a product is bought by someone other than the person who uses it, the distinction becomes load-bearing.

Consider a few common patterns:

Enterprise software: An IT director or procurement team (the customer) purchases a tool that individual employees (the users) will operate daily. The customer cares about total cost of ownership, security compliance, and vendor reliability. The user cares about whether the tool makes their actual job easier or harder.
Ad-supported consumer apps: The end user does not pay anything directly. The customer is the advertiser, who pays for attention and engagement. The user's experience matters to the business only insofar as it sustains the attention the customer is paying for.
Marketplaces: A two-sided marketplace like a food delivery app has at least three populations to track — the diner (a user), the restaurant (a user and, in a real sense, a customer, since they often pay commission), and in some models an advertiser paying for placement (a customer).
Products built for dependents: A parental-control app, a pet-tracking device, or many categories of children's educational software have a user (the dependent) with essentially no purchasing power or product feedback channel at all — the customer (a parent or guardian) makes every meaningful product decision on the user's behalf.

None of these patterns are unusual or edge cases. They are, in aggregate, more common than the simple case where user and customer are identical.

The User-Customer Alignment Spectrum

It is useful to think of every product as sitting somewhere on a spectrum, rather than treating "user vs. customer" as a binary:

Fully aligned (e.g., a single-player mobile game bought and played by the same person): user research and customer research are effectively the same activity.
Mostly aligned (e.g., a project management tool where the buyer is a team lead who also uses the product daily): the buyer and the daily user overlap substantially, though budget-holder concerns (cost, admin controls) can still diverge from daily-user concerns (speed, ease of use).
Partially divergent (e.g., enterprise software bought by an IT department for employees who never chose it): the customer's criteria (security, compliance, price) and the user's criteria (usability, speed) can both be legitimate but are not the same list, and can trade off against each other.
Fully divergent (e.g., an ad-supported free app where more user attention directly benefits the advertiser-customer, sometimes at the cost of user wellbeing): the customer's commercial interest can be in direct tension with what is actually good for the user.

A PM's first job in this lesson is diagnostic: place your own product honestly on this spectrum before doing anything else. Most of the prioritization mistakes described below come from PMs who assume, by default, that they are further left on this spectrum (more aligned) than they actually are.

Why This Distinction Breaks Naive "Desirability"

Recall from Lesson 1 that desirability is one leg of the Accountability Triangle — do people want this? The user-customer distinction reveals that this question is underspecified. The more precise version is: desirability to whom?

A feature can be simultaneously:

Highly desirable to the customer (a compliance dashboard that procurement loves) and low-desirability to the user (who finds it adds friction to their daily workflow), or
Highly desirable to the user (a feature that reduces the ads they see) and low-desirability to the customer (an advertiser who is, after all, paying specifically for that attention).

A PM who reports "high desirability" without specifying whose desirability has quietly picked a side — usually the side that is easier to measure, or the side with more organizational power, rather than the side that is actually correct for the product's health.

Why This Matters More at Certain Company Stages and Business Models

The user-customer gap is not a fixed property of a company; it is a property of a business model. This means the same company can have wildly different user-customer alignment across different products or even different pricing tiers of the same product. A subscription-based tier of a product (where the paying user is also the daily user) sits much further left on the spectrum than a free, ad-supported tier of the exact same product (where the daily user is not the paying customer at all — the advertiser is). PMs who move between pricing tiers, or who are asked to evaluate "the same feature" across a free and paid tier, must re-diagnose alignment each time rather than assuming it transfers.

The Political Dimension

There's a version of this problem that is not just analytical but organizational: customers usually have more organizational leverage than users. A customer complaint often arrives through an account manager, a sales leader, or a contract renewal conversation — channels with direct revenue consequences and executive visibility. A user complaint often arrives through a support ticket, an app store review, or a research session — channels that are easier for an organization to deprioritize, even when the underlying signal is just as important.

This creates a systematic bias: absent deliberate correction, product roadmaps tend to over-index on customer requests relative to user needs, simply because customer requests are louder and better connected to revenue conversations, not because they are objectively more important. Recognizing this bias explicitly — and building processes that give user signal equal structural weight (dedicated user research, usage analytics, in-product feedback loops) — is part of the PM's job of guarding against a distortion the org chart naturally produces.

Common Mistakes to Avoid

Assuming a paying customer's request reflects what end users actually want

This assumes alignment without checking it. A request from a paying customer (particularly in enterprise software) reflects that customer's priorities — which may be procurement-driven, cost-driven, or politically driven within their own organization — and is not automatically a proxy for what the people who will actually use the feature every day want or need.

Treating customer-facing conversations as a substitute for user research

Sales and account management conversations are a real and valuable signal, but they are customer signal, not user signal, whenever the two differ. A PM relying exclusively on customer-facing conversations for product direction, in a product where users and customers diverge, is building on half the picture — often the half that is easier to access, not the half that is most important.

Treating "the user" as a single homogeneous person

Even within "users," there are often multiple distinct roles with different needs — an admin user versus an end-user of the same enterprise tool, for instance. Lumping all of these into one undifferentiated "the user" hides exactly the kind of conflict this lesson is about to teach you to look for.

Assuming misalignment means the customer is "wrong.

The correct response to discovering user-customer divergence is not automatically to side with the user. A customer's business concerns (security compliance, cost control, contractual obligations) are often entirely legitimate and can be things the user themselves would care about if they had visibility into them. The goal is not "users always win" — it is to make the trade-off explicit and deliberate, rather than accidental.

Assuming this distinction is unique to B2B or enterprise products

Ad-supported consumer products, freemium products, and products built for dependents (children, pets, elderly relatives under someone else's account) all have the exact same structural issue, often in a more extreme form, because the user in these cases frequently has no direct commercial relationship with the company at all.

Users vs. Customers