Product sense is not a soft skill and it is not product management. For an engineer it means the judgement to know which version of a thing to build, what to leave out, and when the requirement as stated is wrong.

• You ask what problem this solves before asking how it should work. The single cheapest signal, and most candidates skip straight to implementation.
• You propose a smaller version. ‘We could ship the single-user case in a week and learn whether anyone wants the collaborative one’ is a product-sense answer given by an engineer.
• You notice the edge case that is actually a product decision. What happens when someone has no data yet, when they exceed the limit, when two people edit at once — these are not technical questions and engineers who surface them are valued disproportionately.
• You can say what you would cut under a deadline, and defend it in terms of user impact rather than effort.
• You know what the feature costs to run, and mention it unprompted.

Product sense comes from being close to consequences, which is why engineers on internal tools or deep infrastructure often have had less opportunity to develop it. Three things that work: read your own product's support tickets for an hour a week; ask to sit in on one customer call a month; and whenever you are handed a requirement, write down what you think the underlying problem is and check it with whoever asked. That last one costs nothing and changes how you are perceived within a quarter.

It appears in 84% of software engineering postings — higher than distributed systems — and it is the least-prepared-for item in the whole loop, because most candidates read it as a soft skill. It is not. It is the habit of knowing what the code is for, and letting that change what you build.

• Knowing who the user is, specifically enough to say what they were doing five minutes before they reached your feature and what they will do five minutes after.
• Knowing what problem the work solves, stated as the user's problem rather than the ticket's title.
• Being able to argue for a smaller version — and this is the one that separates people. An engineer who can say ‘we could ship 80% of the value in 20% of the time by dropping X’ is worth more than one who implements the spec faithfully.
• Noticing when a requirement is wrong and raising it before building it, rather than building it and being right afterwards.
• Knowing how you would tell whether it worked after it shipped.

The ticket: ‘Add an export-to-CSV button to the reports page.’

That last row matters as much as the third. Product sense is often taught as ‘push back on requirements’, and engineers who learn it that way become expensive to work with. The skill is surfacing the better option and letting the person who owns the priority decide — while still delivering the thing that was asked for.

• “Tell me about something you built. Why did it exist?” A weak answer describes the architecture. A strong one describes the user, the problem, what was cut, and how you knew it worked.
• “How would you measure whether this feature succeeded?” Weak: usage. Strong: a metric tied to the user's problem, plus a guardrail metric that would tell you the feature is succeeding at the expense of something else.
• “We have six weeks instead of six months. What ships?” This is the most direct test and it is genuinely hard. The answer must cut scope rather than quality, and must say what the cut costs.
• “What would you have done differently?” An answer of ‘nothing’ is a bad answer, and so is a list of technical regrets. The good version names something about the problem you understood too late.