If you’ve ever worked with a great product manager or product leader, you know there’s something distinct about how they think. They seem to have an instinctive good sense for making sound product decisions. They can take a narrow feature request and trace it outward into the wider workflow, customer outcome, and business implications around it. Or give them a broad, strategic ambition and they can work inward to the specific product decisions required to make it a reality.
What enables them to see problems more clearly, connect scattered observations, and repeatedly help their team make better decisions about what to build, and how?
I’ve been mulling over how to define the collection of qualities that make someone a great product thinker.
Some skills of effective product leadership are easy to see. Things like comfort working with customers, setting priority and focus in the right place, translating strategy into plans, coordinating execution, and communicating with the wider team. But these describe activities of the role rather than the quality of the thinking behind them. They don’t fully explain the difference between someone who competently manages product work and someone who has a knack for guiding product direction as a whole.
I call this underlying capacity “product thinking.” But that still begs a question: what exactly does product thinking mean? Great product thinkers are easy to spot when you work with one, but there’s a “you know it when you see it” quality that’s hard to articulate. If asked to define it directly, we might reach for words like taste, intuition, judgment. These are just as slippery.
In this series of articles, I want to probe deeper into this idea. My working hypothesis is that product thinking is not a single instinct or innate gift, but a collection of connected, learnable skills. Over the next four essays, we’ll examine this hypothesis in distinct parts:
Part I: Developing Product Sense – how observation, experience, and reflection generate pattern recognition we often call intuition
Part II: Thinking at Every Scale – how product thinkers work at different scales, hold details and the wider product system in view simultaneously, and trace the causal relationships between parts
Part III: Setting Boundaries, Making Tradeoffs – how to draw boundaries around problems, make tradeoffs, and find powerful points of leverage
Part IV: Creating Sustaining Loops – how they turn solutions into self-sustaining, complementary advantages for both customer and the business, where customer and business value reinforce one another
Taken together, these qualities describe the particular kind of thinking we recognize in great product leaders. In this first essay, I’ll start with what I think is the most mysterious of the four: What is product sense, and where does it come from?
Product sense is something of a meme in product circles. But different commentators disagree on a precise definition of what it means. Shreyas Doshi frames it in terms of its outcome: “reliably making good product decisions, large and small, even amid considerable ambiguity.” Marty Cagan is suspicious of the term altogether, arguing that what looks like an innate sense is better understood as “deep product knowledge.” My definition takes something from each of these.
What we call good “product sense” often looks like in-born intuition. Great product leaders almost seem as if they have an instinctual feel for what users want and how to get it done. Think of how Steve Jobs is described in the popular imagination: a product visionary who willed his crazy ideas into existence out of the ether.
But intuition isn’t some kind of magic talent you’re born with. It’s a resource that’s cultivated and nurtured over time.
Training intuition, developing judgment
By its dictionary definition, intuition means “insight without rational thought or conscious reasoning.” But it doesn’t arrive by chance, thoughtlessly or effortlessly. A better working definition might be something like insight from accumulated experience. It may seem like “gut feeling” drives intuition, but behind that intuitive product sense is a collection of learnings, condensed into something that can be recalled without explicit thinking.
Intuition appears instinctive because the “data” behind it is compressed into recallable patterns, not because it’s merely based on gut or whim.
Like any other skill, we cultivate product sense through example. One of the things I’ve spent countless hours doing in my career as a product leader is paying close attention to products around me — not my own, and often not even ones in the space I’m working in. This builds a solid lay-of-the-land of what’s out there, what specific problems each product solves, who for, how it does so, and where its limitations are.
This kind of close attention pays dividends as you begin to notice what works, and build mental models of different types of users, different shapes of problems, and how others creatively approach their solutions. The more diverse your collection of observations, the richer your mental library of options to compare to. It’s important, though, not to just passively look at other products and how they work. You want to develop a habit of noticing then interrogating what you encounter. Develop your own hypotheses and predictions, then test them through trial and error.
“Example is the school of mankind; they will learn at no other.” –Edmund Burke
We learn an enormous amount through example and analogy. What does this product have in common with three others you’ve seen? Where do they differ? Is the similarity superficial, or is the same underlying mechanism at work? And the more we pay close attention to the ocean of examples around us, along with how well they work (or don’t), the more building blocks we can shape into repeatable functioning patterns.
Examples accumulate into patterns
Novices often encounter a product problem and see a collection of specifics: this screen has this problem, this feature request keeps appearing. They have to reason forward simple observed facts. Each time they start from a blank slate.
With enough varied experience, you start to recognize that different situations — sometimes dramatically different — share an underlying structure. The surface details differ, but the relationships and forces involved are familiar. This is recognizing the shape of a problem.
For example, take some of these user experiences in different apps:
Users repeatedly export reports and email them to colleagues.
Figma users send designs to people who don’t have accounts.
Calendly users send scheduling links to people who have never used Calendly.
Dropbox users share folders with non-users.
These are, admittedly, simple examples, but if you’re a novice without a rich language of patterns to work with, you may see a situation like this and not notice similarities across different flavors of problem. As you notice more problems, a pattern begins to reveal itself:
One person’s use of the product naturally produces something valuable to another, who isn’t yet a user.
The pattern is much more useful than a specific feature like “sharing can drive growth.” Patterns are abstracted away from implementation, but retain the underlying causal structure.
Now when you encounter a new product where users produce something valuable to outsiders, the situation feels familiar. You don’t have to rediscover the entire idea from first principles. I’ve seen this shape before.
Mature product sense isn’t just recognizing a huge library of patterns. It’s being able to identify which ones are operating simultaneously and how they interact.
This also gets at why expertise can appear intuitive. The expert doesn’t consciously recall six previous examples they can point to, specifically. They’ve compressed their observations into a repeatable, recognizable pattern.
Expertise is understanding why patterns work
A novice and an expert may both recognize a familiar pattern. The difference is that the expert has a richer understanding of the pattern’s underlying causal structure.
Consider the sharing example from before. One might observe that:
Figma, Dropbox, Calendly, and DocuSign all grew through sharing. Therefore, sharing is a good growth mechanic.
That’s definitely noticing a pattern, and matching similar ones to each other. But it’s only identifying the superficial similarities, treating only the visible implementation details as the pattern.
A more experienced product thinker would ask: why did sharing produce growth in those products? It’s not simply because a “share” button existed. It’s something more like:
The user’s normal use of the product creates output valuable to another person. Delivering that value naturally exposes the recipient to the product as a second-order effect.
This moves you from recognizing a surface pattern (”sharing drives growth”) to understanding an underlying causal pattern (”value created by one user can naturally expose another person to the product”).
Expertise develops when you form patterns and follow that up with a causal model of why they work. Good product sense fosters a library of patterns, along with knowledge of the forces at work that make those patterns interesting and useful.
Patterns should be adaptable
As you gain experience, your language of patterns expands. You start building out a collection:
Defaults — shape behavior by making one path require less effort.
Progressive disclosure — hide complexity until it becomes relevant.
Templates — reduce the blank-page problem and teach users what “good” looks like.
Land and expand — solve one person’s problem well enough that usage spreads through an organization.
Escape hatches — automate the common path while preserving manual control for exceptional cases.
And many more...
From prior observation, we begin to develop a sense for when the context is right to deploy one of these patterns from our arsenal. But for a pattern to be realistically useful, it needs to be slightly flexible. A pattern should be a sort of “heuristic” rather than an exact specification for a software feature. Patterns aren’t Lego bricks, with rigid dimensions made to click exactly with one another. They’re sort of fuzzy on the edges. A good pattern has a stable center and a negotiable perimeter.
A pattern should indicate what forces or relationships its well-suited for, not dictate exactly what you should build.
Consider an app’s onboarding process for first-time users. Someone may notice that several successful products use checklists during onboarding and conclude: “onboarding checklists improve activation!” That treats the pattern as a reusable, drop-in solution. It worked once or twice, so now the next product gets a checklist.
But the deeper question is: why did the checklist work? Perhaps those products had a small number of discrete setup tasks that users needed to complete before realizing value. The checklist made an otherwise ambiguous setup process legible, gave users a sense of progress, and reduced uncertainty about what to do next. Maybe the next product’s early steps aren’t this clear-cut.
Rather than be so prescriptive, so inelastic, the pattern should be something more like:
When users must complete several prerequisite actions before reaching value, make the path and their progress through it visible.
Keeping it abstract on the edges, and focused around the forces and connections between user and problem, we have a reusable pattern we can design a solution around.
Product sense can be learned
Product sense looks less mysterious when we understand it this way. It isn’t a God-given gift for conjuring the right answer from nowhere. It’s the result of a repeated loop:
notice examples → interrogate why they work → abstract the underlying pattern → apply it somewhere new → revise your understanding
Experience alone isn’t enough, though. A person can spend years encountering product decisions without becoming much better at making them. The raw material of experience only crystallizes into judgment through close attention and reflection. It’s not a game of numbers to see how many patterns you’ve collected, but how well you understand the forces that make them work, how they interconnect with one another. And how readily you can adapt them when the context changes.
When approaching a new problem, ask yourself: What shape does this resemble? Where have I seen it before? Why did the solution work there? Are the same forces present here? At first, answering those questions takes deliberate effort. Over time, the answers compress into this intuition we call “product sense.”
But recognizing the shape of an individual problem is only one aspect of product thinking. Products aren’t collections of isolated decisions; each choice affects a larger system of users, workflows, incentives, and business outcomes. In the next essay, we’ll look at how great product thinkers move between those parts and the whole — and understand the relationships connecting them.
Make sure to follow along in our series on The Anatomy of Product Thinking. Continue on to part 2, where we dive into the product thinker’s knack for seeing problems at different scales.
the six-figure sense
Nice work as always!