A Concrete Definition of “Product Sense” (and How to Build It)

The Problems with Existing Product-Sense Definitions and Advice

The most widely cited definition of product sense comes from Jules Walter in Lenny’s Newsletter from 2022: “Product sense is the skill of consistently being able to craft products (or make changes to existing products) that have the intended impact on their users. Product sense relies on (1) empathy to discover meaningful user needs and (2) creativity to come up with solutions that effectively address those needs.”

Unfortunately, Jules Walter’s definition leaves something out. Empathy and creativity are essential, but how do you recognize, measure, and develop these qualities? Walter and many others, such as Jackie Bavaro, Julie Zhuo, and Marty Cagan, have tried to provide advice for building product sense; most of it revolves around simply consuming product-related inputs, such as:

• Deconstructing the products you use and doing product teardowns (Walter; Bavaro)
• Documenting a product's goals (Bavaro)
• Making crossdomain analogies ("Uber for ___") (Bavaro)
• Doing structured product critiques (Walter; Zhuo)
• Learning from people with strong product sense by studying their reasoning (Walter)
• Doing competitive and market analysis (Cagan)
• Staying curious about tech/world change (Walter) and learning the industry and enabling technologies (Cagan)
• Observing real people using products (Walter; Zhuo; Cagan)
• Inquiring as to the “why” behind behavior and feedback (Zhuo)
• Reading lots of product reviews (Bavaro)
• Studying your product's data and analytics (Cagan)
• Learning from others' successes and failures (Bavaro)

This guidance is useful, but it suggests that collecting scattered inputs will somehow produce reliable intuition to guide product decisions. I argue that gathering these inputs is not sufficient for developing product sense.

What Real Product Sense Is Built On

I propose the following definition of product sense: Product sense is the ability to recognize when current problems match past successes or failures and reliably estimate how similar solutions will affect the desired outcomes.

This view of product sense requires domain experts to build their own personal repertoire of past experiences to draw upon. It’s not enough to simply expose yourself to a collection of scattered inputs from various sources. Building real product sense requires people to close the full experimentation loop:

• Face problems
• Choose solutions
• Measure the outcomes
• Reflect on the results

Experts in many domains develop intuition that helps them make consistently good decisions in fast-paced, low-information environments. This process has been well documented and typically involves:

• Understanding the current problem
• Retrieving similar past experiences from memory to identify a plausible solution
• Evaluating whether that solution would solve the current problem
• Modifying the solution as needed, or searching for a different option

For example, fire chiefs responding to burning buildings, NICU nurses caring for vulnerable infants, and chess grandmasters evaluating possible moves all draw on rich repertoires of past experiences built by completing the full loop described above.

This definition improves on Walter’s because it turns product sense from a loose combination of empathy and creativity into a measurable decision-making skill. It specifies the mechanism behind strong product judgment: recognizing when a current problem resembles past successes or failures, predicting likely outcomes, and knowing when those comparisons are reliable. That makes product sense easier to recognize, practice, and improve.

Product Sense Also Means Knowing When Patterns Don’t Apply

So, if you gain experience making decisions and following through to see the results, do you have strong product sense? Our definition requires people with strong product sense to know both when an experience-based pattern is likely to work and when it is not. That judgment is the “sense.” It is not magical, does not come automatically with time, and remains limited to a person’s domain of expertise.

Consider a fire chief experienced with small building fires advising a crew during a skyscraper fire, a NICU nurse caring for an adult patient, or a chess grandmaster playing checkers. Do the cues they learned in one domain still apply?

Daniel Kahneman and Gary Klein point out that any new decision-making environment needs to provide sufficient familiar clues for an expert to accurately match the patterns they’ve learned to the current situation. There are roughly three categories of problems:

1. High-Validity Situations
   These mirror the environment in which the patterns were learned. They look very familiar and make accurate pattern matching easy. High-validity situations are easy for product experts (i.e., individuals with product sense) to assess. For example, a designer who has successfully improved several checkout flows may be able to diagnose and fix a similar checkout problem without extensive new research or ideation, assuming the users’ priorities and sensitivities are comparable.

2. Low-Validity Situations
   These situations differ significantly from the environments where the patterns were learned, or they lack clear cues and feedback about the action’s outcome. Past experience may still help, but there is no guarantee that the first approaches that come to mind will work. For example, a designer working on a zero-to-one product with a long feedback loop has little precedent to rely on, even with extensive design experience. In that context, trusting product sense alone is risky; it is better to challenge assumptions and gather more evidence.

3. Wicked Situations
   Coined by Robin Hogarth in 2001, the term “wicked situation” refers to problems that do match previous situations, but whose solutions are not fit for the current problem. Unlike low-validity situations, where thin cues at least leave you appropriately uncertain, wicked situations feel just like high-validity ones. This is the most dangerous category because experience here reinforces the wrong pattern while simultaneously inflating confidence. For example, a product team builds a feature that closely resembles a successful feature from another one of their products. Assuming the same approach will work, the team does little research or testing before launch. But because the new audience has different needs, the feature underperforms. What looked like a clear pattern match turned out to be misleading.

In other words, those with strong product sense can recognize when relying on intuition is unwise. They do not assume that experience gathered in one context automatically applies in another - a fundamental danger in much of the existing product-sense advice.

How Do I Develop Strong Product Sense?

The next obvious question is: how do you develop both strong decision-making patterns and the judgment to know when to rely on them?

The most important thing you can do is participate in entire product-development cycles:

• Assess the initial situation (whether it's a bug fix, user pain point, feature request, or stakeholder mandate)
• Develop the best solution you can
• Implement the solution
• Measure the outcomes of your work
• Reflect on how successful your efforts were

The more pieces of this fundamental product-building cycle are missing, the weaker your future product sense will be. You will be like the firefighter who regularly took the first half of the shift where initial calls were made, but never stuck around to see whether the building collapsed. That firefighter might feel very experienced based on the hours they’ve invested, but they are completely unqualified to serve as a fire chief because they don’t know the results of their work.

Too many product builders today work this way: they receive requests, create solutions, and move on without closely tracking the results. Often, they rely on intuition because little research is available. Or, they spend their time fixing bugs and handling complaints about products they did not help design or build. AI is accelerating this pattern. These builders are valiant in their efforts, but they are not developing a robust product sense. They are getting only half of what they need.

To build strong intuition, apply the following suggestions in your workflow wherever possible:

• Stay long enough to see the results of your work. Before changing departments, projects, or jobs, ask yourself: Is there still something valuable to learn by finishing what I started?
• Document your decision-making logic before looking at results. Be specific about your hypotheses. What quantitative or qualitative outcomes do you expect to see from your choice?
• Measure real outcomes, don’t just judge your success based on the outputs you’ve created, and hurriedly move on to what’s next.
• Reflect:
  • How well did your decisions hold up?
  • What didn’t go so well?
  • Why do you think the results shook out that way?
  • What could you have done differently?
  • Which past experiences is this situation most similar to?

Conclusion

Buzzwords come and go. There’s nothing wrong with the term “product sense.” The problem is believing that, with little data, an ever increasing velocity, and more work and decision making outsourced to AI, people can develop a “sense” for what to do without rigorous thinking. Intuition comes with time and repeated exposure to real product decisions and results. AI may rob you of the chance to develop product sense if you aren’t careful. Stay in the ring, own your decisions, and face the results. This is what will make you valuable for years to come.

References

[1] Robin M. Hogarth. 2001. Educating Intuition. University of Chicago Press, Chicago, IL.

[2] Daniel Kahneman and Gary Klein. 2009. Conditions for intuitive expertise: A failure to disagree. American Psychologist 64, 6 (2009), 515-526. https://doi.org/10.1037/a0016755

[3] Gary A. Klein, Roberta Calderwood, and Anne Clinton-Cirocco. 1986. Rapid decision making on the fire ground. In Proceedings of the Human Factors Society Annual Meeting, Vol. 30. SAGE Publications, Los Angeles, CA, 576-580.