[sirwhinesalot]

I share the exact same thoughts. a good PO is worth their weight in gold. PMs are often more of a detriment than anything. Developers should not be cornered off from customer needs, quite the opposite, they should be made intimately aware of them.

Not only is seeing customer struggles a strong motivator for why they do the work that they do, but it also helps with coming up with good solutions.

A poorly thought-out task list that needs 10 refinement sessions before it is actionable is very much not that.

That said, devs are not sales people, that's why the PO is there, and the PO could very well have "PM"-like people under him to handle the customer connections before getting devs involved, but that's different from the "PMs define user stories" approach I see everywhere.

The result of that is that the PMs end up in a managerial sort of role (the name doesn't help) where they boss around the PO who in turn bosses around the devs until they get fed up with the relationship and the dev lead starts pushing back, and the whole thing turns antagonistic.

[ghaff]

I agree but let me provide some perspective from hardware system product management a couple decades ago.

We did indeed make an effort to bring engineers into customer meetings when it made sense. However, you end up with tradeoffs.

- Bring select engineers into a few customer meetings at your company location which doesn't take a lot of time and does provide some outside perspective. The downside is that they get a very filtered sample which it's easy to over-generalize on.

- Make talking to field people, customers, etc. a significant part of their job and you're essentially making them product managers, at least in part, and they don't really have the time or focus to do nearly as much active development.

(Note that this was rather long-cycle hardware development--though software wasn't really much different. There really wasn't a lot of methodology to product management at the time except whatever internal processes we put in place.)

[sirwhinesalot]

Yeah option 2 is pretty much a no go because of what you said, so it has to be option 1. Ensuring bad generalizations don't happen would be the PO's job in that case I suppose. If there was an obvious solution we'd probably have converged on it by now, but at least where I work the PM/Dev relationship isn't really optimal in any way. Unclear tasks, pissed off devs, messy project, etc.

[ghaff]

Back when I was a product manager, I really was the product owner in so far as I was the point person for the field, owned pricing, attended product reviews, had at least a big say in launch decisions, wrote/reviewed external comms, coordinated with field engineering, etc. But, as I say, product management meant something different than it does much of the time with modern software. I never had any specific training on it.

Sometimes we did bring engineers in to have deeper technical backup for a specific discussion. Most of the value though was probably to provide some sense that we weren't just making things up.