I don’t think you can be an expert in generic “Product” just like I don’t think you can be a generic management expert.

And I don’t think you can decide what to build or how it should work from a user perspective without taking into account how it’s built. In many ways I think how it’s built tends to inform what it should do more than the other way around.

However, Product alone is never the cause of bad software in my experience. It’s always product plus an engineer who refuses to push back on the initial proposal.

In most cases when product and design comes to you with a feature, and all the solutions you can come up are going to add tech debt or take forever, you should step back and talk to Product about the problem they are actually trying to solve.

If you go back to product with “I can build this very similar feature that will get you 90% of the way there, but will take 1/2 as long and not create maintenance problems down the line”, they will almost always be happy with that.

The real problems are caused when an engineer says immediately “yep I can build that in 2 weeks” and starts trying to force their solution through by telling everyone that product insisted on this specific feature in this specific timeline that unfortunately can only be done in the way they’ve designed. And then they tell product that they have a solution but are being blocked.

I’ve seen this pattern over and over.