[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.