Module 1 · Foundations

04

Product Sense — and How to Build It

The mysterious judgment senior PMs seem to have, what it actually consists of, and the practices that develop it.

9 pages4.1K words20 min read

The Hardest Skill to Define and the Most Important One to Have

If you sit in enough product reviews, you start to notice a pattern. A junior PM presents an idea. The senior PM in the room asks two or three questions. The questions are simple, almost obvious in hindsight, and they reveal a flaw in the idea that nobody else had spotted. Sometimes they reveal an opportunity that nobody else had seen. The junior PM goes back to redo the work. Six months later, the same junior PM is asking the same kinds of questions of someone newer. Something has been transmitted, but nobody can quite name it.

That something is product sense. It is the most discussed and least explained quality in product management. People recognise it when they see it but struggle to define it precisely. PMs who have it get promoted faster, get given the harder problems, and get listened to in rooms where authority is informal. PMs who lack it can do all the frameworks correctly and still produce work that feels wrong, in ways that are difficult to articulate.

We have been thinking about this skill for two decades and have come to believe it is teachable, but only through deliberate practice on a long timescale. This article is our attempt to define product sense precisely, break it into components you can work on, and give you a practical regimen for developing it.

Why It Is Called a Sense

The choice of word matters. Sense, as in the sense of smell or the sense of direction, implies something that operates faster than conscious thought and is informed by experience the user often cannot fully articulate. Senior PMs rarely sit down and run a twenty-step framework before reacting to a product idea. They look at it for fifteen seconds and have a strong reaction, often correct, that they then have to translate into language for the rest of the team. The translation is the hard part, and it is often where junior PMs get frustrated. Why does this feel wrong? The senior PM may spend ten minutes constructing the explanation after the fact. But the reaction itself was instant. This is what experts in any domain look like, whether they are doctors, designers, chefs, or chess players. The expertise is compressed into pattern matching, and the explanation is reverse-engineered.

Understanding product sense as a sense, rather than as a body of explicit knowledge, has practical implications. You cannot read your way to it. You cannot watch a course on it. You can only acquire it by exposing yourself to many products, customers, and decisions, with reflection that turns each exposure into a stored pattern. The good news is that the input is plentiful. The hard part is doing the reflection consistently enough to convert exposure into intuition.

The Four Components of Product Sense

When we have tried to break product sense into pieces we can teach, four components keep recurring. They are not independent. They feed each other. But it is useful to be able to identify which component you are weaker in, because the development practices for each are different.

1. Customer Empathy

The deepest part of product sense is the ability to mentally simulate what it is like to be your user. Not what you assume they want, but what they actually feel when they encounter the product, including frustrations they would not voice, delights they would not describe, and contexts that shape their behaviour in ways they cannot see themselves.

PMs with strong customer empathy can sit in a meeting and quickly tell whether a proposed feature would land or fall flat with the actual user, because they have done so much real-world observation that the user lives, in some compressed form, inside their head. They have a rich internal model of what users do rather than what users say they do , and they can predict the gap between those two.

2. Pattern Recognition Across Products

The second component is the ability to recognise patterns across many different products and product categories. A senior PM working in healthcare software has often spent serious time using consumer social apps, enterprise spreadsheets, fintech tools, and developer platforms, and has internalised what works and what does not in each. When they see a new design, their brain rapidly compares it to dozens of similar designs they have used and noticed across their career.

This is why senior PMs often have strong opinions about products in categories they do not work in. The pattern library is general. The junior PM's pattern library is small, mostly populated by the few products they use heavily. Building this library is a deliberate exercise that we will discuss later in this article.

3. Judgment About Trade-offs

Product decisions almost always involve trade-offs. Speed versus quality. Simplicity versus power. Customisation versus consistency. Personal versus private. Senior PMs have built up, through repetition and observation of consequences, a sense of which trade-offs are tolerable in which contexts and which are not. This is the component that takes longest to develop, because trade-off judgment requires you to have seen both sides of the trade-off play out in real products. You have to have been present when a team chose speed and shipped something fragile, and present six months later when the fragility came home to roost. You have to have seen the team that chose simplicity and watched the user feedback when power users felt constrained. Each cycle teaches you a little more about which trade-off was right for which situation.

4. Aesthetic Sensibility (Taste)

Taste is the part of product sense that everyone is most reluctant to discuss because it sounds elitist. But it is real. Some products are more pleasant to use than others, even when they have similar functionality and similar performance. The difference is taste, expressed in micro-decisions about timing, language, density, and feel that compound into an overall quality of experience.

PMs with taste notice when a button label is slightly off in tone, when an animation is a hundred milliseconds too slow, when a flow asks a user one question too many. PMs without taste do not notice these things and ship products that work but feel cheap. The difference is often invisible at the feature level and obvious at the product level. Taste is the component most consciously developed by spending time with products that have it, paying close attention to why they feel good.

How Great PMs Evaluate an Idea

Watch a senior PM react to a new feature idea and you will see them running through a sequence of mental checks in seconds. Slowed down and made explicit, the sequence looks something like this:

1. What problem does this solve, and for whom? If they cannot instantly translate the

feature into a problem and a user, the idea is suspicious. Most weak ideas are solutions in search of a problem.

2. How big is the problem, and how often does it occur? They are doing a quick mental

size-up: is this an everyday irritation, a rare frustration, or a one-time setup pain? Frequency matters because it shapes how much value a fix actually creates.

  1. 3. What do users do today instead? If the user has a workaround they are reasonably happy with, the bar for adopting a new solution is high. If they have a painful workaround, the bar is lower. If they have no workaround, the question is why, because that may reveal that the problem is not as common as it sounds.

4. Is the proposed solution actually better than the alternatives? Not just better than

nothing, but better than other things the team could build with the same effort.

  1. 5. What are the second-order effects? What does this change about how users will interact with the rest of the product? About how the team will operate? About how the business model behaves? Junior PMs often miss this entirely. Senior PMs spend most of their evaluation time here.
  2. 6. What would have to be true for this to fail? Not as a pessimistic exercise, but as a sanity check. Identifying the failure modes early means you can test them cheaply.

Most senior PMs are running this checklist subconsciously in the first thirty seconds of hearing a new idea. They will not say let me review my checklist . They will simply ask the most pointed two or three questions in the sequence, often the ones that other people missed. That, externally, is what product sense looks like. Internally, it is just disciplined evaluation done quickly.

Mental Models That Build Product Sense

Some mental models recur often enough among great PMs that they are worth memorising. They will not give you product sense by themselves, but they sharpen the kinds of evaluation you do, and over time they shape your intuitions.

The Hair-on-Fire Test

When evaluating a problem, ask whether the user has their hair on fire about it. If yes, you can probably ship a flawed solution and they will still adopt it because anything is better than the burning. If no, your solution has to be excellent, because the user is not very motivated to switch from their current workaround. Most ideas aim at problems where nobody's hair is on fire, which is why most products under-perform expectations.

The Onion Layers of a Problem

When a user reports a problem, treat it as the outer layer of an onion. The first description is rarely the real problem. Peel it by asking why the user wanted to do that thing in the first place, and then why they wanted that, until you reach a layer where the answer is something fundamental about their goal or context. The real product opportunity is usually two or three layers in, not at the surface.

The Substitute Test

For any new product or feature, identify what users will mentally compare it to. They will not evaluate your work against your stated vision. They will compare it to the closest thing they already use. If your new note-taking feature is mentally compared by users to the notes app on their phone, that comparison is the bar you have to clear, regardless of how you described the feature internally.

The Unsexy Win Principle

The biggest improvements in product experience often come from boring, unsexy fixes that nobody wants to demo. Faster page loads. Clearer error messages. One fewer click. PMs with strong product sense disproportionately value these wins because they know the compounding effect across millions of interactions. PMs with weak product sense chase splashy features because those are easier to show off.

“A great PM can argue strongly for a project whose biggest visible change is removing a feature. A weak PM cannot, because removing features feels like the opposite of progress. Both are wrong sometimes; but the great PM is at least playing the right game.”

How to Develop Product Sense Deliberately

Most PMs hope product sense will arrive on its own through job experience. It will, slowly, but the difference between developing it deliberately and waiting for it to accumulate is roughly five years of career time. Here are the practices that compress the timeline.

Practice One: The Daily Product Audit

Pick one product you use every day and one you have never used before. For ten minutes, look at the daily product critically. Notice three things you find frustrating, awkward, or surprising. Write them down with a one-sentence theory of why the team built it that way. Then do the same with the new product. Build the habit. Within a year, you will have stored hundreds of patterns and developed reflexive critical observation.

Practice Two: The Weekly Teardown

Once a week, take a competitor's product or a product in an adjacent category. Spend an hour using it as a real user would. Then write a one-page teardown: what is it trying to accomplish, what works well, what fails, what trade-offs the team made and why. Save these. Return to them when working on similar problems in your own product. The library you build over a year is more valuable than any course.

Practice Three: The Decision Journal

When you make a meaningful product decision, write down what you decided, what you predicted would happen, and what your confidence was. Three months later, look at what actually happened. Where you were right, ask why. Where you were wrong, ask what you missed. This is how trade-off judgment becomes calibrated. Without it, you will accumulate experience without learning, which is the most common failure mode of mid-career PMs.

Practice Four: The Customer Conversation Diet

Customer empathy comes from volume. Set a target of five customer conversations per month, minimum, even when you do not need them for any specific project. Ask open-ended questions about how their work or life is going. Listen for the small frustrations they would not write to support about. Within two years, you will have internalised so many user contexts that your intuition for what lands and what falls flat becomes much sharper than any survey could give you.

Practice Five: The Diverse Product Diet

Use products outside your category. If you build B2B software, spend time with consumer apps. If you build consumer apps, spend time with technical developer tools. If you work in fintech, try creative tools. The cross-pollination of patterns across categories is one of the most reliable sources of insight. Most innovative design moves are an idea borrowed from one category and applied in another.

Common Signs of Weak Product Sense

If you cannot tell whether your product sense is strong or weak, look for these symptoms in your work. Each is a fixable signal that one or more components is underdeveloped.

You evaluate ideas mostly on their stated benefits

If you accept that a feature is valuable because the proposer described it as valuable, you are not running the evaluation checklist. You are accepting the proposer's framing. PMs with strong product sense always reframe an idea before accepting or rejecting it, because the original framing is rarely the most useful one.

You frequently discover obvious flaws after launch

Some of these are unavoidable. But if it happens often, it is a sign that your evaluation is not surfacing second-order effects early enough. The fix is usually more deliberate critique sessions before commitment, including a deliberate exercise of asking what would have to be true for the work to fail.

You over-rely on data to make decisions

Data is essential, but it is a complement to judgment, not a replacement for it. PMs with weak product sense use data as a shield: the data says we should ship this . PMs with strong product sense use data as evidence within a broader judgment that they are willing to defend on its own terms. If you cannot make decisions when the data is ambiguous, you are leaning on data to compensate for sense that has not yet been built.

You are surprised by user behaviour

Some surprises are inevitable; that is why we test. But chronic surprise about how users adopt or reject features is a sign that your customer empathy component is weak. The fix is the customer conversation diet described above, and especially the discipline of watching users use the product, not just hearing them describe what they want.

You produce work that is technically correct but feels off

If feedback you regularly get is along the lines of this is fine but something is missing or I cannot articulate what is wrong , the issue is usually taste. The fix is conscious study of products that have it. Use them slowly. Notice what they do that lesser products do not. Try to articulate the difference in writing. Over months, your taste catches up.

Two Common Misconceptions

Misconception One: Product Sense Is Innate

It is not. Some PMs start with stronger building blocks (more consumer-product exposure, more design-attentive parents, more writing practice), but the actual sense is built. We have watched PMs with no apparent natural feel for product become excellent at it through five years of deliberate practice. We have watched PMs with strong starting talent stagnate when they relied on it. Innate ability is a head start, not a destiny.

Misconception Two: Product Sense Is the Same Across Domains

It is not, fully. A PM with strong product sense in consumer apps will need to develop additional sense if they move to enterprise software, because the user behaviours, decision dynamics, and trade-off priorities are different. The components transfer but the specific patterns do not. PMs who acknowledge this stay humble when changing domains. PMs who do not get caught flat-footed.

A Self-Test for Your Current Sense

Take a feature your team is currently building. Without looking at the spec or any documents, write down for fifteen minutes:

  • The user problem in one sentence, expressed in the user's words, not yours.
  • How big the problem is for the user, and how often it occurs in their workflow.
  • What the user does today instead, and how painful that is on a scale of one to ten.
  • Three ways the proposed feature could fail to land with the user, each plausible.
  • Two second-order effects on other parts of the product if the feature succeeds.
  • One alternative the team should have considered and either consciously rejected or built into the design.

If you can fill all six items confidently, your product sense for this feature is in good shape. If you struggle with any of them, you have located the part of your evaluation that needs more work. Run this exercise on every meaningful feature in your portfolio. Within six months, the gaps will narrow.

A Final Word

Product sense is the most important skill in product management and the one most resistant to shortcuts. It is built from many small, repeated acts of attention, reflection, and customer exposure. There are no four-week courses that produce it. There are no certifications. There is only the practice, sustained over years, with feedback loops to ensure your intuitions get calibrated rather than just confident.

If we could give one suggestion to a PM in their first three years, it would be this: care about product sense more than tools, more than frameworks, more than titles. Spend disproportionate time on the practices that build it. The PMs who do this become the senior PMs who, fifteen years later, ask the two simple questions in the review meeting that nobody else thought to ask, and watch the room go quiet.

Key Takeaways

  • Product sense is trained intuition, built from thousands of small observations and reflections, not innate talent.
  • It has four components: customer empathy, pattern recognition, trade-off judgment, and aesthetic taste. Each can be developed separately.
  • Senior PMs evaluate ideas through a fast subconscious checklist that junior PMs can adopt explicitly until it becomes second nature.
  • Five practices accelerate development: daily product audits, weekly teardowns, decision journals, customer conversations, and a diverse product diet.
  • Common signs of weak product sense include accepting framings unchallenged, frequent post-launch surprises, and an over-reliance on data to substitute for judgment.
↑ Back to the index