Reading user/customer truth — who you’re really building for.
what we mean by this
User is the most humbling competency in Ken. Everyone thinks they know their customer. Most teams have a persona deck, a few interview summaries, a stack of NPS comments, and a Slack channel full of feature requests from the three enterprise logos that got the CEO's ear last quarter. They call this "customer knowledge." It isn't.
What User specifically measures is the ability to cut through the noise of customer representation and read who is actually paying, staying, and growing. Not who your loudest customer is. Not who your founder imagined when they first drew the product on a napkin. Not who your sales deck says you serve. The customer who actually exists in the data — their behavior, not their stated preferences; their retention patterns, not their wishlist; their usage shape, not their job title.
The wrong beginner take: "I just need more user research." More interviews do not solve User. In fact, more interviews can make it worse — they produce more stated preferences, more articulate power users with detailed opinions, more representation of whoever has the time and willingness to talk to you. User isn't about quantity of signal. It's about the judgment to read which signal is real.
What no other competency tests quite like this: the capacity to hold a structural read of demand — who across the whole installed base is actually generating value and sticking — against the local pressure of whoever is loudest in the room. Signal measures whether you read conflicting evidence correctly in general. User is the specific case where the hardest evidence to discount is a customer who is present, articulate, and emotionally compelling, and the most important evidence is the quiet shape of 10,000 sessions you've never met.
citation
PL Standard v3.1 · Ken · User
Markdown form: [PL Standard v3.1 · Ken · User](https://pragmaticleaders.io/framework/competencies/user)
The difficulty is that secondary customers — the ones your company keeps calling "not core" — sometimes account for the majority of durable revenue. And when they do, the User competency is what lets you see that before you spend another year building for a segment that was never going to generate the growth you needed.
the four levels
Anchored at every rung. The blockquote at each level is panel-authored and pulled live from the rubric — edit anchors via the panel tooling and they appear here.
L1Developing
builds for the loudest or most visible user segment without checking who actually uses the product or what they actually do.
you'll see this when…
The PM builds for whoever asked last — the most recent customer complaint, the loudest Slack thread, the feature request that came through an exec.
They treat stated preferences as behavior: a customer says "I would use X" and the PM puts X in the next sprint without asking whether anyone has ever used analogous functionality.
Their "customer insight" is a retelling of a single interview, with the caveats stripped out — "our customers want Y" based on two conversations with early adopters who may not resemble the actual ICP.
common failure mode: The PM confuses access to customers with understanding of customers — they've talked to many people, but the picture hasn't updated.
L2Competent
conducts user interviews and maps patterns to a core user profile, but defaults to familiar user types and needs prompting to question assumptions when the problem space shifts.
you'll see this when…
The PM triangulates across a few sources — interviews, usage data, NPS — but the synthesis is still additive rather than structural: they list what they heard, they don't distill who they're actually serving.
They can identify their "primary persona" but struggle to say what percentage of current revenue comes from customers who match it.
They recognize when a customer request is edge-case vs. mainstream, but they reach this conclusion via gut rather than a systematic read of the data — sometimes they're right, sometimes they're not, and they can't always explain the difference afterward.
common failure mode: The PM reads customers correctly in isolation — individual interviews, individual tickets — but can't aggregate those reads into a coherent structural picture of demand.
L3Proficient
reframes who the actual user is when the team has assumed the wrong person, then tests that reframe against behavioral evidence before committing.
you'll see this when…
The PM can name the real shape of demand — who uses the product deeply, who churns and why, what the actual ICP looks like when you read the retention data versus the sales deck.
They actively notice when the loudest customer voice diverges from the behavioral data, and they treat that divergence as a signal rather than a discrepancy to explain away.
They design customer-listening systems that go beyond interviews: usage heatmaps, cohort retention by segment, support ticket taxonomy — and they read those systems regularly enough that the picture stays current.
common failure mode: The PM reads customer truth well for the product as it exists today, but anchors too hard on current users when adjacent segments represent the real growth vector — proficiency can shade into customer conservatism.
L4Expert
reframes who the real user is when the team has drifted; that reframe changes what gets built.
you'll see this when…
The PM can hold two pictures simultaneously: who the current customer is (behavioral, retention-weighted) and who the customer could become if the product moved — and they can make a credible argument for when to lead the customer vs. follow them.
They treat persona frameworks as working hypotheses, not facts — when data contradicts a persona, they update the persona, not the data interpretation.
They can walk an executive through the difference between the company's stated ICP and the actual revenue-generating segment, and do it in a way that moves strategy rather than just making the point.
common failure mode: ICP fundamentalism — the expert has done the work of identifying the real customer, and now they over-apply that read, refusing to serve adjacent segments that don't match the definition even when those segments represent the real next growth curve. The L4 trap is letting a hard-won ICP clarity calcify into a cage.
how to develop it
The most leveraged move is building a regular habit of reading your retention data by segment — not aggregated — and asking "who is actually staying?" once a month. Most PMs look at aggregate retention. Aggregate retention hides the segment shape. A product with 70% 12-month retention can have one cohort retaining at 90% and another churning at 60%, and if you don't split the view you'll build for the wrong one.
Read. /manual/core-skills/discovery/customer-interviews is table stakes, but don't stop there — the discipline is in what you do after the interviews. /manual/core-skills/discovery/jobs-to-be-done is the structural frame that keeps interview insight from collapsing into a preference list: JTBD asks what job customers are actually hiring the product to do, which almost always diverges from what customers say they want. /manual/core-skills/discovery/user-development-and-buyer-research and /manual/product-sense/user-truth are the two most direct reads in the Manual for this competency.
Practice. Scenarios that stress-test User are the ones where stated preference and behavioral data point in opposite directions. Look for scenarios where a vocal segment is asking for something, and usage data on the analogous feature tells a different story. If no specific User scenario exists in your track yet, the type you want is: a customer is telling you one thing; the data is telling you another — what's true, and how do you decide?
Write. Draft a Brief response that includes an explicit segment analysis — not just "our users" but a structured read of which users are generating which outcomes. Then notice whether your recommendation would change if you weighted by retention rather than by count. If it would, say so — and explain why you're weighting one way over the other.
Coach yourself. Before your next roadmap review, pull the retention data for your last two major features. Ask: did the customers who asked loudest for this feature retain at higher rates? If not — why do you think that is? One paragraph, monthly.
how to spot it in others
In planning conversations: when they talk about customers, do they say "our customers want" (aggregate, stated) or do they differentiate — power users versus occasional users, retained cohorts versus churning ones, the segment that drives LTV versus the segment that drives volume?
In feature prioritization: when a customer escalation comes in, can they quickly situate that customer in the broader landscape — "this is a real pattern among mid-market accounts" versus "this is an outlier; we should note it but not build for it" — without needing to run a three-week discovery sprint?
In post-mortems: when a feature underperforms, do they read which customers didn't adopt it, and does that read change their hypothesis about who they're building for?
In customer-facing conversations: are they listening for jobs and friction, or collecting opinions? The PM who is strong on User asks "walk me through the last time you needed to do this" not "what would you change?"
In persona documents: are the personas dated? Do they include a "we updated this on [date] because [data]" — or are they the same deck from eighteen months ago, treated as current truth?
three failure modes we see often
The survey fiction. The PM builds listening infrastructure — NPS surveys, satisfaction scores, periodic interviews — and reports the outputs as customer truth. The problem is that survey responses are stated preferences, and stated preferences are systematically different from behavior. Customers say they want more features; they churn because onboarding was too long. Customers rate the product 9/10 on satisfaction; they stop using it after thirty days. The PM who reads surveys as truth ends up optimizing for what customers say rather than what would make them stay. The tell is when "customers told us they wanted X" is used as a sufficient justification for building X, without asking whether customers who got analogous features in the past actually retained at higher rates.
The founder-self user. The PM builds for an idealized version of themselves — or of the founder — rather than for the customer the product has actually attracted. This is most common in early-stage products where the first users were the founding team's peers, and the product was shaped for that persona. As the product grows, the actual customer base often looks different from the founding cohort, but the roadmap stays anchored to the original self-image. The cost is a product that gets progressively less relevant to the people actually using it. The tell is when the PM says "I don't use this product that way" as a disqualifying response to customer feedback, rather than as one data point to weigh.
The persona deck calcification. The team built real personas two years ago, based on real research. The personas were accurate at the time. They're now treated as permanent facts, updated only when a new research initiative gets funded — which means they're updated roughly never. Meanwhile, the customer base has evolved: a new segment found the product through a different channel, a previously secondary use case became primary after a feature shipped, pricing changes attracted a different buyer profile. The PM reads current customers through a stale lens, which produces a systematic blind spot for whoever the product has become attractive to in the intervening period. The fix isn't more research — it's building a lightweight, continuous-signal habit so the picture stays current without requiring a formal project to update it.
Room is reading the people in the building: colleagues, stakeholders, the exec in the room — their actual intent, the subtext under what they said, what the silence meant. User is reading the customer outside the building: who they really are, what they really do, what actually makes them stay. Both are reading skill; they operate on different populations. You can be strong on Room (exceptional at reading colleagues and navigating internal dynamics) and weak on User (poor at reading the real shape of external demand). The confusion is understandable — both involve listening carefully and reading beneath the surface — but the data sources, the time horizons, and the social pressures are completely different. Room is about what's true in the next meeting. User is about what's true in the product's market.
Signal is the general skill of reading conflicting evidence and reaching a call. User is a specific domain of that skill — the evidence is customer data, and the specific distortion is that the most emotionally present evidence (the customer in the room, the escalation from sales, the angry power user) systematically over-represents certain types of customers. A strong Signal reader can still fail at User if they don't understand why customer signal is specifically prone to selection bias. User adds the domain knowledge: you need to know not just how to weigh conflicting evidence in general, but how the particular way customer evidence gets collected creates systematic blind spots you have to correct for.
what good looks like in the wild
A product team at a B2B SaaS company had spent eighteen months building for what they called their "core" segment: mid-sized professional services firms, 50–200 employees, mostly using the product for project management. The sales team loved this segment. The founders loved this segment — these were the customers who showed up to webinars, gave testimonials, and could articulate the product's value clearly. The roadmap was built almost entirely around their requests.
The PM on the platform team was doing a routine cohort analysis for a quarterly planning meeting when she noticed something. The retention curve for one segment she'd previously labelled "secondary" — smaller independent operators, solo practitioners and two-person shops — looked completely different from every other cohort. Their 12-month retention was 84%, versus 61% for the mid-market firms. And their expansion revenue per account, while smaller in absolute terms, was more consistent — they renewed at higher rates and added seats in a more predictable pattern.
She dug in. The solo-practitioner segment wasn't asking for features. They weren't showing up to webinars. They weren't complaining to sales. They were just quietly using the product, paying, and staying. The mid-market firms — the "core" segment — were actually churning at nearly twice the rate, despite generating louder signal and a more articulate product vision.
She brought this to the next planning cycle not as a research report but as a business argument: the company's stated ICP was generating 39% of revenue with 61% retention. The "secondary" segment was generating 41% of revenue with 84% retention — and the company had spent almost no marketing or product attention on them. The product was effectively discovering its own ICP in the data, and the roadmap was pointed in the opposite direction.
The repoint wasn't comfortable. The mid-market segment had champions inside the company — the sales team, the founders, the CEO's relationship with a few named logos. But the PM had done the work: the picture was clear, the evidence was behavioral not stated, and the business case was precise. The next quarter's roadmap shifted. Within two quarters, net revenue retention improved by eleven points — not because the product got better in a dramatic way, but because the team stopped building features for customers who were going to churn anyway and started building for the ones who had already decided to stay.
“
That's User at its best — the read that's invisible until someone does it, and obvious once they have.