Whats 'product sense' vs 'strategic execution' vs 'leadership judgement'
Navigating the jargon - product sense vs. strategy vs. leadership judgment. It's all corporate bullshit? yes. But knowing the difference can decide your next promo.
At some point in your career, you get senior enough for your 1-1 feedback to start including what sounds like corporate jargon. Or as we call it, in professional circles and behind closed Slack channels, corporate bullshit - product sense, strategic thinking, and leadership judgment.
Then slowly the jargon creeps into your perf expectations, your 360 feedback. And eventually, painfully, your reasons not to promote.
Product Sense vs Strategic Thinking vs Leadership Judgement
The scope of what’s expected from engineers is expanding (e.g: Meta added product sense to their Engineering role guidelines). But the vocabulary being used to describe it is sloppy enough that you can do everything right and still miss because you optimized for the wrong word.
So the next time one of these shows up in your performance review, do yourself a favor and ask whether what they’re saying is also what they mean. Here’s a break down so you can aim at the right target.
What is product sense?
Product sense is figuring out what’s worth building and in what order.
It’s having a point of view on which problems actually matter, how users behave (not how you assume they behave), and what you’re willing to trade-off to solve the thing that matters most.
The person with strong product sense doesn’t just build what’s on the ticket. They’re the one who notices that users are exporting data to CSV because the product doesn’t have the dashboard they actually need, and then go build the dashboard
Here’s a detailed take on what is product sense, what’s hard about it for engineers, and how to build it.
When product sense is missing, you build something technically sound that probably still solves some problem, but it doesn’t move the needle on the metric that the business cares about. In other words, it’s wasted effort.
What is strategic thinking for engineers?
Strategic thinking gets thrown around a lot, and for engineers and new managers, it can feel especially vague. If often doesn’t mean writing a strategy doc. In practice, strategic thinking has three layers.
First, know the game. Connect the dots across your team’s goals, the org’s priorities, the competitive landscape, and what’s most likely to kill your product. You can’t think strategically about your work if you don’t know what game the company/org is playing.
Second, form an approach. Take what you learned in step one and turn it into a bet. If the competitive landscape says speed wins, your approach might be "identify a niche use case and iterate fast vs going broad." If your biggest risk is platform fragility, maybe you slow down and invest in durability. If there's a team two orgs over building something adjacent, maybe you partner deeply instead of building it yourself.
Once you have an approach, it should filter out everything else. Without an approach, you end up investing in onboarding and power-user features and internationalization all at once, and none of them move far enough to matter.
Third, actually follow it. If your approach is "iterate fast on a narrow use case," that should show up in every decision - cutting scope aggressively, picking scrappy over elegant because you need to learn before you invest, telling the partner team no when they want you to generalize your API.
Most teams agree on an approach in a planning meeting and spend the next quarter contradicting it because the day-to-day challenges feel more immediate.
So where does product sense end and strategic thinking begin?
Product sense tells you what to build. Strategic thinking tells you why that thing, in this context, right now. Product sense is “our users need a dashboard.” Strategic thinking is “we need the dashboard before we invest in the UI, because this year our focus is retention, not new growth.”
Leadership Judgment
Product sense and strategic thinking are about what to d and how to do. Judgment is about how you handle the human side of doing it - knowing what call to make, when to make it, and how much force to apply. Usually without enough information or clean data.
Timing - the same feedback lands completely differently on Monday after a launch versus Thursday after a reorg. Letting a team struggle through a hard problem instead of stepping in, because the learning matters more than the timeline. Escalating something early because you can see where it’s headed.
Calibration - knowing which battles need you to go to the mat and which ones you let go. Promoting someone your skip-level will question because you've seen something in the last two quarters that hasn't shown up in their metrics yet. Having a hard conversation at 70% intensity because the person is already shaky and you need them to hear it, not shut down.
Consistency - You can have sharp product sense and a solid strategy, but if your team doesn’t trust how you make calls, none of it compounds. That trust is built by people seeing a consistent logic behind your decisions, even the ones they initially disagreed with at first.
When judgment is missing, you see managers and leads who have the right read on the situation but blow the execution. They give the hard feedback on the wrong day, escalate something that needed one more week of data, fight for the right thing so aggressively that people stop wanting to work with them. The strategy was sound, the product sense was there. But the outcome still went sideways because the human part was off.
