The product manager role is a mistake

My current company is full of smart people, and (for a variety of reasons) we don't have product managers. It sucks. What happens is that the things a PM does do not get done. Very few engineers want to maintain relationships with customers, interview users to identify potential features, manage leadership, play politics for resource allocation, and so on. So it doesn't get done. That's what happens there.

At my last company, where I worked for about a year, I had three product managers. Two of them were fired because they were incompetent. One was really, really good (tremendous, in the parlance of this article). Our team still got more done in a year with a fraction of a good PM than my current company has gotten done in over two years without any PMs.

I agree with one thing: there aren't enough good PMs to go around. My belief is the number of people cut out to be a good product manager scales linearly with the size of the population. You need certain personality traits and other qualities that can't be taught. You can mint mediocre PMs in school, but you can't make good ones that way, let alone great ones. The problem we are dealing with is that the software industry did not scale linearly, it exploded exponentially, and it needed 100x the number of people wearing the PM hat than there were actual, bonafide PMs in the world.

And the alternative is, "hire good people but not with the PM role"?

It reads like someone had a bad experience with a PM who thought they were Steve Jobs. PMs are just ordinary people, I don't understand this supposition that anyone holding the title is going be an entitled douchbag. An org can have thousands of PMs, each with a superior.

Just a weird article

Here's a list of what they tend to do:

- gather information from users on what is/isn't working for them

- gather information from executives about what needs to be done to keep the company working

- gather information from industry leaders who may or may not be part of the company about where the industry is going

- work with design

- take all 4 previous points and distill them into what actually needs to be built for a needed feature

- work with engineering to figure out what is practical, vs not, for building, and how long approximately it will take

- work with engineers / higher ups to remove features that take time but don't add as much value.

- work with engineers to ensure estimation and team velocity is more or less predictable

I've probably already described a 1 and 1/2 jobs. Now if you take product away, each of the above gets distributed among the engineering team, and not everyone in that team is good at it. And even if they get to a good homeostasis, one person leaves and now there's a non-obvious gap that we're not interviewing for.

Some people will often break the boundaries of those roles, though, and that's ok. They have ideas and might even come up with their own job titles. An organization must be smart enough to let that people grow and thrive. That doesn't mean one cannot thrive as a PM, or do great work; it's just that an organization usually cannot invest time in deeply knowing who they're getting onboard and so offer precooked roles.

I took, naively, a product manager job at one place I worked, thinking it would finally give me formal control over the product that I'd been previously asserting through influence - very successfully - in my client-facing sales engineering role. Of course as soon as I got in the chair I discovered it was a highly-constrained clerical job that I was completely unsuited to. Managing tickets and a backlog; coordinating decisions instead of making them; writing interminable powerpoint reports; the most creative thing was putting together a process for the company to follow in formalizing its product roadmaps. I lasted six months before running away.

The function is quite useful in supplying some visibility into what's getting built and in managing conflicting priorities for a growing product, but one thing it is not is shaping or controlling the evolution of the product in any way. It's a sorting, filtering, and (if you're lucky) a data collection function, producing an auditable decision trail and an impression of maturity in decision making which helps the MBAs higher up sleep a little easier.

> Tremendous people envision alternative realities, fully commit themselves to their work, and move mountains with their willpower.

The last part is so reductive. It's not willpower moving mountains. It's the underlings actually making the vision come to pass. At most the "great person" is aligning the incentives to motivate the actual doers and experts.

My feelings so far are mixed. I've worked in PM-heavy organizations before and I agree that those suck. But at the end of the day there is some work that a PM would do that still needs to be done. In my org that responsibility officially falls into Software Managers and Senior+ Developers.

For example, if you are leading an initiative for your team as a Senior Engineer, you are in charge of doing all the activities that a PM would otherwise do. For other activities, the Manager or Senior Manager of the team is in charge.

Suffice to say that as a developer this sucks. Not only you need to deliver your own work as an IC, but you need to coordinate other people and ensure that things get done. Not only this is extra work, but let's be honest, many developers don't have the skills to be effective PMs. It also makes inter-team collaboration difficult, since now you have to coordinate people that don't share a reporting structure with you.

Often this approach results in lack of ownership, lack of accountability, duplicated efforts or things falling between the cracks, and general disorganization. That being said, it tends to work well for small intra team initiatives involving a few people, since it removes the overhead of a PM and places control in the hands of builders. But for larger initiative, I'm not quite convinced it works.

But: The author hand-waves the solution into oblivion:

"There’s an alternative model that works. You hire everyday great people. Each one needs to be great at something, obsessed by their craft, and driven by quality. You then put them together in a team, without individual responsibilities, ensuring that there’s minimal overlap in areas of greatness. And you pay them to have fun doing what they love doing, in exchange for putting their time and skills at the service of your company."

I mean, come on. That sounds lovely but can anyone point to a successful company larger than 100 people where that actually works in practice? (HOW could it work in practice?)

I view my job primarily as risk management. A great team of engineers and designers will face a huge number of risks to shipping great products, like not having the right skill set to articulate their vision to get others on board, or having lawyers impose requirements or restrictions on what can and cannot be done. My job is to manage that, to help bring out the best in the team so they can get on with the actually important work of building and shipping great products.

I judge success by how redundant I am. My goal is to not be needed, for the team to have the right context, confidence and support to make good decisions without me.

I love working with engineers to level-up their skills so they can do just this; I work with my EM partners to understand the strengths, weaknesses and goals of each engineer, and try and find ways I can help them progress.

In an ideal, utopian world maybe I’m not needed. I can understand that argument. But in most cases, doing truly great things will run up against challenges and risks, and a good PM works in partnership with their team to overcome them and is a net value add.

There is a function many (though not all) software teams need whereby someone understands customer needs, prioritizes them, and translates them into something that can be worked on by developers. We call that role "Product Manager". Do you strictly need an MBA who has some specific certifications to do that? No, of course not. A very strong UX researcher could potentially do it. A very strong engineering lead could potentially do it. But for many products, it requires a significant time investment in understanding the problem space, guiding a UX/UI research/design team iterating through solutions, and documenting it in such a way that a dev team could approach it.

As someone else commented, the article is just "Hiring bad leaders is bad".

That way you don't have "product" people who are really just status reporting for the team, or "product" people who are really just writing bad tickets that need rewriting. You have actual product people who focus on where the product should be going.

You also don't have a "delivery manager" role. The team needs to be steered into doing this by a decent lead who can do the 3% admin required to keep on top of this sort of thing.

Also, I've found it a lot easier to reason about organizational issues if you don't fixate so much on "great people." More and more people enter the workforce with the idea of competence as a "ladder" being firmly ingrained in their heads. It doesn't work that way; people succeed as a function of who they are and the environment they're in. Your "smart person" is often totally useless somewhere else (see, for example: the huge numbers of FAANG-ish employees that struggle to do anything in smaller companies, and vice-versa.)

I found this entire article to read like it comes from the heyday of "only associate with people as _great_ as you want to be", which I think (a) was terribly reasoned and (b) hasn't really worked out that great, especially for the people who followed this advice.

This is different from the "Product Manager" at other companies which typically "owns" a product's direction and has authority over the people building it. That mixes project management with people management, politics, and worst of all, ego.

I never worked with an EPM at Apple that caused interpersonal problems. They all just wanted to fix bugs, figure out what we could and couldn't do in a specific timeframe, and release products on schedule. IMO, this is one aspect of Apple's organizational process that other companies should emulate, but I've never encountered it anywhere else. Maybe this kind of thing can only work at large companies that can afford to hire people for such a well-defined role.

Every company relies on the quality of its people. Every company puts people into positions of responsibility. Any company would suffer if people abuse or cannot handle their responsibility. So what? Is this some kind of insight? No.

Incompetence is a problem regardless of role, and it’s more of a problem with more powerful roles. The author gives no reason why “product manager” should be his special target.

The author seems to think the solution is… teamwork? Really?

That’s it. Problem solved? No.

This article is part of a genre that extolls the amazing power of the group without discussing or acknowledging all the excellent reasons why hierarchies are so immensely popular in industry compared to self-organizing hives.

Most articles on teamwork assume the happy path. Speaking as a person with skills, experience, and strong opinions— I know what it means to collaborate with difficult people. I am one. Any company that consistently thrives with an egalitarian culture must either be tiny or it must develop a sophisticated and sober culture of conflict management. Ironically, only with strong leadership from the top can that be done.

What you are building, why, how you price it, how you speak to the market about it, how you position yourself in your category, how you partner with others to provide a better solution (either services companies to provide a turn-key solution or other software companies), how should you should allocate your engineering resources to best increase revenue, etc. And these questions touch almost every department in the company, so they have to be great communicators.

Just a few areas I routinely see bad PM's skip:

- Sales / Partner Enablement (awesome, you built something, but it doesn't matter if the field does't understand it or can explain it and its value)

- Market research / segmentation (are you building the right stuff for what you are targeting?)

- Creating new products / SKUs for opportunities within your existing target market/segments (growth)

- Identifying new/adjacent categories to develop products for (growth)

- Balancing building for today's customers vs building to get new customers

- Pricing/packaging (I'm not talking about physical product packaging)

- Build / buy / partner analysis

The Pragmatic Management Framework is a nice framework really shows the breadth of what a PM should be doing:

https://www.pragmaticinstitute.com/product/framework/

I agree that there are tons of bad PMs out there. But allow me to summarize what a good PM does:

Talk to customers; either to dig deep into their use case, deescalate a situation, figure out solutions, or conduct research. Monitor the rest of the market. Plan launches, pricing, and coordinate with sales teams, etc. - I had Product Marketing staff before, but they missed context and delivered bad experiences. I find it way harder to find a good product marketing manager than a good product manager. The PM is the DRI (Directly Responsible Individual) and therefore takes a lot of shit. The PM acts as a filter so you can continue doing your job. A good PM can even write a line of code here and there. Prototyping is part of the job. Roadmap, strategy, vision, build vs. buy... often the center of friction between what the business wants, what customers want, what the business can afford, and what engineers want to build. Finding a middle ground. You are right; these are not skills you learn in school. A PM wears a lot of hats. People with a solution architect or engineering background with a customer-facing element to their past tend to have the best chance of being a good PM. But by no means is the PM job an unnecessary one - do you want to figure out how to price a product and be responsible if sales can't sell it? I hope you come across a good PM in your career.

'Just hire great people' - what's new?

PS: The success of a PM highly depends on the engineering culture. If engineers are convinced all PMs are useless and they have no real job, or as a real-life example: engineer thinks A, PM shows data that shows B, but engineer just thinks the data is wrong and will do A anyway... it will be a highly frustrating collaboration for both. Please keep an open mind.

To me, great products are a result of having a leader in the company who brings strong vision, customer focus, prioritizing the needle movers, and assembles the right technical talent to turn concepts into reality. This leader "gets it", and they make the tough decisions.

So while simply having a PM doesn't ensure these things, it doesn't necessarily prevent them either. Once you scale, the PM function brings much needed order to chaos. But if a company is relying purely on IC PM's to bring the vision, focus, needle movers, leadership, the company is flying blind as it's a signal that the founders / execs / board are absent. And that's a bigger problem than not loving your PM.

The real problem is unrealistic roadmaps filled with top-down strategic initiatives which are often made up by leadership with very little rigor—all in the pursuit of growth at any cost. The bad PM is an emergent property of that system.

I think it goes one step too far and throws the baby, the bath tub, and the whole house with the bathwater.

> Do you know what else they had in common? None of them were motivated by OKRs, KPIs, data, or other people’s opinion.

This is not true for Bezos for example. He was famously driving the company through data, metrics and process, and there's countless examples of "Jeff meetings" where he changed his mind after reading the data presented by others.

All those examples are tools, that you can, and often shouldn't use. It makes no sense to have a heavy process when you're small, in direct touch with the customer, and are fully driven by an idea. Similarly, it makes no sense keeping on wet-fingering it and single-person driving once you have a set of established customers and want to increase your penetration.

Same is true for all aspects of a company, from engineering to sales to marketing. As you grow you get more people working, and you need a minimum of coordination and standardization to avoid going in antagonistic positions all over. And same goes with seems between these functions. Let me tell you that I prefer having a good PM to handle these needs and that coordination rather than having to deal with synchronizing their needs as an engineer.

I went in there hoping I would have a good resource to share about the topic, but it's too sour and mono-directed into some weirdly "aw common just be smart about it" to be credible. Ironically, the conclusion of the article (no structure, just smart people everywhere) contradicts one of its central argument (everything doesn't apply everywhere).

At Google product managers became the worst aspect of the entire company. They spent their time arbitraging credit, cutting off communications between builders and executives, and generally appearing for a while, not taking ownership, then leaving after they fucked up the roadmap so badly they couldn’t fix it.

They became the worst kind of leech on the company.

But then in starting my own company, PMs who need to own, execute, and deliver on a triads goals has become invaluable. It shortens communication pathways and distributes responsibility.

So I dunno I’m at a loss.

You want to build lasting success on good process, good organization and responsible management. People come and go. Organizations stick around.

I also saw astute comments from folks that recognize that if the product manager role does not exist as a distinct role, someone else in the organization has to take on the work of determining what to build and when, based on market and customers needs - usually engineering or product marketing. There is nothing wrong with that, btw, just different way to slice the same pie of responsibilities. Finally, several folks rightfully pointed out that a product manager (person accountable for building the right product for the market) is very different from a project or program manager (a person coordinating internal activities).

The only thing I'd add here is that product management roles can also be very different, depending on the stage of the company (early stage vs late stage), the type of product it builds (e.g. B2B vs B2C), and the industry vertical. Looking at the author's LI profile, he seems to work for larger companies, in the financial sector, in the UK. Perhaps in that world (which I perceive to be a fairly rigid, regulated industry), the role of the product manager is quite different from what I have personally experienced working as a PM in the Bay Area for early and mid stage startups.

The engineers are most connected to the tremendous energy. Have the most idea of potential & costs & a savvy for appreciating what is most directly possible, sharp intuitive angles towards mechanistic sympathy/finess. But are made to mete with all manners of checks, have their will impeeded. Bargained down ongoingly from doing good.

There's definitely a lot of being a junior engineer where you want or need direction. The more formal org's high-structure is good here, is predictable. But on the whole, I think companies have become far lesser for being so managed. There was a great thread recently where the discussion turned to middle management, and it was great if sad hearing such stress & strain mirrored about. I will fucking haymaker you if you mention agile again, https://news.ycombinator.com/item?id=37894676

- micromanagers of tasks and features

- insightful data munchers

The first group is usually a bunch of people citing Marty Cagan, talking about continuous discovery and running in circles. They are not helpful and sometimes hurtful to performance.

The second group captures business and market data, process it and create insights from it. They keep the engineering effort focused. Those are very helpful.

This is just my personal experience, of course, but I'm yet to see a third type.

EDIT: to be fair, Marty's books seem to advocate for the second type.

I believe the author must have worked with PMINO or Product Manager in Name Only. AKA, when companies hire Product Mangers (let's call them PM uppercase) and make them program managers (pm, and please this isn't me demeaning program managers by using lower case- just a differentiation).

A PM is in charge of setting product vision and realizing it. A pm is in charge of ensuring that happens by aligning resources. Both are really valuable parts of the team, but they are different roles. I don't believe it is good to mix the two because they are two distinct set of skills.

The PM is the war strategist who understands opponents' weakness and opportunities to strike for the campaign's success, while the pm is in charge of staging the battlefield to ensure those tactics can be carried out by keeping the battalions equipped for success. I know military analogies aren't everyone's cup of tea, but just using what I know.

The best PMs I've worked with were purely product focused. They didn't engage in resource alignment and dealing with middle managers. The best pms were purely managers. They engaged in working with engineering managers/directors to ensure the right people were working on the right initiatives. They kept schedules on track and helped everyone stay sane with the work that had to be done.

Maybe I am wrong too, but this is what I believe is the right approach that I plan to employ at my company. When the company is small and only a single engineering team (like 5 people total) I don't think there's any reason to have a pm. When there are multiple teams and distinct organizations, you really need pm so the PM can stay focused in their role.

I think you need to tailor each group and their process carefully, depending on available talent pools and the complexity of the work being attempted, and sometimes you will need active management of requirements to achieve better outcomes. If your process grows faster than the core coding team does, you probably do have a negative process jerk happening you need to disrupt.

Maybe you'll get better results by not calling people 'mediocre' to start with, as if that's anything but a hateful subjective label.

There are two types of effective PMs in my experience: the visionary who shapes the product, and the exceptional "team cat herder" who adeptly manages outward from the team: KPIs, regulatory reviews, and similar things. Whether this person should have a different title is irrelevant: That's the title they have and the role they take.

When a PM like that departs, these duties don't vanish; instead, they often become the responsibility of engineers, adding to their workload.

Product manager is such a weird term that can mean absolutely anything, and putting manager in the title leads to the expectation that PMs are supposed to be running the show instead of working cooperatively. The Customer advocate should be just one voice among many when making decisions.

And after nearly 20 years of building software, I have come to the conclusion that it is completely impossible to be an expert in generic “Product”.

Clayton Christensen knew this all too well and calls this sustained innovation. In other words, to just make incremental improvements to a product to maintain a position in a market.

What this article is pointing out is a classic innovator's dilemma, in which the product manager role is unable to live up to the necessity to innovate and follow these great ideas of great PMs.

Overall a great article because it calls out the 10 dysfunctions of product management as told in books like "Build what matters". Especially this thought:

> Anyone with even a speckle of greatness eventually leaves. They either get pushed out by the mediocre dictator, or they leave on their own terms, as the environment has become intolerable to them.

The irony from my experience is that there are great people who want to do great things. They want a great PM and they want to follow a compelling vision. The modern day challenge is what companies are starting to identify... Vogons. "not actually evil, but bad-tempered, bureaucratic, officious and callous". Also known as middle management.

The simplest thing I can boil it down to is how they respond when asked a question. With the exceptional PM, when you asked a question you got an answer.

With bad PMs, you ask a question and you get "Good callout! I'll try to get some alignment with our stakeholders on that". Every decision point spins out into this web of stakeholders and cross-functional team buy-in. And no decision is ever made, everything is always in flux and uncertain. During this process they have produced an entire literature of documentation, each version contradictory to the others. "That feature was only in the original doc, we got rid of it in v2" but also "That feature was in v1, I forgot to copy paste it into v2 but we never canceled it. Sorry!" Every variation of every feature exists somewhere, a kind of superposition of the product out there somewhere.

It consistently amazes me that they never seem to be able to grasp how self-destructive this is to the product development. Or maybe they do, but they just don't care and they are just exploiting their evaluation framework. Probably the latter.

Used to be we had two or three people responsible for owning the product design. Coherence of design, despite the name, doesn’t come from a single mind. It comes from a mind that is challenged at every turn to be better. I had a friend in college who had a love-hate relationship with Stephen King. He was a fan, but lamented the fact that King refuses to have an editor. “Great beginnings, terrible endings,” was how my friend described his books. And “he needs an editor, even if he doesn’t want one.” And repeated it at the end of each book he read. Which is how we end up with King saying the Movie Ending for The Mist was better than his ending. Nobody to push back. Nobody invested with the power to call him on his bullshit.

We used to have companies with a leader of engineering that insisted on what success would look like, a leader of quality that insisted on what corners we could not cut, and a leader of development that insisted on how we were going to get there. Now we have a product owner trying to be all three and doing a shitty job at two of them. If you’re lucky.

In traditional Kanban, everyone has a veto, a strong cultural drive not to use that veto unless it’s necessary, but as soon as it’s necessary. In Scrum the illusion of adaptability is an opiate for the masses. Agile theater for a process that has become almost entirely and practically Lean. If you think you’re doing Agile when you’re doing Lean, you’re gonna have a bad time.

Problems with PMs generally boil down to "they're not very technical" (mostly irrelevant, because there's much more to being a successful PM than being arbitrarily "technical"), "they're just a project manager"/"they're just a status update monkey", which does happen depressingly often. However, this "prod-ject manager" archetype is generally something imposed on the PM by a company that has no interest in having anyone do actual product management work. The "all metrics all the time" people do, of course, exist. There's a place for them in bigger companies that are primarily optimising what they've got, but they won't last 5 minutes at a lot of companies.

So much of what people criticise as bad product management (or, but extension, bad product managers) is actually a systemic lack of product management at all. Leaders hire the wrong type of people for a role they have no interest in supporting, with inevitable results. However, are we expecting that these same leaders are going to make A-grade hires in engineering? In my experience, the engineers who complain most about product managers are the ones that would benefit from (good) product management the most.

I worked at a mobile game development company for a couple years. While the industry was young, they had some really big hits and grew to be mid sized. While I wasn't there for that era, talking to the people that were, it was mostly driven by passion and people that cared about games, and while they monetized well it wasn't the focus.

However, they had a couple of misses after those hits. This is pretty normal in game development, although in my opinion those misses were mostly about being too ambitious: way too much tech requiring cutting edge phones, tools that were still not mature, team sizes that were larger than they knew how to handle, etc.

So, the founders stepped down, and they were replaced with a new C-level staff that came from the gambling industry, mainly slot machines.

These people LOVED the numbers, KPIs and all that jazz. They loved showing those numbers to the staff too, which credit for being transparent but realistically a group of creatives are not generally that interested.

The problem was, since every decision required "data", innovation became impossible. Have a cool idea out of left field nobodies done but everyone is excited about? Can't be done, where's the data? But we can make a match 3 with a familiar IP! Who cares that we're just copying the market leaders and entering the space once its already saturated.

Anyway, the company folded two or so years after that. It was a shame because there was a ton of talent there, but the C level management just did not understand the industry, how to get creatives excited, and they did not care about games. They just had "data"

If you think you can identity people with good taste, and incentive them properly to make the product better, and give them control to act on their taste, then you should do that. But you probably can't. One of the pieces is probably missing. Maybe you can't measure product quality very well. Or maybe you don't have good taste for people with good taste. Or maybe you don't have the authority to give someone control over the product.

The article gets at what I just called taste for good taste. It doesn't make sense to create a product manager role if you can't fill it with someone who has good taste concerning the product. Often, companies will get the PM roll wrong on multiple fronts: bad taste, and no ownership. At that point you've just hired on another voice adding noise to product discussions.

I usually see PMs get soft authority, but not a budget.

However, I’ve worked with excellent product managers that can break down features and work through modeling sessions with strong understanding of what the business needs and what stakeholders expect.

It’s a silly article from an inexperienced person.

One problem is that Scrum jargon uses the term "product owner." That might have been intended to give that person more influence, but the effect most often is that real product managers assign junior people to that role and it becomes the "features check-box accountant."

Real product managers should be directly engaged in product development teams because, if they are any good, they have clout with senior management and can grok concepts like minimum viable product, especially the viable part.

I can understand the frustration with mediocre product managers. But that's a symptom of being in a sub-scale organization that can't hire great product managers. If the senior management don't see that and engage better with their product teams to make up for it, you're screwed. And Scrum jargon often adds to the problem.

    - Why is a company equated with one product?
    - Without a "product manager", or, since I prefer scrum terminology, "product owner", who determines the direction of the product development? Who decides what the most important thing to work next is, and where to focus company resources? Who is responsible for making sure that the product is valuable, and that whatever developers work at any given moment serves to maximize its value?
    - Without a single "product manager"/"product owner", who decides which of the multiple competing requests to the team takes the first priority?
    - With the attitude of "hire everyday great people; each one needs to be great at something; you then put them together in a team", how do make sure that individuals you put on a team work toward a single goal, as a team?

I wont hire a PM now that isn't also a contributor during work or in their spare time. Not only should they be excellent leads, they should be able to get down and dirty actually move the needle, design something, write code. Run their own damn prototype and test.

A big part of my current role is just empowering more Jr PMs to contribute more by educating them on certain skills, but it doesn't scale and none of them have the drive to study the subjects on their own.

I envision a shift coming. Ive never subscribed to the bullshit, but Im personally moving away from much of the "PM activities" and spending more time on my original skills, design and engineering...

I can relate with that.

I was working on an operation that has the incredible track record: 74% of reliability (in a daily batch), 2 Engineers to serve 12 Analysts, stack running an old version of Haddop and Spark (2 majors down at least) and the company hired a technical PM.

The first measure of this PM? Setup meetings with consulting behind our backs, plus tons of politics with upper management, and the cherry on the top was he thought that was a good idea to move the Data Engineering team to a Front End team since “it’s more or less the same and a developer is developer everywhere”.

Final result: everyone quited and he eventually was fired with 1 year of delay.

my take about all this and every other role is, it doesn't matter what roles and titles and processes you give people

if they suck

or if they're all great at what they do but cannot work together as a team (VERY common in tech where everyone has superiority complex towards everyone else)

the output will suck

teams composed of people who are good at what they do (they don't have to be tremendous) AND can work well together as a team kind of run themselves and don't reaaaally "need" pms or any other formal role - they just need goals that make sense to them and they will execute with speed, quality and efficiency

meanwhile not even the best PM/tremendous individual in the world can save a team composed of people who suck or are great but can't work together as a team

I do agree with the red-flag symptoms like KPI and other “measurements”, and I’ll go as far as to say it’s extremely difficult to find a great PM and the field is riddled with mediocre ones.

In my several decades of software engineering work, good product managers were almost non-existent.

Today I’m working with one who has a strong competitive streak, is quite smart, and deeply understands our users and competition.

I’ve been making sure to give her stellar feedback during reviews and peer feedback, as I know how rare this combination is.

Edit: Reading through the responses, perhaps I should reconsider. The expectation of the role and responsibilities are misunderstood and misaligned to what businesses and engineering teams actually need.

That is to say, my team PM’s a success despite the role and not because of it.

The problem here is that the skill involved with being a PM are equivalent to janitorial jobs. Anyone can do it. Anyone can have intuition on how they think a product should work. This is not a high skill job. The work itself is not easy, just unskilled. The person in this role has to spend ALOT of time diving into the purpose of the product and thinking of new features... etc. Anyone can do it but not a lot of people are WILLING to do it.

What makes this role hard to find good people for is that it's hard to quantitatively measure how willing a PM guy actually is. Instead we end up measuring the persons political skills. How good is that person at making you THINK he cares about the product? And that is the metric and bar you need to be good at to land the PM job. Politics is a hard skill. It's hard to measure and it's hard to train for.

What happens is we try to measure skills in one dimension but politics and charisma can cover it all up. People can bullshit their way past everything. That's why algorithm questions are so pervasive in the industry. It's a way to cut through the bullshit specifically for software. It's a blurry metric but it is effective at removing a certain level of political bullshit.

For PMs you can't cut through the bullshit. Evaluation of the PM is directly through an API that is literally bullshit politics. The more charisma and the better you are playing politics the better you will be perceived at being a PM.

So what you get are a lot of shit PMs who are managing more politics than product. If the product doesn't do well, the PM is usually skilled enough in politics to redirect blame away from him. Both hiring for a PM and keeping a PM job is just a process of filtering for political skill.

A good example of a really good PM is Steve Jobs. But note his PM skill was orthogonal to actually keeping and holding the PM position. He got his own ass fired. He only came back because the company became desperate. This rarely happens in the real world where a fired PM will come back to his old job.

Someone has got to care about the user and the business.

It can be much worse with a project manager who doesnt care about the user, doesnt care about the business and is just trying to complete tasks per sprint without any focus. It is even worse when the project or program manager has no technical background and doesnt understand what it takes to build something.

In each role, product, project, program, and all the other lead roles (technical), it takes people who really care.

I can guarantee that if you start being responsible for actual PM work for an extended period of time, you will start drafting your article about “they ask us to do too much, we need time to focus”

Working with other humans at scale is inherently difficult, we all take turns being the solution, and we all take turns being the problem. Such is life.

The solution is to not be rigid with the role. Have the person do whatever they are best at doing.

This is not just a PM thing. If you hired a developer and it turns out they are not good at coding but are good at DevOps then let them do DevOps full-time, offloading DevOps responsibilities from other developers.

It sets up a strawman of "delegating control to a single person", and assuming that person is either an engineer or a PM. Everywhere I've worked, the product teams/leaders and engineering teams/leaders were peers. Engineering didn't report to product, and product didn't report to engineering. Rather, both reported directly to the CEO, often as separate CTO and CPO heads, or they both reported to an executive VP or director or similar.

Because the reality is, you need both. Engineers are great at building but they're not spending time with customers or UX research to know what the market and users need. The main job of a PM is to understand what the market and users need by spending a lot of time with customers and researchers, and to marry that with the business priorities coming from executives. And then a PM and eng lead negotiate back and forth to figure out what can be built that meets everyone's needs.

The idea that a product manager role is a mistake makes as much sense as saying an engineering lead role is a mistake, or a sales lead is a mistake, or a marketing manager is a mistake. A successful business needs all parts.

(Occasionally you're building a product that's by developers for developers, where the engineers do have an accurate understanding of users/market, and a PM isn't necessary. But that's exceedingly rare.)

These are the systems that run the world in banking, finance, education, transportation, consumption, production, manufacturing and supply chain amongst others.

Stakeholders are internal and a Product Manager role really doesn't apply. I think it important to differentiate between types of software endeavor and much of the discussion here seems to view the software world and the need/role of a Product Manager narrowly.

That would be like putting Paul G on this list. Neither of those two are applauded and loved in the mainstream even if they are both rich and extremely smart.

That a Product Manager may seem "in charge," of development is incidental to the role, and not the purpose of it. The role exists to discover features and scale them to customer demand. Managing means "to extract value from," and a lot falls into place when that lands.

There is IMO no correlation between being mediocre and being put off by intensity and passion.

Overall I think this article generalizes a lot. I can't say for sure that the article is not applicable to a certain part of the industry, but it certainly doesn't in any way represent my experience.

PMs can be good, bad, or anything inbetween. I've never experienced that a good PM was not a benefit to a project.

Most of them worked on failed projects within a much larger company. The failure was due more to bad management of large Corp rather than them. One is a VP at Apple today. Gotta say my career hasn't really shot to the moon by staying in Engineering. Food for thought.

----

Here is a nice story from a former MS Excel's Program Manager

"My First BillG Review" by Joel Spolsky

https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...

There are many many bad PMs who are either dead weight or actively drag down their teams. But most eng and design teams are so much more inept and slow without any PM that even a mediocre one clearly improves velocity (if not effectiveness).

But have seen companies from inside that totally went downhill because you could sense that product tier is totally clueless. They know nothing of the domain and if anything, pretty superficial. Have no spark, interest or intuition of what will work and what not.

May be this was limited to my own sample size. Great products are out their and they didn't fall from the sky.

That’s a silly bar to put before hiring someone to be a product manager.

Andy Jassy started as a product manager at Amazon and is now CEO of Amazon. Product thinking and working backwards from customer needs (and not forward from technology), is not just a big-tech concept, but applicable to every business big or small.

These are not the attributes I would associate with success or appreciation in any role.

Project Managers can also be very useful in a complex project that spans departments but that’s a completely separate role

Baffling argument. Not everyone has to be a visionary. Hire Picasso as your corporate lawyer, see how that works out for you.

the problem is noone says no - everyone says yes to what the PM says, because of politics.

The closest they had was Steve Jobs and Product MARKETING Managers, which are quite different than Product Managers.

"People are hired based on whether they’d represent no treat"

I think author means "threat".

them being the list of leonardo, steve jobs, peter thiel etc..

the part I quoted just isn't true

----------------------------------------------------

Based on sentiment analysis of the comments:

    37% have overall positive sentiment towards product managers
    28% have overall negative sentiment
    35% are neutral

- Go beyond surface-level feature requests and dig into the root problems customers are facing. Observe real customer workflows and pain points. Identify the jobs-to-be-done and where the product is failing users.

- Collaborate closely with designers and engineers early in the process. Avoid tossing requirements over the wall. Co-design potential solutions and conduct design sprints together.

- Develop enough technical literacy to understand architectural constraints, make feasible suggestions, and earn engineers' respect. Take coding courses, read engineering blogs, attend tech talks.

- Focus on high-level goals and strategy rather than tactical execution. Don't micromanage - empower teams to determine solutions.

- Avoid reactive mode and spending all time in meetings. Block off strategic thinking time and deep work.

- Learn enough about data and analytics to identify leading indicators and qualitative insights. Don't just fixate on vanity metrics.

- Interview users, customers and frontline employees to build empathy and an outside-in perspective. Immerse yourself in the customer experience.

- Prioritize ruthlessly. Challenge teams to focus on true differentiators versus commodity features. Relentlessly cut scope.

- Focus on business impact and outcomes over outputs. Tie roadmap to company OKRs and strategy.

- Simplify and streamline processes that don't clearly add value. Remove unnecessary bureaucracy but maintain just enough process.

- Build relationships and credibility with engineering managers and team leads. Avoid throwing weight around.

- Develop storytelling and communication skills to paint a compelling vision and explain rationale.

The key is focusing obsessively on customers, leaning into strategy over execution, and enabling teams versus controlling them. PMs create the most value through vision, prioritization and strategic clarity.

> Picasso, Jeff Bezos, Mozart, Steve Jobs, Nikola Tesla, Elon Musk, Robert Oppenheimer, Peter Thiel, Leonardo [... would be amazing PMs]

I beg to differ. Mozart died at 35, completely indebted after years of excess drinking. Jobs ousted from his own company after poor strategic decisions and intolerable behaviour. Picasso / Leonardo were geniuses of their own without need for co-workers.

> None of them [geniuses mentioned before] were motivated by OKRs, KPIs, data, or other people’s opinion.

Wrong. We know from another genius, Kurt Gödel, that even intellectually brilliant people struggle with procrastination. In Gödel's notebooks we find a multidimensional planning system (goals for the day, week, quarter, next year) and clear OKRs ("finish preparation of Princeton lecture until end of this month").

> The enormous mistake you can make is to adopt a model that requires tremendous people, without having these tremendous people.

Again wrong. Great discoveries are made by employing great discipline over a long time, not by hiring some rock stars. Why else would Elon Musk call one of his most ambitious ventures "the boring company"? Why else was Katalin Kariko, who "invented" the Covid-19-vaccine and received the nobel prize for Medicine in 2023 ousted twice from Penn University, because her research was deemed "not sexy enough" for grants?

In some companies, they are essentially project managers who groom the backlog and coordinate releases with support, and (ideally) take a variety of coordination tasks off of engineers plates. At the other extreme, they're pure concept+strategy, and (ideally) provide a clear vision that allows other teams to understand where they are going and allow them to prioritize independently.

There's a few other dimensions I could probably name, but wherever someone sits on these dimensions, it is possible for them to be bad at their job - either because they're a mismatch for the job they have or because they're just not very good.

This isn't unique to PMs, of course - I have worked with a lot of engineers who are bad at their job for the same reasons. And I could s/product manager/software engineer/ in the linked article and recognize a lot of the same negative behaviors and patterns.

I think one of the reasons there are a lot of bad SWEs and PMs is that roles that were once only appealing to people who were genuinely passionate about what they were doing are now considered general purpose desirable careers. When I started working in tech 25+ years ago, most of the people who were entering the software industry found computers and technology deeply interesting, and enjoyed working in the space. When product managers started to appear as a more defined job function, the best PMs were experienced engineers, marketers, etc. who cared about and understood their users, the business problems, and could help drive things forward as the landscape became increasingly complex.

Today, there are a lot of people who enter software engineering and product management who are not particularly interested in the work. It's just a job, it's just pushing bits or paperwork around, and while many of those people are still effective, it can engender the behaviors depicted in the article.

That doesn't mean the role is a mistake, especially since the article depicts the most negative version of product management: "These PMs you hire have no vision, charisma, expertise, strong beliefs, or technical skills."

That's the problem right there - the role of a product manager is fundamentally about driving clarity. That clarity could come in the form of better requirements, customer understanding, a strategic focus, and yes, even things like metrics and goals (if they are clarifying!). If a product manager is not providing clarity, they are bad at their job. If an engineering team knows with exact clarity what they should be prioritizing all the time, they don't need a PM.

Product-level thinking isn't confined to PMs. In fact, a good engineer should be conversant on the most important aspects of the product they work on, and care about many of the same metrics.

Having a good product function in a company can be very impactful when it comes to scoping and prioritizing, validating ROI, understanding what success looks like, and ensuring that people take into account the real cost of the work they do.

Sometimes this means making sure that engineers aren't just building things they think are fun but pose no real ROI, or asking engineers for things they don't feel like doing, or -- the gravest of all crimes -- asking for status on in-flight progress, perhaps even in person. This is why these folks draw the ire of some of our less mature fellows.

Ahh Red Queen strikes again! Such is life

I hesitantly have to give Elon Musk credit for proliferation of EVs and - yes, highly questionable - because of finally completing DARPAnet’s original mission via starlink’s usage in ongoing Ukraine war… (yikes, lot of “offset” should IMO be considered; on many ”fronts” with his business ventures actually).

But for what should Peter Thiel be worshipped again? Especially in comparison with the rest of the list?

At the end of the day, someone needs to have a vision of how your product is going to be successful and can walk the team along that journey. Back in the day, and in small companies today, that person is often the engineering manager or even the technical founder. In large companies, this is the primary response of the PM.

The reason is that engineering managers who can also “do the product” thing are rare, both because there’s certain personality traits and skills that are required but not common and it takes a lot of bandwidth.

For example, in my first job as a PM, I traveled to 20+ countries every year meeting with hundreds and not thousands of clients and prospects to really feel out my product’s place and opportunity. That investment of time and breadth of “perception” put me in a really good place to lead my product.

It’s hopefully obvious that I wouldn’t be able to do that and also be responsible for careers of 50+ developers, technical direction etc, so yeah I had to be a PM, not an engineering manager, to operate like that.

In terms of impact, the most junior PMs take load off engineers. Eg: they go to the customer and write down what they ask for. The engineer could do that themselves but it’s deemed a better investment of their time to keep coding, so the junior PM is thrown at it to free them up. A middle level PM talks to a bunch of customers and defines a solution for their biggest problems (in contrast to the junior who depends on the customer to tell them what is needed in what order.) This PM synthesizes customer information into something different and hopefully easier to deliver and more scalable. This is where the skill set diverges from engineers. At the most senior level, the PM anticipates the kinds of problems their customers will have down the road and acts as a “visionary” to get the solutions built proactively.

PMs obviously can be asked to do other jobs, like I’ve often seen them tasked with running sprints etc. it’s fine if the PM or someone from engineering does it but in neither case is it a required part of the job and is better done by a project manager who is more inanely focused on running processes.

Another way I like to describe what a PM does - they are the teams interface into the world, on the hook for turning external ambiguity into internal clarity. They are on the hook for driving priorities with the team and that doesn’t just mean customer priorities. For example, sometime a purely technical thing can be the most important thing to work on and at other times the same thing could be a waste to address. The PM should be able to help the team understand which situation they are facing.

All this btw explains the massive pay disparity in PMs across seniority and across companies. Some companies view PM as that “leverage to engineer” model I described above which by definition pays less than the engineer. On the other extreme companies see senior PMs as the strategic leaders of multi-billion dollar product lines.