Product sense for product managers
Product sense is the judgment I use to understand a customer problem, see the product tradeoffs around it, and choose a useful next step when the evidence is incomplete. I do not treat it as intuition that is magically correct. For me, product sense is a set of habits I can practice: noticing the context, clarifying the job, comparing options, explaining tradeoffs, and learning from what happens next.
It matters because product decisions rarely arrive with complete information. I may need to decide what to improve, which audience to serve first, how much complexity to introduce, or what not to build. A framework can structure the conversation, but judgment is still needed to interpret the situation.
Start with the person and the job
When someone presents a feature request, I first ask what they are trying to accomplish. I want to understand the moment in the workflow, the trigger, the desired result, and what they do today. “Add filters” might mean people cannot find the right item, do not trust the current sorting, or need to share a particular view with a teammate. The same request can hide different problems.
I pay attention to constraints and emotional context too. A workflow used occasionally under time pressure may need clarity more than breadth. A configuration used by experts may justify flexibility that would overwhelm a new user. I avoid assuming that my own preferred workflow represents the people who use the product.
I treat customer language as evidence about a problem, not as a complete solution specification. I ask for a recent example and what happened before and after it. Concrete episodes usually teach me more than abstract statements about what users “always” need.
Define the product promise
I ask what the product promises to help someone do and where the requested change fits. A product cannot optimize every local request equally. If the change makes a core job clearer, safer, faster, or more reliable, I give it more attention than an isolated convenience that adds complexity without strengthening the product’s purpose.
I make the primary user and desired outcome explicit. I also name what I am not optimizing in this decision. That boundary helps me avoid adding a secondary audience, edge case, and integration until the original problem has disappeared under scope.
This does not mean I dismiss edge cases. Some low-volume needs carry high consequences or represent important accessibility, safety, or contractual requirements. Product sense includes noticing when a simple frequency-based ranking would be misleading.
Compare options and tradeoffs
I rarely ask only whether an idea is good. I compare it with doing nothing, improving the current workflow, and trying a smaller or different approach. For each option I consider customer value, usability, implementation effort, operational burden, reversibility, and the risks it introduces.
I look for the simplest option that can create meaningful learning or value. Sometimes that is a focused workflow change. Sometimes a better explanation or default solves the main confusion. Sometimes the problem is important enough to warrant a larger investment. I do not equate simplicity with minimal effort; a small surface change can require significant technical or operational work.
I make tradeoffs legible to the team. If we choose speed over flexibility, a narrow audience over a broad one, or a manual process over a complex automation, I state the choice and what would cause us to revisit it. A decision is easier to learn from when its reasoning is visible.
Use evidence without hiding behind it
I use evidence to reduce uncertainty, not to outsource judgment. Data can show that behavior changed, but I still need to understand why and whether the change represents value. Qualitative research can reveal a meaningful need, but it does not tell me automatically how common the need is. A technical spike can show feasibility without proving adoption.
I ask what each source can actually support. I separate observation, interpretation, and recommendation in my notes. When evidence conflicts, I look for differences in segment, context, timing, or task rather than choosing whichever result supports my preferred answer.
I also notice when the cost of waiting is higher than the cost of a reversible test. In those cases, I define a small release, a guardrail, and a review point instead of demanding certainty that product work cannot provide.
Practice with product scenarios
I strengthen product sense by practicing on ordinary products. I choose a workflow I understand, identify the primary user and job, describe the product promise, and propose one improvement. Then I ask what I would measure, what could go wrong, which audience I would serve first, and what I would cut to keep the experience coherent.
I review real decisions after launch. Did the change solve the problem we named? Did it create a new burden? Which assumption was wrong? I treat this review as a way to improve judgment, not as a search for someone to blame. A good outcome does not prove that every part of the reasoning was right, and a disappointing outcome can still produce useful learning.
I seek disagreement from design, engineering, research, support, sales, and customers. Each group sees different evidence and constraints. Product sense gets stronger when I can incorporate those perspectives without losing the central problem.
Communicate the decision
I explain a product recommendation in a sequence people can follow: the person and context, the problem, the desired outcome, the options considered, the tradeoffs, the decision, and how we will learn whether it worked. I avoid presenting confidence as certainty. “This is my current recommendation because…” invites useful challenge.
A practical starting exercise
I take one feature request and write a short decision note. I name the job behind it, the primary user, the outcome, two alternatives, the biggest tradeoff, and one test that could change my mind. I ask a teammate to challenge the assumptions before I turn the request into delivery work.
Product sense works for me when it is observable and revisable. It is not a personality trait reserved for people with strong opinions. It is the repeated practice of understanding context, making responsible tradeoffs, and learning honestly from product decisions.
Next step
Build stronger product discovery, strategy, and decision-making skills in the Product Manager Certification. Subscribe to the Product HQ newsletter for practical frameworks and career-ready product lessons.
