[badpun]

It's just what businesses are familiar with and, frankly, what works. Before scrum you've had system analysts writing requirements and use cases, now you have product owner writing stories.

Engineers have so much on their plate fighting the actual code that making them talk to users (who don't know what they want half of the time or are involved in some sort political battles themselves) is just putting too much on their plate IMO. Maybe this could work in a smaller organisation with a fairly straightforward business, but in any place old and large, there's usually so many stakeholders involved (usually playing poor man's game of thrones amongst themselves) and so much random conflicting bullshit (in the requirements etc.) that any sane developer would be happy to just be oblivious to that.

[goatinaboat]

I disagree, based on my experience in both small and large organisations, nothing at all beats a developer spending a half-day or a day sitting with an end user saying “show me what you are doing, or trying to do”. And making copious notes then going away and programming it.

Very few organisations are willing to work like this because nearly all project- and middle-management would be out of jobs. The management class will always strive to protect itself and its members from the workers (both end-users and devs).

[badpun]

I agree that it can work in cases where the business is actually well organized and knows what they want. However, what I've often seen is that nobody pretty much knows anything and/or they're afraid to make a decision and hence you need a product manager to go around various business units, arrange workshops etc. and try to pound out some definitive statements out of the business guys. This is super common on large multi-million (or billion) projects which are supposed to transform the whole org in some way. On the other hand, if the project is just for one business unit and they're the one driving it, then maybe product owner is less needed.

[goatinaboat]

Surprisingly often they do know what they want, even if they can’t articulate it they can demonstrate it.

The spec only becomes inane gobbledygook when filtered through a PM who doesn’t understand it but rewrites it in business-speak anyway, or an “architect” who also doesn’t understand it but thinks it needs to be a grand, generic solution.