“Product sense” is often used like a compliment and explained like a horoscope. Someone has it. Someone does not. The room nods knowingly and moves on.
That is not useful for learning.
The less mystical version
Product sense is the ability to make a reasonable product judgment when the evidence is incomplete, the constraints are real, and the answer is not hiding in a framework.
It is not guessing. It is a compressed form of practice.
Strong product thinkers tend to notice four things quickly:
- The job: what the person is trying to accomplish.
- The friction: where the current experience breaks down.
- The trade-off: what improves for one group and worsens for another.
- The test: what small piece of evidence would change the decision.
How it gets built
You build product sense by making your reasoning visible. Before proposing a solution, write down the problem in one sentence. Before debating a feature, describe the user behaviour it should change. Before choosing a metric, explain why that metric is a plausible signal of value.
Then invite someone to disagree.
The disagreement is not a performance review. It is practice. Every time your mental model meets another person’s context, your judgment gets more precise.
The dangerous shortcut
The shortcut is confusing taste with sense. Taste says, “I would use this.” Sense asks, “Who needs this, in what context, and what would make it worth the cost?”
Taste can start a conversation. It cannot finish one.
Product sense is a library, not a lightning bolt
Experienced product people appear fast because they have seen recurring structures: activation that mistakes setup for value, marketplaces that optimise one side while starving the other, collaboration features that add communication instead of reducing coordination, enterprise requests that hide a governance problem.
The pattern library helps them generate hypotheses. It does not excuse them from checking context. A pattern transferred from consumer media to regulated healthcare can become a very efficient mistake.
The skill is knowing both when a pattern is informative and when the differences matter more than the resemblance.
Make the model visible
Teresa Torres’s opportunity solution trees are one method for showing how an outcome, customer opportunities, possible solutions and assumption tests relate. The value is not the tree shape. It is forcing a team to reveal the path between evidence and a preferred idea.
Once visible, the model can be challenged. Are we treating one interview as an opportunity? Did we jump from a broad outcome to the first available feature? Are three solutions actually variations of one assumption? Which branch has evidence and which has executive enthusiasm?
Product sense improves when the thinker receives feedback not only on the answer but on the structure of the reasoning.
Practice on decisions smaller than a launch
You do not need ownership of a major roadmap to practise judgment. Choose an everyday product and write a short product narrative:
- Who is using it, in what situation?
- What progress are they trying to make?
- Where does the current experience create friction or anxiety?
- What trade-off seems deliberate?
- What single piece of evidence would most change your interpretation?
Then compare your model with real behaviour, reviews, support discussions or someone who uses the product differently. The gap is the training material.
Marty Cagan’s build-to-learn FAQ connects product sense to understanding customers, data, industry and business, then testing solutions against product risks. This is a useful correction to the idea that judgment is simply having better ideas. Strong judgment includes knowing which belief is dangerous enough to test first.
Seniority can damage product sense
Success creates a new risk: the organisation begins protecting someone from disconfirming evidence. A senior leader’s fast intuition receives less questioning, so their pattern library stops being corrected by reality.
Good product leaders therefore narrate uncertainty. They separate what they observed from what they inferred. They ask junior colleagues what they see differently. They write predictions before results arrive. They make it professionally safe for evidence to embarrass an attractive idea.
This does not weaken authority. It keeps authority connected to learning.
A product-sense review
After an important decision, revisit it without grading only the outcome. A good outcome can follow poor reasoning and a bad outcome can follow a sensible bet.
Review the assumptions available at the time, the alternatives considered, the evidence ignored and the signal that eventually mattered. Add the lesson to the team’s pattern library in specific language. “Talk to users more” teaches little. “We mistook administrator enthusiasm for end-user adoption” can change the next decision.
Questions to take back to your team
- When someone says an idea shows “good product sense,” which observable reasoning are they praising?
- What assumption in your current favourite solution would be most expensive if wrong?
- Which pattern from a previous product are you transferring without checking whether the context matches?
- Who in the room can challenge senior intuition without paying a social price?
- What decision could you revisit now to improve the reasoning rather than defend the outcome?
Take a current proposal and narrate the user, friction, trade-off and next test without naming the solution. Does the idea still feel inevitable, or did the missing reasoning just become visible?
My take
When an interview question asks for product sense, do not perform certainty. Show the path: clarify the user, frame the problem, surface the trade-off, and say what you would learn next.
That is not less impressive than a clever answer. It is the actual job.