[friendzis]

> I think the problem is when product dictates what is going to be implemented

I don't think of that as a problem, that's one of the primary goals of product. Problems (yuuge problems) arise when product also gets to dictate cost/timelines. Sorry, that breaks basic management principles.

> I used to do that until I had a manager that changed my view.

Small, young teams (e.g. startups) can easily do without management, because communication is unhindered and ad-hoc. The more organization expands and matures, the more communication suffers. That's the primary goal of engineering management - facilitate conversations. When I have a request that is tad too technical I always try to backtrack and ask what's the business goal. I am 99% certain "display memory usage per tab" is not the business goal. "Find resource hungry tabs" sounds like a good candidate for a business problem.

"Customers" (e.g. product) tend to be "helpful" and provide technical implementation details, diluting the business problem, while engineering tend to fixate on those implementation hints as if they were technical requirements. Ever noticed how technically inept product managers/owners sometimes tend to be good managers? Well, they are either aware of their technical ineptitude or are inept so much that they can't even express technical details and form their requirements as business questions which leaves implementation details open and allows engineering to implement things "correctly". It's magical how simply communicating on appropriate abstraction level can lead to awesome results as each team can focus on what they are strongest at.

[pjc50]

Some of this is what stackoverflow calls an X/Y problem; someone has a problem, got halfway down a route to a solution, and now is talking to you. It can be quite difficult to dig down into what the actual original problem was, then persuade them to back up and pursue what is in your opinion a better solution.