[scrumper]

My experience was B2B. I was certainly expecting a lot more of the problem identification and solution generation work that you described.

The difficulty was that the owners at the top had unshakeable ideas about what the product should be. That's ok, single minded vision can be good and all that. In my very hands-on sales engineering role I'd make things that my prospects were asking for, put them in the product, they'd buy it, and my prototypes and hacks and tools would end up getting refined, hardened, and supported by the implementation team. It worked well because everything I did had big dollars attached to it (so the org itself didn't mind) and the product advanced in a way that the market wanted.

The problems arose when we put in the product management process - the whole committee/requirement/signoff thing the article describes and I mentioned in my earlier comment. That created a formal bureaucratic mechanism for various players to stop all the ideas I had. Before, they'd be fait accomplis necessary for winning a big deal. Now they were just ideas divorced from value from some guy who should've known his place. Back then I was hopeless at understanding how to get a group of people with different agendas to agree on something (I think it's called 'politics').

> if you were simply ordering an existing backlog, who was defining the new items to add to the backlog?

It's over 15 years ago but what I remember is that there were thousands of semi-structured documents which represented things that, with the new product org, got turned into backlog items (stories, epics). This was part of an attempt to move engineering to a more agile way of working while creating a product function to support it. So it's more that we didn't have a backlog as such, then we stood it up and triaged everything we already had into it. All this was happening while the company was trying to learn about agile. I remember day long meetings where we all tried to argue about whether technical tasks belonged on a backlog, and if not how you could write a user story for remediating a piece of technical debt. Basic stuff but none of us had a clue.

[Nathanba]

>The problems arose when we put in the product management process - the whole committee/requirement/signoff thing the article describes and I mentioned in my earlier comment. That created a formal bureaucratic mechanism for various players to stop all the ideas I had. Before, they'd be fait accomplis necessary for winning a big deal. Now they were just ideas divorced from value from some guy who should've known his place.

precisely, the introduction of a PM means that the people who actually implement the product are put below pure talkers. You suddenly go from being able to influence the product daily to everything being up for a vote and every vote being overriden by the PM. The PM gets to decide which issues are important enough to be included even though he really doesn't know better 99.9% of the time. 99.9% of the time he didn't talk to customers about it, he just has his own opinion and was put into this artificial leadership position that ruins the fun of the job for everyone else. Oh sure he talked to leadership but that ends up being about how to achieve his own dreams and goals, certainly not to help make the ideas of engineers a reality. I've literally never seen a PM that goes and asks what ideas of the engineers we can help make reality. Just let that sink in for a moment: Isn't that what a product is? Ideas of engineers? I mean it really is. The whole agile movement is one of the strangest gaslighting ventures that human psychology has ever produced. We are told that there is no boss while actively being micro managed issue by issue, hour by hour almost, while literally being asked every single day in the standup when X will be finished.