On being a product-minded developer

The best engineers I’ve worked with don’t treat product as someone else’s problem. They read the support tickets. They sit in on the sales calls. They notice when a customer keeps asking for a feature the team has already built three times in three different shapes.

This isn’t about being a "10x engineer" or doing the PM’s job. It’s about closing the feedback loop on your own work.

What changes when you do this

You start writing different code. Not better, just different. You add the empty state because you saw a screenshot of someone hitting it. You don’t spend a week on the edge case that affects four users. You notice when a request "isn’t actually about the API, it’s about the shape of the data we store." You stop arguing about the right abstraction and start arguing about whether the abstraction matters to the person paying.

What it costs

Time. There’s no way around it: reading user feedback is a tax on your focus, and you have to be honest about whether the tax is worth it for the role you’re in. If you’re three months deep in a database migration, no, probably not today. If you’re building a feature, the tax is the job.

I’m not arguing every engineer needs to do this. I am arguing that the engineers I most enjoy working with all do, and that the gap between an engineer who does and one who doesn’t is wider than the gap between two engineers of the same kind at different skill levels.