The point of the article is not that companies shouldnt have PM, but that you shouldnt make them owner of the innovation in a B2B context. Of course if you start with the assumption of "Good PMs" it will work, but you will rarely find these "good PMs"

One of the most important aspects of the PM's role is not to take a list of feature requests, and not to give customers what they directly want/ask for, but to understand their problem space deeply, and to use that understanding to guide the dev team to the right solution. This still leaves power in the hands of the dev team to innovate, but ensures that innovation is directionally correct. If you don't have a dedicated PM, someone still needs to do the role, and if the dev team is doing this better than the PM, they needs a new PM - maybe whoever is doing this successfully from the dev team (this was my path into the PM role as a lifelong dev).

Forgetting to focus on the right things quickly leads to an XY Problem [0], and in my experience over the past ~20 years building software, almost every customer falls into this trap, and engineers are just as susceptible to this problem as the person doing the PM role.

I some have empathy for the author as someone who has experienced working with a bad PM, but it would be easy to write a response to this post that mirrors the author's arguments while describing a poorly executing dev team and the resulting outcomes of that.

The failure modes of dev team without product thinking (whether that thinking comes from someone on the team, or from a dedicated PM) are just as severe if not worse as the failure modes of a poorly run PM org. I've seen teams spend 6+ months "innovating", only to find they did not really understand the customer problem, and what they built was never used.

The other thing worth noting here is that "innovation" is not necessarily a good primary measurement when thinking about progress building B2B products - especially enterprise products. Innovation is often directly at odds with the needs of the business buying the tool. They're running a business on this product, and they value stability and "does this thing solve my problem" far more than innovation for innovation's sake. If innovation is required to solve a new problem or to improve the stability of the business, so be it, but running a business is often at odds with dev team's willingness (even desire) to move fast/break things.

My advice to the author would be to spend some time seeking out information about good product managers. Establish a working understanding of what the role looks like when executed well. Engineering can often guide the direction of a PM org, and identifying poorly performing PMs is as important as identifying poorly performing engineers. But starting from the position presented in this article is just a complete non-starter for any such progress. It shuts down the conversation before it even starts, because it demonstrates a painfully glaring lack of understanding of what the problem really is.

And this doesn't even begin to touch on the myriad of factors that play into product decisions once the company starts to grow. Factors that no engineering team wants to deal with - pricing, packaging, putting XYZ on hold for a release to focus on ABC because there's a product-wide priority, etc.

(Disclaimer: I switched from dev to PM late in my career because the team needed a technical PM, but the majority of my professional experience is working as a dev).

- [0] https://xyproblem.info/

Someone in management decides that "we need to be product led" and appoints a product manager or owner. They then either spend their time micro managing the development process, or making unrealistic goals which don't take into account the development team at all.

I have sometimes seen good product managers - people who are engaged enough with the development process to understand the state of things, and can suggest the right direction to take development work to meet external requirements. The problem seems to be that there's not an effective selection process for them. When an organisation is "product led" that makes the product manager a de-facto team leader (regardless of what people say) which makes it very hard for the developers to hold them accountable. There's limited objective metrics you can hire them against, and the person who does hire them is often their manager - less motivated by development productivity than by the appearance of productivity.

I’m not sure if product managers at small companies and startups act this way.

At the larger companies the people who spend all their time fighting for power seem to be product managers.

It doesn’t make sense at all to me why these people get specifically hired and put into these roles. Because people who want power are defined by the trait of not listening and that is exactly what a Product manager is supposed to be an expert at: Listening.

So you hire people who are guaranteed not to be good at listening and of course you get really bad results.

I think most of these product managers choose these roles because they are more interested in power. Or their managers want power.

But I'd say over the past 5 years or so, wherever I go the expectation is that the PM must put their nose in everything and I'd have to gently, if diplomatically explain why that's dumb. I think it's the whole "the PM is the CEO of the product" which is stupid. The CEO is the CEO.

Take a look at most PM job adverts now. The expectations are insane and something only a go-getting type A MBA control-freak type would go for, with the expecting that you play an intimate role in low-level architecture decisions to leading webinars with end-users and everything in-between.

Who wants that? I might as well go start a company.

Terrible blog post BTW. Poorly written and badly developed arguments

And god help you if your product is technical and your PM isn’t technical or knowledgeable enough. Conversations get fun when the PM says something wrong and you’re now trying to correct them “respectfully” in front of customers.

As we all know from agile it's impossible for a customer to know what they want and it's the programmers job to talk to them to figure it out anyway

>> market

As Heynren Grufford said: the market can want a faster horse for longer than you can be where the puck will be

So they focus on what they think they can control.

No, you need to hire good EMs to provide checks and balances. Any system without checks and balances will go off the rails at any moderate scale no matter what you do.

Every company should be customer led. Not in the sense they tell you exactly what to build, but understanding the customers problem and then coming up with solutions. In small companies it is much easier to align everyone with the customer. When we were a small company I would send engineers to sales/industry conferences, and it was great to see their eyes open and suddenly understand all the 'odd' requests coming from sales.

This becomes harder in a large company, so the customer has to be proxied somehow. PMs and sales are the common customer proxy. But, if the engineers are being asked to do something and they don't see the value, that is absolutely a failure of communication from PMs and sales. I've also seen the other side where the engineers fight anything that doesn't fit in their idea of the product, regardless of customer or business demands. Both are frustrating.

This reminds me of a company I worked at that had a lot of rhetoric going around inverting the power relationship between teams and their managers.

Basically the "project manager" role was renamed into "project advisor", the department manager to departmental advisor and so forth, carrying the connotation that a subordinate might just choose to ignore "advice" from above.

In reality, the whole thing was a charade to bullshit people into believing they had more power than they actually had. If someone decided to disagree on any given piece of "advice", they would usually find themselves in a call with the line manager one level up and be told that they were perfectly on track for not getting any salary increase this cycle and no more promotions ever again, because of the arrogance, ignorance, and a dozen other negative personality traits, attributable to anyone who won't follow "advice".

This was soo much worse than just having "a boss". If you have a boss, you might just think to yourself "The boss is full of shit, but I'll have to implement it anyway, because that's just how it goes. He has power, I don't." But now there is this whole gaslighting element where you start to question your own reality: "Why does it seem to me right now that the boss is full of shit? Is that because I'm too arrogant to take advice? Is it because I'm too dumb to fully grasp the greater wisdom of his advice?"

Once you create a caste such as the "product managerial" caste, it just doesn't matter what you call them, and how you define their role on paper. They are going to be in power.

Because there has to be some reason why you chose to distinguish them from the engineers. The article itself seems to reflect some of the bogus beliefs that motivate why engineers can't be their own product managers: Like they are so socially inept that they can't coordinate with relevant stakeholders, and they are so far removed from the customer that they have no way of figuring out by themselves what to build. There also has to be a reason why you chose to distinguish them from the sales people: Like salespeople will just recklessly say "yes" to any and all customer demands with no idea of the cost of actually building stuff.

So what's the solution, if you think you have these problems? Apparently, to create a new caste of people. Let's call them "product managers". And because we are calling them something different, those prejudices won't have to apply to them. They won't be socially inept and removed from the customer, because we're not calling them engineers. And they won't be reckless because we're not calling them salespeople.

If you hold those beliefs, they are going to be in charge, won't they? Because you've just chosen to think of everyone else in this negative way, and put those project managers up on a pedestal. You've chosen a whole caste of people whose very reason for being is predicated on those negative beliefs about these other groups. And they'll work hard to perpetuate those beliefs, possibly even sabotage the company to make them stay true. They don't even have to be evil to act this way, just human, because is psychologically natural. Hire a full time event manager, and you'll have someone who will constantly be politicking the company into doing events, because, otherwise, why are they here? Hire full time product managers, and you'll have someone who will constantly be politicking the company into not letting engineers and sales people make "product" decisions.

The better thing to do is to go back to the original problems and try to solve them: Like, give engineers blocks of time off from coding duty, so they have time to be more proactively communicating with stakeholders. Send them along with a sales person every now and then so they get to talk to customers regularly. Give them time off so they can be trained in usability and design. Let sales people follow along with engineering status updates when you're building a feature that they promised to a customer. So they come to appreciate just how much work it is to actually build stuff. ...now there's no longer a need to have product managers, and you've actually solved problems that were going to cause trouble anyway, regardless of whether you have product managers or not.

This is quite common. Lots of ex-project managers are now called product managers or scrum masters. But they're actually project managers.

Indeed, both can create negative value for a project.

At least with engineers, we have slightly better proxies for interviewing. Leetcode sucks but it does filters out people who can’t code or grasp recursion. Unfortunately, the source of resentment towards Leetcode is that it also filters out people who can code in a practical setting (false negatives). While false positives are increasingly common with Leetcode now that tech is lucrative and people know how to play the game, people who pass Leetcode interviews can program in some capacity

(I realize the irony of this comment.)

You could argue that Lawyers are lead by their clients in the same way that Engineers are led by their end users / PMs.

The difference is that in the Doctor & Lawyer examples your end-user is very obvious because it is the person in-front of you. With Engineering you are not usually in constant contact with your end users, hence the PM role.

My comment elsewhere aligns to this: https://news.ycombinator.com/item?id=34867766

> Take your most competent sales person and put him in charge of the product.

For some reason, I’ve found lately that designers don’t want to work with engineers. This happens regardless of whether or not the engineer and designer work in the same office. Because of this, designers come up with prototypes that are more expensive to implement than what is required to meet the customer’s needs. So at some point, engineers have to have awkward conversations with designers about trimming scope.

This seems to me why we have PMs: engineers naturally avoid the awkward conversations, build half-fancy things because they have a budget to meet and “it wasn’t in the design,” and no one is happy with the final product.

I feel like there is still a better way out there, and I think it involves engineering and design both breaking out of their shells, and that’s where a PM can really help.

There’s a strong bias in tech circles to view the outliers that made it from garage to unicorn, but they’re just that: outliers. Don’t make the mistake of considering them the norm.

They seem to appreciate my sacrifice...

> There is a famous quote about Henry Ford “If I had asked people what they wanted, they would have said faster horses”. Innovation is not something you see in the data. It is someone that has intuition and most people disagree with. When you start by saying “Let's look at the data and talk to users and we will build what we see”. You are basically saying “Let’s not innovate but work on the most visible issues”.

Which actually is an indictment of, as you describe, "thinking in practical business terms".