Except this is true of anyone in the company. Unless the author says who is capable of making these really good decisions this article is empty rant.
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.
Edited for typo.
There are a lot of products, especially in enterprise or B2B where the customer is not someone asking for a faster horse. They themselves are innovators and they want something they’ll use and pay for.
So there is certainly value in pouring through the data and finding the best value to build next. And for that a PM is pretty important to lead product.
* You need someone very technical to understand the engineering aspects
* You need someone politically and socially astute for the internal politics and prioritisation
* You need someone who actively knows the market, clients, prospects and competitors
Who would come up with such a nonsense? Regardless of B2C or B2B, knowing what your users need solved is crucial, irrelevant who eventually the buyer is (user vs Manager)
This is why we strive to talk to the actual users as well, to understand what the company really needs.
Some companies are worse than others, but I've got many examples of how the team manager, and everyone above, was unaware of essential procedures performed by users, sometimes even on a daily basis. Without which operations would grind to a halt.
Similarly I also have many examples of companies where the higher-ups selected a competitor without considering their users, and it all ending in tears as the product couldn't do what was actually needed for daily operations. Most of them struggle for a while to make it work, before pulling the plug and coming to us.
I don't understand, this seems to say: "all the time spent on making your customers happy is time not spent on your customers" ...huh?
The issue is, what's the scope of an efficient PM. Should they involve in product development process ? Should they involve in the UX design process ?
They seem to appreciate my sacrifice...
I am a PM who used to be an engineer and eng manager. In my engineering life, in retrospect I did PM work too - ie, orient my teams work to highest value as expressed in financial and user impact terms.
The eng/PM split is an unfortunate outcome of the fact that many engineers and engineering leads aren't capable of thinking in practical business terms, and so they need a PM in the mix to steer the ship.
The problem starts not when you get a PM but when your engineers need one.
For what it's worth, I find being a mix of the two really optimal - I am still capable of having hardcore technical discussion even as my focus is on the business, but I was doing that from the engineering seat as well.
> 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".
Also, innovation is not an end in itself. The question is do, PMs add value?
The author is right that the founder is the best product manager and should only handover to a dedicated PM once the business is ready to scale.
And then they start shitting on PMs, saying that they're not actually that smart and they only like the discovery part of their job where they get to make all the decisions. And to top it off, they say that PMs in B2B companies are useless because they're not actually talking to the people who use the product... That's literally the job of a PM, to talk to customers and figure out what they want.
And then they go on to say that if you want to innovate, you shouldn't listen to PMs, but instead put your most competent salesperson in charge of the product. That makes no sense at all.
Sadly, as someone else said, I'd assume that this article was driven by poor experiences with a PM in the past. And it's not cool to take a bash at the whole segment due to having a bad experience with someone.
Qualitative research at any company is critical and poor qual research (interviewing the wrong people, asking the wrong types of questions, etc) will yield poor insights as is the case here. Any PM working at a B2B startup not understanding the complexities of how the buyer and users differ and asking questions such as, “Would you use this feature?” is a poor PM.
Don’t let one bad experience ruin your perception of the role.
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"
I can easily flip the script and say "Devs at B2B shouldn't be anything more than oompah-loompahs" or "UI designers shouldn't be allowed to give ideas" based on a couple of my own isolated experiences.
You want to be taken seriously? Don't rant and explain what structure/methods would be more appropriate for a B2B business that would balance the need for innovation that makes users happy with keeping the paying gatekeepers willing to keep paying
Given you don't understand that the core pillar of the product manager role is to be the owner of the problem space, I'm not sure how qualified you are to comment on how valuable our role is or isn't.
Discovery isn't about decided what does or doesn't get built, it's about discovering what the real problem is that your customers need solved (almost like it's in the name).
If your PM is good at their job, the answer to that question should be pretty clear once they're done. That's not them "telling you what to do", if you want to go build a solution to a problem nobody actually has, you have fun with that.
And if you PM is defining solutions and telling your team how/what to build, that's on you to push back and take ownership of the part of the process that you're meant to be owning.
A lot of PM's end up overreaching because they're just tired of there being a leadership vacuum and nobody willing to fill it. Trust me, we're busy enough, we don't want the extra work.
I’ve had the same b2b PM woes. I even had my PM tell someone that they (the PM) didn’t really need to know how to use our product, as long as they talked to users and wrote down what they wanted into stories.
I have since taken back more product owner power as founder. Innovation is up again! So I think it’s helping.
You have never worked with a good PM then. I hear unexpected things from customers pretty much every single time I talk to one.
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/
Friends say the same thing too. It makes me roll my eyes whenever someone retorts "you just need to hire the /good/ PMs"
Even my worst sales/tech colleagues, I've never had as much conflict and annoyance as with product people
My experience of bad PMs is that they live in the Y side of the XY problem space[0] and believe they should have total say over how the engineers and designers spend every minute of their time.
Thankfully my company has a great CPO and we have agreed to avoid this type of PM. Anyone who says that the PM should be the Product CEO is not hired. Anyone who says they are the one to define how the engineering teams work is not hired.
At a truly tech lead organization, PMs work for the engineering teams, not the other way around. We have some great PMs who collaborate and provide lots of value.
It's pretty clear that this is the author's view of a PM and not what PMs actually do. It is the premise, and an incorrect one at that, of the entire post.
Imagine such hyperbole flipped around and applied to developers, this would be receiving a lot more vitriol.
I was a PM for 4 years in a startup. I helped the engineers avoid (most) meetings, I was obsessed with our customers and their pain points - and spoke with them frequently; as well hyper-obsessed with the competition and where we could improve. I took suggestions from users about what features to build next, and we built a few, and ignored others. I wouldn't bother my engineers unless management (who had a technical background) OK'd the feature after discussion and debate. I probably spent 2-3x the amount of time with my customers than my engineers. Sometimes as the PM the only interaction with my engineers was to bring them coffee in the morning while they cranked out code.
Seems there aren't many PMs like the role I played in my team. In a B2B or B2C startup, a good PM can provide structure, cover for the engineers, and a consistent look into how the product is being used, why it's used versus your competition, and what features users want going forward. A PM doing the right things is more of a design and customer support hybrid role than anything else.
That said, I don't understand why it's a bad thing to "stop innovating". If you have an innovative product that is clearly a hit with customers or users, you shouldn't aim to continually innovate past that in the short-term. You should be eliminating technical debt and making sure your core product's experience just fucking works 100% of the time. A good PM can help with that too, by putting management's ideas onto the backburner and saying "we have to solidify our product first" instead of jumping from one product to another.
Ironically, avoiding assumptions is the basis of product management.
At the end of the day, someone has to do the product role on the team. If the founder can scale that, great, and if the engineers can do it, even better! Unfortunately both options are extremely rare to find.
There are a lot of shitty PMs out there, just as there are a lot of shitty engineers or any other job function.. We would do better, I think, to discuss and promote better patterns, than trying to discredit a whole profession by clumsily reverse engineering a handful of gross assumptions and, probably, bad personal experiences.
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
This is much worse. You'll end up doing what individual customers ask, lose product strategy and run the risk of having a guy in sales deciding the next features on the fly during sales meetings, promising stuff just to get that deal signed.
Some good points here, but it feels more of a symptom of other problems, like the lack of a tech lead who manages the team (so the PM ends up doing it)
(I realize the irony of this comment.)
And if you just build what a user tells you to build, then you’re not a very good PM. Users are not designers, you go to users to get an understanding of what the problems are but users communicate problems in terms of solutions so a good PM uses the proposed solution to understand the problem and then creates a solution that actually solves that problem.
All those PMs that fancy themselves mind readers in that they believe they can define what the customer needs and what the developers should build, without hearing their perspective first, are just bad managers with a different name.
I am not sure what really happens after Product Managers come in that the product takes a dive. I have seen this repeat almost everywhere. You start with a small team of engineers and have a product that people love, now you need more engineers and hence you bring in a manager and managers almost always demand to have a product manager and the whole thing devolves into a game of promotion.
Doctors are lead by Senior Doctors, Lawyers are lead by Senior lawyers, whereas Engineers need handholding that also sucks the very joy out of engineering.
In my opinion, What could be more beneficial is to have Product Managers who also are senior engineers and who atleast do hands-on development 10% of their time. This is exactly how even the senior most doctors still perform surgeries.
unless it is customized B2B or B2G, where the engineers are not really interested in the mundane chores of the nitty gritty of a drop-down or having to have constant arguments on what the button should be called, you likely dont need a ProductMgr.
The other thing that happens as soon as productMgrs enter is engineers let go of the ownership of the product. The back button doesn't work? well good luck, that was not in the PMs requirements. now raise more unnecessary tickets and show the improved velocity.
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.
Is that the fault of a PM?
Sometimes this is a Product Manager, but just as often it’s a VP, or someone in Sales, or someone in Customer Support. It can even be multiple people, who all echo and amplify each other’s description of what the customer really wants.
It’s a very easy pit to fall into once a company has some success: Everyone’s busy, the product has a clear direction, and the customers are paying. There’s a lot of unglamorous work to be done, but it’s much more fun to go off into a room and work on “design” or “vision” for weeks and months. Any attempt to bring reality into the is met with “This is what the customer wants.”
This can go on for years, especially at profitable companies.
1. He is wrong, PM are not at all like that
2. He is wrong, ofcourse that is what PM does
3. He is wrong, the criticism is written the wrong way
Amusing…
The most successful product company doesn’t have Product Managers.
Saying this as a product person.
My comment elsewhere aligns to this: https://news.ycombinator.com/item?id=34867766
It only sounds like PMs have all the power because they put the tasks in the order that you work on them in, after haggling with all the other stakeholders.
I'd guess that the PM in the story trying to get some evidence to backup a decision/convince someone of something.
I think it says more about the disconnect between dev and product, than the actual sins of product people.
> Take your most competent sales person and put him in charge of the product.
I think it says more about the disconnect between dev and sales, than the actual sins of sales people.
Investing in Design+Engg gives maximum return. These two disciplines have other ones around them like project management, overall product owner (PO, General Manager), etc.
It is really weird when one sees PMs being mentioned as the one who talks to customers or users.
Usually designers were doing that right from beginning, going back to half a century or more..
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.
>If you are a startup B2B founder, I want to give you one piece of advice, don’t ever give a lot of power to product managers as long as you want to innovate.
The article seems to make the point that PMs both love exploring and finding out what people want but also that they don't and that is the issue.
It seems the author started by arguing project managers are all over the place, and (my line of thinking) that B2B companies therefore should be focused more on execution and delivering, not just finding a bunch of cool new tech/ideas to pursue.
But then in the next few paragraphs they diverge by saying PMs actually stifle innovation because they want to look at data and improve things. They don't actually want to imagine something brand new.
This makes no sense. I would agree that in a B2B environment, you want things that work, not a shiny new UI and new products every couple of months. Businesses are focused on revenue, not flashy new things like consumers might be. They want to know if it works. And if you're selling to other businesses, reliability is far more important than new features. Why does everyone use SAP and Oracle? It is certainly not because they innovate.
I think the author just got very confused with their points and didn't know how to argue against PMs, but they clearly have a vendetta.
The worst PMs I've worked for aren't the ones who stifle innovation. The worst are the ones who encourage it to increase the feature factory appearance to make their own CVs look good. The best ones gather and present the data to inform the decision that the team has to make.
But in terms of power, yes there needs to be an emphasis on them being facilitators of the conversation and not the decision-makers. As Devs (QA, DevOps, SRE etc) we need to make sure that it isn't a one sided decision and learn to argue without undermining or name-calling.
> First most product managers believe that the most important thing to do, is to interview users, look at data of usage, and then take some obvious bet to take the best decisions
Heaven forfend! We've got to put a stop to that sort of behavior. I agree with the author, people should be making big, incomprehensible bets without talking to users or looking at data first.
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.
Product folks who don't have domain experience always seem to fail, no matter how hard they work. Their opinion is not trustworthy on important topics. To compensate for their obvious lack of merit, they HUSTLE. They fall into the trap of crowd-sourcing ideas, insisting on design patterns that make no sense, and micromanaging a project to death with story points. They pathologically avoid any tough decisions (because deep down they know they don't have the skill or knowledge to make them) and prefer to focus on small tractable tickets that they show visible progress. No matter how well they run their processes, their lack of domain experience will almost ensure poor quality.
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.
The actual boundaries tend to be a bit fuzzy because a lot "product management" comes down to doing whatever the team needs in order to make sure a good product is delivered, and by necessity product managers often do a substantial amount of project managing.
Typically you'll see people conflating "program management" and "product management" in tech. You don't usually see "project management" in that mix since that tends to refer to a more industry agnostic discipline.
The key responsibility (and purpose) of a product manager is to provide a coherent vision of what the product needs to be successful and define what the ongoing projects' goals should be to effectively improve that product.
Engineer - how to build; project manager - how to organize building; product manager - what to build.
(and I don't think they are personnally incompetent - quite the contrary; but in my experience, it's the managerial process that is often designed to generate incompetency as a side-product)
A PM's job is to be the owner of the "problem space", while the engineering teams job is to be the owners of the "solution space".
Fords point was that his customers would only ever tell him about solutions they wanted (faster horse). When in actual fact what mattered to Ford was the problem (current modes of personal transport being expensive, unreliable, uncomfortable, slow, single-person).
Any good PM should be able to explain this to you. OP has never worked with a proper PM apparently... Just BA's and Project Managers that wanted a pay bump.
Don't get me wrong, they do a lot and it's all valuable. But even they can't tell me what their fundamental role responsibility is hahaha.
Project manager handles a discrete undertaking with a beginning and an end that falls outside whatever your org considers “ongoing operations.”
Program manager handles a portfolio of interrelated projects. If a lot of projects are failing and you want a single throat to choke, the program manager might be a good person to replace.
Product manager seems like it could be interpreted as kind of like a program manager (for a large, complex set of inter related projects) or a project manager (if there’s only one project) except that the organization’s ongoing operations include the creation and development of the product, instead of the product being a single event/discrete undertaking.
Source: read PMBOK decades ago
[0]: maybe others who learned differently can chime in? Doesn’t seem like this terminology is universal.
This kind of apologizing for horrific behavior undermines what I thought were otherwise strong points.
Should PM's be better at not steam rolling engineering teams? Yeah, 100%, it's literally the #1 thing that I consciously work on when it comes to personal development and self discipline etc.
But it would also help if engineering teams were more... I want to say "aggressive" when it comes to solving new problems and building new solutions.
I get that "new features" is seen as a PM thing and we always get shit for pushing "new features" over things like fixing tech-debt. But for 95% of products, "new features" are going to be a very consistent reality and often they're responded to extremely negatively by engineering teams, even (and some times especially) when those engineering teams are placed in the drivers seat to come up with the solutions.
It doesnt mean they are bad PM or good PM, innovation requires just fundamentally opposed skills to the standard product management ones that we see in books.
Trust me, we deal with so much psuedo-emotional garbage every day that stuff like this just slides off our backs.
My point is that you obviously don't actually understand what a PM's job is, so you probably shouldn't be telling everyone what they can and cannot do.
As a PM I've been the one that's lead some of the largest and most successful innovation focused initiatives that the companies I've worked at have ever delivered. In some cased delivering revenue uplifts totaling 20-30% of the companies entire income.
Engineers don't have a monopoly on innovation. Innovation is what happens when a great solution is paired with a nasty problem. For at least one half of that calculus, most companies need good PM's.
This is a bit like encountering an engineer who isn’t very good (or maybe it’s just a lack of experience) and then concluding that the engineering org should not be allowed to control architecture based on that experience.
Or encountering a dev team who goes off and builds some complex feature that no one asked for and then concluding that dev teams should never have a say in what should be built.
The existence of bad PMs or bad devs (or good PMs/devs executing a misguided plan) shouldn’t be used to justify a general sweeping argument about either discipline.
It was a hybrid role that every org did differently, and it was confusing to everyone and made it hard to separate product focus from execution focus.
Last year they split the roles into Product Manager and Technical Program Manager (TPM), and PM’s had to elect which role/title/path to choose.
This is at least true for the Experiences and Devices and Cloud and AI orgs.
Source: work there now, have been there 6 years.
To me, it always felt like it was supposed to be an intentional "product" role as opposed to "project", but you're right that it basically was a hybrid where they worked on product but also helped manage the project itself.
A PM is an Air Traffic Controller - not a dictator.
For example, I tend to be the guy on the panel all the other PM's hate because I taught myself to code so that I could have deeper empathy for how my engineering teams work and now I advocate for all PM's needing to be at least moderately technical.
Rocking the boat certainly doesn't make you popular haha
Also, Product has in some places gone from a valued member of the team to a ruling class, with all the faux problems that generates.
It's a funny one!