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.