> The consequence of that is interviewing users in B2B is almost useless, and taking decisions from what users tell you is a severe error and in most cases the path to stagnation.
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)
The issue with B2B is that the decision makers are not the users of the product. You need to convince the decision makers first, as otherwise you'll not sell. Hopefully, the decision makers value user requirements as well.
In my experience with B2B, the higher-ups don't really know what's actually needed by the company. Just one step up the ladder and important operational details are lost.
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.
You need to be talking to Users, Customers and Stakeholders and be clear about which is which.
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.
It is because product managers should only be hired at the company after post product-market fit. And they innovate usually not in creating the new product, but improving the existing one, or identifying the possible new product to be created.
This is a poorly written article that is all over the place. It’s evident the author had a horrible experience with a PM. Their description of a PM is a description of a PM who’s doing their job poorly.
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.
Well I agree that this is poorly written (I wrote it).
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"
Paul, it’s a bad article. Your arguments don’t make sense and are mostly strawmen. If you want to improve it, show it to someone in real life and have them talk over it with you. You’ll probably get a lot farther than a few sentences of feedback over the internet. But it’s really bad.
100% what others are saying. This is a hot take rant with bad arguments based on an experience with a bad product manager (or maybe you're just difficult to work with and your ideas aren't as innovative or as good as you think).
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
In this whole article the word "problem" is only written once, and it's in the line "the problem with product managers is".
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.
Sorry if you took it personally or you think this is a rant. This is clearly not the case, I can repeat it, PM have a lot of value, but there is one specific area that we shouldn't give them control over.
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.
> but there is one specific area that we shouldn't give them control over.
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.
Going by this article and the rest of your writings it's hard for me to think that this 'one specific area that we shouldn't give them control over' isn't really 'whatever area polote happens to be in right now.'
I didn't take anything personally. IMO your implication that I did just feels like another attempt to straw-man PM's.
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.
It's not meant to be apologising, it's meant to provide context so that engineering teams can be more comfortable pushing back and retaking control of the solution space.
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.
Imagine feeling qualified to write this article without knowing the difference between a project manager and a product manager. Imposter syndrome indeed. Thinking you are the correct person to evaluate a “PM” without knowing what half the letters mean is pretty amazing, leaving us to wonder what would happen if this person ever were to encounter a program manager.
Let's be fair here... I consider myself a pretty proficient Product Manager and even I would struggle to tell you what the Program Manager in our Org is actually meant to do.
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.
On the other hand you’re not out there writing slam pieces on project managers, so I don’t think your lack of clarity around these terms is causing anyone any heartburn. And yeah these terms are a little under-differentiated in some shops. How I learned it [0]:
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.
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.
I don’t get all this criticism. It’s a rant, I personally enjoy a good rant so thanks! Now everyone saying you don’t understand the role? Hogwash, most companies and their management are incompetent and don’t understand the role either, they simply hobble along on their “chaos is a process” BS. I read this as one of those. It happens, a lot.
Yep. It's no longer a rant when a recognizable pattern emerges.
(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)
Presenting a dichotomy of "Developers aren't social and product managers are" says a lot more between the lines about the author than the actual words advance any argument.
It also matches with my experience fwiw. The biggest issue I saw with qualitative is that it almost always was used to reinforce an existing idea that the PM has. I've never heard a PM say they learned something surprising and are reconsidering their initial idea.
It's possible I've not worked with a good PM, but the fact remains that I haven't seen the industry _incentivize_ the "good PM" behavior you're describing nor have there been consequences for "bad PMs", so does "good" and "bad" really mean anything?
There are lots of companies where talking to customers is a requirement for a PM to have continued employment. I’ve worked for more than a few. Seems to me that’s a pretty significant incentive.
This piece would be better titled "Startups stop innovating when they have poor leadership", and reveals a fundamental misunderstanding of the PM role and the nature of the problems the author is witnessing.
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).
This guy gets it. Thank you for taking the time to write this up properly, the failure of OP to understand the PM roles relationship with the concept of a "problem space" is a fundamental misunderstanding of the role that never seems to go away.
This post makes some wild assumptions, like the fact that B2B PMs only interview customers, and not end users. Also, that they mostly build what people are saying they want to have.
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.
> There are a lot of shitty PMs out there, just as there are a lot of shitty engineers or any other job function
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
As soon as an article states you can use “product manager” and “project manager” interchangeably, you can immediately assume the author has no idea what they’re talking about. Convenient this article did that early on, saves everyone a lot of time.
This, plus if you see them mentioning the Henry Ford ‘quote’ about horses you can reliably close the browser tab because they’re about to build a straw man argument against doing basic customer/user research.
Isn't it nice that those meme-like anecdotes, or whatever they are exist? Other examples are the Maginot Line in WW2, Amazon was never profitable, ERP systems suck because of their sales reps playing golf with their clients...
Interesting, I’ve always thought of this quote justifying deeper user research than just asking users what they want, not less. I’ve seen people who don’t really understand user needs over index on what they say they want versus deeply understanding their workflow and needs.
The quote is designed to make you understand that building products is about understanding problems, not listening to desired solutions.
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.
If you go by volume, you may well find that the theoretical definition you're referring to is outnumbered by the practical reality. I definitely wouldn't assume that reality matches theory.
I'm going by my personal experience as a PM. To be fair, whenever I talk on a PM panel I tend to be the odd one out.
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
Yes - totally agree. It's a tricky job, and there are real product people, of course, but I think there has been a bit of a migration away from the slightly unfashionable "project manager" into roles such as this one, flooding it.
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.
That would fall into the realm of product owner, who are meant to keep things in-line with committed timelines and keep teams working on outputs, different from product managers as they have significantly less headache and scope of responsibility.
Within the tech sector, project management refers to the set of competencies and tasks around coordinating projects - a lot of stuff around task tracking, reporting progress, unblocking problems that come up, and so on. Product management refers to a set of competencies and tasks for making sure you're building the right thing to solve the right problem. Tasks like conducting market research, user research, and crunching product metrics/analytics generally fall more on the "product" side than "project" side.
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 project manager is to manage and organize the execution of a project so that it achieves the goals which were defined for that project.
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.
Why has every product person I've worked with been obsessed with controlling teams and communication rather than obsessing over the customer and the market?
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
Because those skills require actual experience and domain-expertice. You can't factory print MBAs that actually give you skills, but you can create the illusion of value by teaching something, so they throw out a bunch of random econ and ways to control employees and everything gets a little bit worse everytime someone graduates
Unfortunately, domain experience is no panacea. Dealing with product people that don't understand technology but do understand the domain is equally as frustrating.
This. Some product folks know their industry well and have actual hands-on experience building something in the same ballpark. They are a joy to work with. Even if they don't do their job particularly well, you can ask them real questions and trust them to make reasonable decisions. They have an intuitive sense of what does and doesn't work for the target audience.
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.
I’ve seen this in dealing with Microsoft. Product Managers at these companies all have a type A personality in general. If you want excessive politics and everyone fighting and being a dumb ass it’s the product managers at big companies.
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.
I worked there for 13 years and worked with a lot of people with the title of Product Manager, or "PM" to be specific. And no, we didn't call them "project managers".
Ah, you got me there. My apologies. You're right. I had forgotten that it was "program" and not "product". (I haven't worked there in a few years and probably mixed it up with product manager titles at a different company.)
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.
They think it’s their micromanagement that creates productivity. Sometimes it’s incentivized by upper management. The more noise they make the better they seem. So for example, a micromanaging PM will demand that all communication go through them. It can certainly help, but oftentimes adding a third person to a loop complicates things, not helps. Now there are three schedules to align! But the PM has to seem busy and productive so it’s better for them to be involved when it comes to optics, productivity be damned.
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.
I've seen "product" done badly at multiple companies. I've still not seen it done very well. I think the problem is structural. Of all the areas of software development process that get cargo culted without careful consideration of actual effect, product management is the worst (with "scrum" a close second!)
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 got into product management maybe 10 years ago. At that time, it was more the bridge between sales and engineering, and you manage the technical marketing. You let each department work the way they work best and the roadmap is collaborative. Some places still have that but they are dwindling.
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
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 product person I’ve ever worked with in depth has been obsessed over the customer and the market, and if anything they tend to get frustrated when circumstances require them to think about internal communication instead. I don’t know where the gap comes from but I can testify that the good PMs people are telling you about do exist.
The idea that someone that is good at making decisions that make a company successful would always start their own company is wrong on many levels. Running a company is about much more than making a product successful. There’s all the nitty gritty stuff that constantly bogs you down from legal, tax, finance, interpersonal stuff in the company landing on your plate. Some of that can be handed off to an accountant or lawyer, but you still need to learn at least the basics of it to understand what they’re trying to tell you and decide based on that advice. You need access to capital, sometimes a lot. Your risk profile is entirely different than as an employee. Many companies just fail with a total loss. Many people can’t afford a total loss.
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.
While my experience has lined up with the content of this post, I also think the conclusions only apply to a narrow set of organizations and products.
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.
> 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. Take your most competent sales person and put him in charge of the product
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)
> Second, most product managers are not smart in the sense that they make good product decisions. Anyone can be a product manager, you just need to pretend to know how things work and have done other things in the past. Product managers really rarely evaluate themselves on the KPI they have achieved in the past. And finally if you are really good at taking decisions to make a company successful you will have started a company of your own a long time ago (Not everyone want to create their own company, yes I know, but the high performers do :) )
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.
Where to start with this. All I will say is that the job of the Product Manager is if nothing else, to manage the product through the product lifecycle. Concept, development, release, revision, maturity, retirement/death, including likely migration to some new product/service that is a logical replacement. These core duties are most clearly exercised in small product-lead companies. In large firms the job can become very bureaucratic and political as everyone wants to put a hand on the ships wheel, especially if the company is a single-product company.
This is great advice. I think people are reacting badly, because they are skipping over the word "competent" and attributing a lot of malice to the word "sales".
I think it says more about the disconnect between dev and sales, than the actual sins of sales people.
The funny part is how the article starts off with how others are missing the point, and then the article continues to completely miss the point. I didn't know you could put that much bias and wrong assumptions into such a few paragraphs.
The writer's trying to argue that product managers aren't useless, but that they have too much power. Okay, sure, but they go about it in the most confusing way possible. They start off by saying that developers who think PMs are useless are missing the point, which is fair, but then they go on this whole tangent about how PMs are actually important because they can help with decision-making and project delivery..?
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.
> What matters is to make your customers happy, and sometimes, and pretty often this is not needed, so all time spent on it is time you will not spend on the most important people, your customers.
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?
"it" is what USER wants, as opposite to customer. One of the key takeaways from the article should be that in B2B the customer is often is not the user.
Devs working directly with customers will always be better than relying on PMs to do it. But it's hard to find devs with the soft skills needed, and are willing to do so.
I imagine there's a lot more going on behind the scenes that the author realises. If it's a single product startup a PM will be getting pulled in different directions by sales, marketing, tech, clients and investors. All who have their own agenda, all of whom may want different things.
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.
This article is terrible. Lots of speculation and biased opinion, with absolutely no facts or alternative team structure suggestions. It's more of a rant.
As an engineering leader, I tend to agree that giving Product Managers too much power causes lots of problems. A big one is retaining good engineers.
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.
"PMs work for the engineering teams" made me cringe. This statement is no different than what the article is preaching, just another flavor. PMs and Engineering should work together. PMs #1 role and why they should even have a job is bringing customer clarity and urgency. Being a tech-led/product-led organization is just another version of sales-led organization. The ultimate balance is being customer-led which many companies/teams don't fully understand. But I fully agree with the "product CEO take" - as a PM I hate that framing.
> At a truly tech lead organization, PMs work for the engineering teams, not the other way around.
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...
> At a truly tech lead organization, PMs work for the engineering teams, not the other way around.
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.
The only good PM that I ever met introduced himself like this: My job is to answer product questions when the developers ask me and then confirm those answers with our customers.
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.
147 comments
[ 3.6 ms ] story [ 210 ms ] threadWho 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.
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.
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.
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.
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.
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 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.
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.
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.
(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)
https://twitter.com/alain/status/1625297691617169408
You have never worked with a good PM then. I hear unexpected things from customers pretty much every single time I talk to one.
A PM is an Air Traffic Controller - not a dictator.
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/
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
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.
This is quite common. Lots of ex-project managers are now called product managers or scrum masters. But they're actually project managers.
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!
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.
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
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.
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.
Ten years of experience at various startups, and it is absolutely this way.
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.
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.
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.
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
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.
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.
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.
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.)
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.
Edited for typo.
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.
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.
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...
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.
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.
0. https://xyproblem.info/
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...
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.
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.