[scott_w]

Disagree. This position completely disregards our experience and expertise. We need to partner with our Product counterparts to figure out what our customers’ needs are. We must also be clear what our operating constraints are so PMs can make an informed decision on what to prioritise based on a reasonable idea of the costs/benefits.

Doing anything less is basically shitting on Product and, if you have that attitude, why do you think you deserve to be treated as an equal in the conversation?

[devjab]

What makes you think you know more about customer needs than the people working directly with the customers?

I think we sort of agree though. I think presenting product with various options and letting them decide includes a lot of what you suggest here. Including working with product. Ultimately though, it’s the job of engineering to deliver what creates business value. Refusing to add a bathroom to a customers house because there are engineering concerns or thinking you are better at spotting customer needs than product is the opposite of that in my opinion. Of course the flip-side or this is that you need an organisation which will accept it when engineering points out that adding a bathroom will be widely expensive because the foundation needs to be reinforced, or maybe the entire house needs to be rebuild. Without that you end up with Boeing.

I do think that thinking you know better is unfortunately one of the pitfalls of our profession because we’re so used to working with patterns, but often engineering won’t even be told the full picture. I find it to often be a humongous waste of time if engineering has to be taught why something is actually necessary before they can get on board with it. This is not me saying that forcing engineers to do something they think is a bad idea is the right way to do things. This is me saying that I prefer engineering departments which are cultivated towards delivering value, and not being obstacles you need to “convince”. This is so often the reason software engineering (and IT) in general is disregarded or seen as “them” in organisations, because they are the people who deliver problems rather than solutions.

[scott_w]

> What makes you think you know more about customer needs than the people working directly with the customers?

I never said I did. What I said was that we should not disregard our own knowledge and experience when working on our products.

We should be expected to get a good enough understanding of our customer/user needs to be able to challenge Product prioritisation and also to make our day-to-day decisions better when building out the product.

> I think presenting product with various options

This wording implies an abdication of responsibility in my opinion. We aren't "presenting options and letting them decide," we're collaborating with our Product counterparts to help them figure out how to prioritise which customer needs we tackle first and how we could address them.

On the flip side, our PM can (and should) understand and challenge our technical considerations. In some of the examples given, maybe we can run a restricted set of reports or not allow certain features, or build a PoC for a smaller user subset just to validate the idea.

That collaboration needs to be built on a foundation of trust and knowledge of each others' strengths. My manager trusts my technical knowledge and my people-management skills but he'll still challenge my decisions where he may have a different context or point of view. Just as I do with my direct reports.

> Refusing to add a bathroom to a customers house because there are engineering concerns or thinking you are better at spotting customer needs than product is the opposite of that in my opinion.

> I do think that thinking you know better is unfortunately one of the pitfalls of our profession

Since I never said any of these things, I don't see any need to address them.