The Question Most Teams Cannot Answer
Walk into any product team and ask a simple question: who is your user? The answers you get will reveal more than the team intends. Some teams describe a vague segment ("small businesses"). Some recite a persona document last updated three years ago. Some describe themselves ("someone like me, but with less time"). A rare few describe a specific person whose behaviour they have watched, whose context they understand, and whose words they can quote.
The depth of the answer is one of the most reliable indicators of product team health we have found. Teams with shallow user understanding produce features built on assumption, hit launch metrics that disappoint, and slowly become disconnected from the people they serve. Teams with deep understanding make sharper decisions, adjust faster to changes in the market, and produce products with the unmistakable feel of having been made for someone specific.
This article is about how to build that depth. It is not about research methods in detail (we will cover specific techniques in later articles on customer interviews, surveys, usability testing, and analytics). It is about the discipline of user understanding as a continuous practice that runs alongside everything else a PM does.
What "Understanding" Actually Means
Understanding users is more than knowing facts about them. It involves several layers, each deeper than the last.
Surface Layer: Demographics and Behaviour
Who they are by category. Job title, company size, age range, geography, frequency of use. This is the easiest layer to capture, the most common content of persona documents, and the least useful by itself. It tells you what bucket they fall into but not how they think.
Middle Layer: Goals and Context
What they are trying to accomplish, in their own framing, and what conditions shape how they go about it. The marketing manager at a fifty-person company is not just trying to do marketing ; she is trying to prove the budget was worth it to a sceptical CFO who reviews her numbers monthly. That context shapes everything she does.
Deep Layer: Behaviour vs. Stated Preference
What they actually do, as opposed to what they say they do. The gap is usually significant. Users describe themselves as thoughtful planners but actually decide in the moment. They say they want every feature configurable but actually use defaults ninety-five percent of the time. They claim to compare options carefully but actually pick the first acceptable choice. The deep layer is what distinguishes useful research from misleading research.
Deepest Layer: Emotional and Social Drivers
What the user is feeling and what social dynamics shape their decisions. The marketing manager wants to look competent in front of her boss. The engineer wants to feel respected by his peers. The small business owner wants to feel like she is in control. These drivers rarely show up in user research unless deliberately probed for, and they often shape adoption more than functional needs.
Real user understanding spans all four layers. Most teams operate on the first two and assume they have the rest. The PMs who do the work to reach the deeper layers produce products that feel different, because their understanding of the user is different.
Behavioural Truth vs. Stated Preference
The single most important principle of user research is that what users say and what users do are different things. This sounds obvious. In practice, almost every research mistake we have watched comes from forgetting it.
When asked, users describe themselves as more rational, more patient, more thoughtful, and more independent than they actually are. They tell you they would use a feature they will ignore. They tell you they would pay for something they will abandon when the trial ends. They predict their future behaviour with confidence and are wrong about it most of the time. None of this is a moral failing on their part; it is how human cognition works.
The implication for product work is direct: weight observed behaviour over stated preference, always. If a user says I would definitely use this but their behaviour with similar products has been inconsistent, trust the behaviour. If a user tells you a feature is unimportant but the analytics show they use it daily, trust the analytics. The discipline is to treat user words as data about how users describe themselves, not as ground truth about what they will do.
Methods for Building Understanding
Different methods reveal different layers. A complete user understanding practice uses several in combination, not just the easiest one.
Customer Conversations
The foundation. Done well, conversations reveal goals, context, and emotional drivers that no other method captures. Done poorly, they capture stated preferences and miss the rest. The discipline is to ask about specific past behaviour, not hypothetical future behaviour, and to listen for the emotional subtext beneath the functional answers.
Direct Observation
Watching users work, in their actual context, is the most honest research method. They reveal workarounds they would never describe, frustrations they have stopped noticing, and rituals that shape their day. One hour of observation is often worth ten hours of interviews. The challenge is access; many users do not invite vendors into their workflow easily.
Behavioural Analytics
Quantitative data about what users actually do in your product. Where they get stuck, what features they use, when they abandon. Analytics reveals patterns at scale that interviews can miss. It also misses the why behind behaviour, which interviews provide. The two complement each other.
Support Tickets and Sales Calls
An underused source of insight. Support tickets reveal frustrations users felt strongly enough to complain about. Sales calls reveal concerns users felt strongly enough to raise before purchase. Reading a hundred recent support tickets is often more revealing than running a survey, and is free.
Surveys
Useful for measuring at scale (how many users feel this way) and for tracking change over time. Less useful for discovering why or for predicting behaviour. Surveys should follow other methods, not lead them. The most common research mistake we see is leading with surveys before any qualitative grounding.
Usability Testing
Watching users attempt to complete tasks with a prototype or live product. The fastest way to surface design problems. Best for evaluating specific solutions, less useful for discovering underlying problems. Five sessions usually surface most major issues; running thirty is rarely worth it.
Method Best For Avoid For
Customer conversations Goals, context, emotional drivers Predicting future behaviour
Direct observation Workarounds, real workflow, friction Quick or scalable insight
Behavioural analytics What at scale; usage patterns Why behind behaviour
Support tickets Real frustrations users acted on Representative samples; biased
to complainers
Surveys Measuring known things at scale Discovery; predicting behaviour
Usability testing Evaluating specific designs Discovering underlying problems
Building a Continuous Practice
The mistake most teams make is treating user research as a discrete activity that happens at the start of a project and ends when the kickoff happens. Real user understanding is continuous. It runs alongside every feature, every decision, every quarter. It compounds over years.
Weekly Cadence
Block time every week for some form of direct user contact. The specific activity varies (interviews one week, support ticket review another, prototype testing a third), but the contact happens weekly. Within a year, you have done fifty user touches. Within five years, two hundred and fifty. The accumulation is the point.
Document What You Learn
After each user contact, write a short note: who you talked to, what you learned, what surprised you, what assumptions it challenged. Save these. Read them back periodically. Patterns emerge across notes that no single conversation surfaces. The compounding insight is more valuable than any single research report.
Share What You Learn
Tell the team what users said and did this week, in your writing and your meetings. The team's collective understanding of the user grows when the PM acts as a transmitter of fresh user signal. Without this, only the PM gets the benefit of the research, and the team builds on stale assumptions.
Bring Users Into Decisions
When making meaningful product decisions, name the specific user reality that informs the choice. We are choosing this approach because [specific user we recently spoke to] described [specific situation], which suggests [specific 'implication]. This trains the team to make user-grounded decisions and reinforces that user understanding is operational, not ceremonial.
The Problem With Personas
Personas have been the standard tool for representing user understanding for decades. We have used them. We have written them. We are skeptical of them, and the skepticism has grown over time. Most personas we encounter are doing more harm than good.
Why Personas Fail
The typical persona document is created in a workshop, written in a standardised template, and printed on the wall. Meet Sarah, a 35-year-old marketing manager at a mid-sized SaaS company. The persona becomes a static reference, a way to feel like the team is user-centred without actually doing the ongoing user work.
The specific failures: personas freeze a snapshot of user understanding at one point in time. They reduce a complex user to a small set of attributes that may not be the right ones. They become a substitute for ongoing research rather than a supplement. Teams stop talking to actual users because they have personas. The persona becomes the user in the team's mind, and the real user becomes irrelevant.
A Better Alternative
Instead of static personas, maintain a small set of recent, specific examples. Recent users we talked to: a list of five to ten real people, with names (or pseudonyms), real quotes, real contexts, and real situations. Update the list every quarter. Reference specific examples in decisions. The specificity is what makes them useful; the personas' abstraction is what makes them useless.
If you must have personas, treat them as summaries of patterns across many specific users, refreshed at least annually, with active links to the recent specific examples that exemplify each pattern. Without that grounding, the persona becomes a fiction the team mistakes for understanding.
Common Mistakes in User Understanding
Mistake One: Treating Power Users as Representative
The users who give the most feedback are usually the users who use the product the most. Their needs are not representative of the broader user base. Optimising for power users' requests can produce a product that becomes too complex for new users, constraining growth. Every feedback channel needs to be weighted by how representative the source is.
Mistake Two: Listening Only to People Who Speak Up
Most users do not give feedback. They simply leave when frustrated, or fail to convert in the first place. Their voices are absent from feedback channels and surveys answered by current users. The most important user insight often comes from the users you no longer have, who are hardest to reach.
Mistake Three: Confirmation Bias
Researchers find what they look for. If you go in with a hypothesis, you tend to confirm it, even unconsciously. The fix is to design research that could produce surprising results, ask open-ended questions, and pay particular attention to data that contradicts what you expected. The contradictions are usually where the most valuable insight is.
Mistake Four: Confusing Internal Stakeholders With Users
Sales tells you what users want. Support tells you what users want. Customer success tells you what users want. None of these is the user, and each has its own filter. Internal stakeholders are useful sources of signal but not substitutes for direct user contact. Many product mistakes come from PMs who only hear about users second-hand.
Mistake Five: Outsourcing the Understanding
Some teams have a researcher who does the user work and delivers reports to the PM. The reports are read; the understanding is shallow because reading is not the same as doing. Researchers are essential collaborators, but PMs cannot outsource the building of their own user understanding. The PM who has not personally talked to users in months is operating with delegated knowledge that is qualitatively different from first-hand understanding.
How User Understanding Compounds Over a Career
User understanding is the kind of skill that compounds. The first hundred users you talk to teach you how to listen. The next hundred build pattern recognition across user types. The next thousand let you anticipate what a user will say before they say it. By the time you have spoken to several thousand users across multiple products and segments, you have an intuition that no specific research project can produce, because the pattern library has become rich enough to handle novel situations.
This is why senior PMs can often answer questions about user behaviour without running new research: they are matching the current question against patterns from their stored library. Not always correctly; the intuition still has to be calibrated with fresh data. But the speed and precision of their judgment comes from accumulated user contact, not from being smarter than other PMs.
If you are early in your career, this is the practice that will matter most for the next twenty years. The compounding rate is high. The required investment is small per week. The penalty for skipping it is invisible at the start and enormous by the tenth year of your career, when peers who built the practice are operating at a level you can no longer reach by working harder.
A Final Word
User understanding is the foundation of every other product skill. Strategy without it produces plans nobody wants to follow. Roadmaps without it produce features nobody asked for. Pricing without it produces structures nobody is willing to pay. The most common cause of product failure is teams who thought they understood their users and did not.
Build the practice. Talk to users every week. Watch them work. Read what they write. Watch what they do. Document what you learn. Share it with your team. Update your assumptions when the data shifts. Do this for years, not months. The depth of understanding you accumulate is what makes the difference between competent product work and great product work, and there is no shortcut to producing it.
Key Takeaways
- Understanding has four layers: demographics, goals and context, behaviour vs stated preference, and emotional and social drivers. Most teams operate on only the first two.
- Stated preferences and observed behaviour diverge sharply. Always weight what users do over what they say they would do.
- Build a continuous practice: weekly user contact, documented learning, shared findings, and user-grounded decisions. The compounding effect over years is enormous.
- Personas are usually counterproductive because they replace ongoing research with static reference. Specific recent examples are more useful.
- User understanding is one of the most career-compounding skills in product management. Start the practice early; the cost is small per week and the long-term advantage is large.