When Shreyas Doshi was at Stripe, he described product sense as "the ability to understand what makes a product great, the ability to identify which problems are worth solving, and the ability to anticipate user reactions." That definition is accurate. It is also intimidating, because it makes product sense sound like something you either have or you do not.
It is not. Product sense is pattern recognition. And pattern recognition is built through exposure, reflection, and deliberate practice. You can develop it the same way a chess player develops intuition. By studying hundreds of positions until the patterns become automatic.
Here is how.
What Does Product Sense Actually Look Like in Practice?
Before we talk about building it, let us define what it looks like when someone has it. Product sense shows up in specific observable behaviors:
They spot the real problem. A customer says "I need an export button." A PM without product sense adds an export button. A PM with product sense asks why and discovers the customer needs to share data with their finance team, which means the real solution might be a shared dashboard, an integration, or a scheduled email report. The ability to see past the stated request to the underlying need is product sense in action.
They anticipate second-order effects. Adding a "quick add" shortcut to a task management app seems harmless. A PM with product sense sees that it will bypass the categorization step, leading to disorganized task lists within three months, leading to increased support tickets, leading to a perception that the product is messy.
They feel when something is off. They use a prototype and immediately sense that the flow has one too many steps, or that the naming will confuse users, or that the feature is solving a Tuesday problem while ignoring a Monday problem. They cannot always articulate why in the moment, but they are usually right.
They prioritize without analysis paralysis. They can look at a list of 20 feature requests and immediately identify the 3 that matter, not because they have a scoring framework in front of them (though those help), but because they recognize the patterns from previous products.
They see the product as a system. They understand how changing one part affects other parts. Adding a notification feature is not just about notifications. It is about attention, user fatigue, settings complexity, and the overall rhythm of the product. This systems-level thinking is what distinguishes tactical PMs from strategic ones.
The Four Inputs to Product Sense
Product sense draws from four distinct knowledge domains. Weakness in any one of them creates blind spots.
1. User Empathy
Understanding how people actually behave, not how they say they behave. This comes from hours of watching users interact with products. Your own and others. It comes from customer development conversations where you listen more than you talk.
The gap between stated preference and revealed preference is where most product mistakes live. Users say they want more features. They actually want fewer features that work better. Users say they want customization. They actually want sensible defaults. Building this understanding requires direct observation, not just survey data.
2. Domain Knowledge
Understanding the specific market, industry, and competitive context your product operates in. A PM building healthcare software needs different domain knowledge than one building developer tools. This knowledge takes time and there are no shortcuts. But you can accelerate it by reading everything your customers read, attending their conferences, and spending time with the practitioners who use your product.
3. Technical Intuition
Not the ability to write code, but the ability to sense what is easy and what is hard. A PM with technical intuition knows that "just add a search bar" involves indexing, relevance ranking, performance optimization, and edge case handling. They know when they are asking for something genuinely simple and when they are asking for something that sounds simple but is not.
This comes from working closely with engineers over time. Ask them to explain their constraints. Attend architecture reviews. Build things yourself, even if they are small and messy. The goal is not expertise. It is calibration.
4. Business Acumen
Understanding how your product creates and captures value. Which features drive conversion? Which drive retention? What does the unit economics look like? How does pricing interact with feature decisions?
A PM with business acumen knows that a feature used by 5% of users might be more important than one used by 50% if that 5% represents enterprise customers who pay 20x more. They understand the difference between a feature that grows the market and one that extracts more value from the existing market.
Most PMs are strong in one or two of these domains and weak in the others. An engineer-turned-PM typically has strong technical intuition but weak user empathy. A designer-turned-PM often has strong user empathy but weak business acumen. Identifying your gaps is the first step to deliberate practice. You cannot build what you do not know you are missing.
The Product & Design Strengths Framework maps these skill areas across 8 dimensions and identifies 8 archetypes that describe how PMs and designers create value. Take the interactive assessment to pinpoint your profile in about 5 minutes.
A simple self-assessment: rate yourself 1-5 on each domain and ask two trusted colleagues to do the same. The gap between your self-rating and their rating is usually where your biggest blind spot lives. An engineer-turned-PM who rates their user empathy as a 4 but colleagues rate it a 2 has found their most impactful development area.
Five Practices for Building Product Sense
Practice 1: The Daily Product Teardown
Spend 15 minutes each day using a product you do not normally use. Not casually. Critically. Ask yourself:
- What is the core job this product does?
- What was the first thing I noticed? Why?
- Where did I feel confused or frustrated? What caused it?
- What is one thing this product does better than its competitors?
- What is one decision the product team made that I disagree with? Why might they have made it anyway?
Write your answers down. Over months, you will develop a library of patterns. What works, what does not, and why. This is the deliberate practice equivalent of studying chess games.
Products worth studying right now: Linear (opinionated workflow), Arc (browser reinvention), Raycast (command-based UX), Loom (async video communication), Notion (composable documents). Each made bold product bets that are worth understanding in detail. Study not just the current product but how it evolved over time.
Practice 2: Hypothesis Journaling
Before you look at any data or talk to any users about a problem, write down your hypothesis. "I think users are dropping off at step 3 because the form asks for information they do not have yet." Then go find out if you are right.
Hypothesis-driven development is valuable as a process, but it is also valuable as a training method. Over time, you will notice your hypotheses becoming more accurate. You will start recognizing which types of problems you read correctly and which types you misjudge. That calibration is product sense.
Practice 3: The "Why Did They Ship This?" Exercise
When a product you follow ships a new feature, do not just evaluate it. Try to reconstruct the reasoning behind it.
- What problem were they trying to solve?
- What alternatives did they probably consider?
- What trade-offs did they make?
- What metric are they trying to move?
- Who inside the company probably championed this?
Do this for 50 product launches and you will start seeing the recurring patterns in product decision-making. You will recognize the signs of a feature that was built for a customer deal, versus one that was built from user research, versus one that was a CEO's pet project.
Practice 4: Reverse Engineering Successful Products
Pick a product that is widely considered well-designed. Figma, Linear, Notion, Arc, Superhuman. And trace its evolution. Use the Wayback Machine, old blog posts, and launch announcements to understand:
- What features were in V1? What was explicitly excluded?
- In what order were features added? Why that sequence?
- Where did the product team make non-obvious choices?
- What did competitors do differently?
The goal is not to copy these products. It is to understand the decision-making patterns that led to their success. The best products are the result of hundreds of small, compounding decisions. Studying those decisions builds your judgment for making your own.
Practice 5: Seek Disconfirming Evidence
Product sense is only as good as your ability to challenge your own assumptions. Build a habit of actively seeking evidence that you are wrong.
After you form an opinion about a product direction, ask: "What would it look like if I am wrong?" Then go look for that. Talk to the users who disagree with your hypothesis. Read the competitor reviews from customers who switched away from your product. Look at the usage data for the feature you were ready to kill.
The PMs with the best product sense are not the ones who are always right. They are the ones who update their beliefs quickly when new evidence arrives. Charlie Munger's concept of "inverting" applies here: instead of asking "how do I make this product successful?", ask "how would I guarantee this product fails?" The failure scenarios you generate will reveal your hidden assumptions and blind spots more efficiently than positive thinking ever will.
Common Mistakes in Building Product Sense
Mistake: Confusing opinions with product sense. Everyone has opinions about products. Product sense is opinions grounded in evidence and pattern recognition. If you cannot explain why a product decision is wrong (beyond "I don't like it"), you are expressing taste, not product sense.
Mistake: Only studying successes. Failed products teach you more than successful ones. Study why Google Wave failed, why Quibi died, why the Facebook phone never took off. The failure patterns are more instructive than the success patterns because success has many causes but failure has recurring ones.
Mistake: Building product sense in a silo. Discussing products with other PMs sharpens your thinking. Start a product review club. Debate decisions. Challenge each other's reasoning. Product sense develops faster in dialogue than in isolation.
Mistake: Thinking product sense replaces process. Product sense helps you make better decisions faster. It does not mean you skip customer research, data analysis, or structured prioritization. The best PMs combine strong product sense with rigorous process. Product sense tells you where to look. Process tells you how to validate what you find.
Measuring Your Progress
Product sense is hard to measure directly, but there are proxy signals that indicate you are improving.
Your hypotheses improve. Track your accuracy over time with hypothesis journaling. When you first start, you might be right 30% of the time about what users will do. After a year of practice, that number should climb to 50-60%. You will never be right all the time, but the trend should be clear.
You spot problems earlier. In design reviews and spec discussions, you start catching issues that others miss. The edge case nobody considered, the user segment that would be confused, the second-order effect that will create support tickets. This pattern recognition is product sense making itself visible.
Your questions get better. New PMs ask "what should we build?" Experienced PMs with strong product sense ask "what is the user trying to accomplish, and what is preventing them?" The quality of your questions reveals the depth of your understanding.
People seek your input. When engineers, designers, and other PMs start pulling you into conversations because they value your perspective, that is a signal. Product sense earns trust because the insights it produces are consistently useful.
You can articulate trade-offs quickly. Someone proposes a feature. Within minutes, you can outline the 3 most likely risks, the 2 audiences it would serve well, and the 1 reason it might not be worth building. This rapid trade-off analysis is the most visible manifestation of product sense.
How Long Does It Take to Develop Product Sense?
There is no shortcut. In my experience, deliberate practice over 2-3 years is what separates PMs who "have product sense" from those who are still developing it. But the compounding starts early. After six months of daily teardowns and hypothesis journaling, you will notice that your instincts in product discussions are sharper and your arguments are better grounded.
The critical insight is that product sense is not a destination. It is a practice. The best product leaders I know. People with 15+ years of experience. Still do product teardowns, still challenge their assumptions, and still seek disconfirming evidence. They have better product sense not because they stopped practicing, but because they never did.
Start today. Pick a product you used this morning. Spend 15 minutes writing down what it does well, what it does poorly, and what you would change. Do the same thing tomorrow with a different product. In six months, your pattern library will be deeper, your instincts will be sharper, and your product decisions will be better grounded.
Product sense is not magic. It is mileage. And the odometer starts the moment you decide to pay attention.
The question is not whether you have product sense. The question is whether you are building it deliberately or leaving it to chance. Deliberate practice beats passive experience every time.