[cmuguythrow]

Just to offer you another perspective: In all of the (B2C) companies in which I have worked as a PM (three, across two different industries), I have been closely involved in shaping and controlling the evolution of the product.

My normal month has always consisted of creating anywhere from four to twelve unique proposals (PRDs) for new features for the company to build, with the number created varying based on the size of the company and the amount of process needed as a result. But regardless, it has always looked like: "Our users currently have X problem, and we should build Y to solve it. Y looks like this...". Yes this comes with some coordination and communication challenges, but those are always in service of figuring out what to build next.

I understand not all PM roles are like this, but I do disagree that PM never gets better than "sorting/filtering/decision maturity theatre". I am curious: if you were simply ordering an existing backlog, who was defining the new items to add to the backlog?

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

[AlotOfReading]

Is that not a straight up engineering job? A good chunk of "engineer school" is practicing "customer has an issue, design a solution" type problems, in-between all the math.

[melevittfl]

Customers are rarely able to express their underlying issue. They usually communicate what they think the solution is.

A good product person is able to drill down to the fundamental problem the customer really has and articulate that to engineers.

Also, good product people should be evaluating the customers problem in terms of the whole market.

After all, engineering is a limited resource. So you need to solve the problems that exist for your target market, not just a single customer.

Of course, I’ve seen good engineers who can do this, but it takes time and effort to sift through all of the customers issues and work out which ones to solve. So product managers are focused on this to free up the good engineers to design solutions to those problems.

[sarchertech]

>Customers are rarely able to express their underlying issue. They usually communicate what they think the solution is.

In my experience the vast majority of PMs do exactly this. Half of my job since I became a staff+ engineer almost a decade ago is taking “solutions” from product managers and trying to figure out what they really want.

[gretch]

A lot of traditional engineering (civil, mechanical, etc) are non-competitive endeavors. For example, if you are supposed to make a bridge, you just design what you think a good bridge to be.

In the modern consumer application, you have to understand business concepts like differentiation. If your product is very good, but it’s strictly worse than another product in every dimension, you don’t get any credit for second place. You actually get close to zero sales because no consumer chooses your product over the alternative, in contrast to a “bad” product that does at least something very well in a niche.

[sarchertech]

Clearly there’s a difference between building a bridge and getting customers to use your free app, but the vast majority of Engineers aren’t working in big infrastructure projects. Even the ones who do are competing with everyone else who bids on the project.

And in software there are plenty of cases where the 2nd or 3rd place product gets tons of sales even if it’s strictly worse in every category. There are so many things that impact market success that are completely out of the hands of product or engineering.

[granshaw]

This doesn’t sound like any university CS degree I know of, apart from maybe a single class actually called “software engineering”, which in many cases isn’t even required

And even if it was, no, engineer personalities are horrible at designing solutions that actually meet customers’ and the business’s needs

[AlotOfReading]

The engineering classes I took were full of stories and problems centered around solving erroneous customer reports. A good example is the ice cream story [0], where a customer reports their car malfunctioning when they buy the wrong kind of ice cream, which was used as an introduction to root causing techniques. That specific story is apocryphal and the manufacturer varies, but there's an entire mythology of such stories being used to introduce topics / provide "realistic" problems / do design projects for students.

This sort of stuff is a not-insignificant portion of my job as well, since PMs rarely have the technical skills to know what's feasible as a solution anyway in my experience.

[0] https://www.snopes.com/fact-check/cone-of-silence/

[sarchertech]

My CS degree was full of classes where we had to deal with problems like that.

[solatic]

Good Product people don't just build exactly what the customer described as their problem. They understand that sometimes there's a better way to solve it. In "engineering school", you can't tell your professor "I understand what you're actually trying to achieve, so I built X instead of Y because I think it'll be better for you".

Product figures out what to build, and Engineering figures out how.

[sarchertech]

Sure you can. I’ve literally had classes that worked exactly like that. I had classes where I had to interview and observe actual customers using our product.

What you’re describing is a huge part of engineering. Engineers have been doing this long before Product Managers existed. When I started, software engineers used to just talk directly to customers, domain experts, business analysts, and business leaders.

At “product led companies” the engineers just end up trying to figure out what the product manager actually wants because it’s not really possible in most cases to separate the what from the how.

Having worked with both systems, I don’t think the way it works now is better.