The topic of product sense came up in a one-on-one—an engineer (RD) wanted to talk about “product sense,” and at the time we split it into two parts: how engineers should understand the product, and what product managers actually do. The core is the difference in stance between RD and PM. When discussing it, always ask one step further first: What is the user trying to accomplish? Where are they getting stuck? What friction does this solution remove, and what cost does it introduce?

Prepare Your Own Perspective

First, answer for yourself where you stand on “understanding requirements” and “understanding outcomes.”

  • How do I understand a requirement? Background, purpose, features; launch, impact (data), review, iteration.
  • How do I understand outcomes? Have I ever looked from the user’s perspective?
  • How do I understand data? Process data and outcome data, A/B experiments, the full funnel.
  • From my perspective, is the product’s goal clear? Are the stages of breaking it down clear? (Goal communication, product strategy, industry competitors, stage of development)
  • For the business I’m working on now, can I articulate which direction it’s heading at the product level?

Points Worth Discussing

Starting from “what matters most in the product you’re building now” is more useful than starting from “what is product sense.”

  • Want to talk about the current business from a product angle? What will this product do in the next six months? Where are the areas of focus? What is the logic behind how the product operates?
  • How do I think this product should be built? In my understanding, what form should it take, and what should its monetization model look like?
  • How can technology serve the business? How can technology measure product impact?
  • If you had a business of your own, which business metrics would matter most?
  • In the product you’re building now, which module matters most? Why?
  • If you had to remove the least appropriate module from the current ones, which would it be? Why?
  • Looking back at the requirements you’ve shipped in the past six months, can you name the top 3 that had real impact?
  • How do you build retention for a content platform? How is growth done?

Four Questions Are Enough to Begin a Judgment

  • What task is the target user trying to complete?
  • What is the current evidence?
  • Which constraints cannot be ignored?
  • What is the smallest validation?

When someone proposes “adding a settings toggle,” don’t rush into discussing the component: what is the user trying to avoid? Do they need to change the setting frequently, or do they just want to make a choice the first time? If it’s only a first-time choice, a default value plus a one-time explanation may be simpler than a permanent toggle. Product judgment isn’t about pursuing more features—it’s about making clear: who we’re serving, what we’re willing to take on, and what we’re holding off on for now.

Gripes and Feedback

  • I’ve taken on too many requirements whose value I can’t articulate.
  • I don’t know the real reason the product is building this feature.
  • Nobody reviews whether it worked; once it ships, that’s the end of it.
  • And ______