B2B startups stop innovating the day you give power to product managers(blog.luap.info)
blog.luap.info
B2B startups stop innovating the day you give power to product managers
https://blog.luap.info/your-b2b-startup-will-stop-innovating-the-day-you-give-power-to-product-managers.html
147 comments
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"
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"
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
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.
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.
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.
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.
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.
> 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.
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've worked with good and bad PMs and this jives with my experience.
> 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.
This kind of apologizing for horrific behavior undermines what I thought were otherwise strong points.
This kind of apologizing for horrific behavior undermines what I thought were otherwise strong points.
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.
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.
What is the horrific behavior, here?
[deleted]
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)
(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)
I think the article had some good points.
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’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.
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.
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.
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.
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.
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.
> I've never heard a PM say they learned something surprising and are reconsidering their initial idea.
You have never worked with a good PM then. I hear unexpected things from customers pretty much every single time I talk to one.
You have never worked with a good PM then. I hear unexpected things from customers pretty much every single time I talk to one.
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.
"Talking to customers" is "good PM behavior"? Isn't that like saying "writing code" is "good developer behavior"?
Additionally, as a PM, I hear unexpected things from my engineering teams to and they very often change the course of an initiative we're running.
A PM is an Air Traffic Controller - not a dictator.
A PM is an Air Traffic Controller - not a dictator.
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.
[deleted]
Great headline though
B2B startups stop innovating the day you give powers to developers (video)
https://twitter.com/alain/status/1625297691617169408
https://twitter.com/alain/status/1625297691617169408
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).
- [0] https://xyproblem.info/
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/
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.
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
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
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.
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.
It's just hard in general. So it will feel messy from the inside.
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’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.
You’re aware that Microsoft didn’t even have a Product Manager title until last year, right?
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".
How did you work there for 13 years and not realize that Microsoft “PM” was neither product nor project, but “Program”?
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.
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.
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.
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.
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
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.
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.
Unfortunately, domain experience is no panacea. Dealing with product people that don't understand technology but do understand the domain is equally as frustrating.
Those with the domain expertise stay away because of this culture.
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
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
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.
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.
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.
>> customer
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.
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.
>"you just need to hire the /good/ PMs"
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.
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.
Many "product" managers are actually lower level project managers. Some companies don't know the difference.
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.
0. https://xyproblem.info/
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/
"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.
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.
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.
> 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 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 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.
> 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.
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.
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.
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.
[deleted]
> As soon as an article states you can use “product manager” and “project manager” interchangeably
This is quite common. Lots of ex-project managers are now called product managers or scrum masters. But they're actually project managers.
This is quite common. Lots of ex-project managers are now called product managers or scrum masters. But they're actually project managers.
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.
Yeah but the fact that OP buys into the trope that they're the same thing kinda speaks to the point that they have no idea what a PM actually does.
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
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.
It's a funny one!
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!
What are these two roles about? What differentiates them? Asking genuinely as someone not in the tech sector.
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 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.
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.
I've seen PMs "scope creep" themselves to boost their CVs for when they leave and go somewhere else. These PMs suck. They are the type to lead meetings
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.
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.
This is marriage material. Well said.
Music to my soul.
can I hire you?
Yes! I saw a bit about your companies, and not sure where exactly I'd fit in, but always down to have a chat. My email and linkedin are in my profile.
I just though that was a funny comment, but now I'm going to reach out for real.
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.
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
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
> 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)
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)
It sounds like you haven’t ever worked with a good salesperson.
(I realize the irony of this comment.)
(I realize the irony of this comment.)
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.
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.
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.
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.
Most good software out there were started by engineers and not by product managers and engineer only products are generally great and liked by people. Linux and the ecosystem is one example.
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.
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.
> Lawyers are lead by Senior lawyers
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.
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.
It’s not quite so obvious in medicine. The patient often isn’t the one paying the bill, so the insurance company or government is the actual customer. In that regards, it’s more like a B2B transaction.
You mean lawyers are led by Partners at the firm.....
Product Management is often a role where a lot of strategic business decisions and operational product decisions collide.
A product needs to be innovative and relevant for a market but even with our tools today everything built for the future is a bet, so it is risky. Most PMs are not C-Level, so they are not allowed to take that kind of risk. So they manage a small box of possible pathways with low risk and low gain.
So as soon as you shift all strategic decisions (a product owner in a software company is not far from a business owner) to the PM roles you limited the future development of your business to this small box.
Is that the fault of a PM?
Is that the fault of a PM?
I think the article and most of the commentators are missing a real problem. The real problem is that there is an underlying complexity, which has no simple solution - collaboration of teams/groups of people with different expertise and even different interests is a universally unsolved problem.
When a company passes the "startup" stage and gets real customers, it isn't a startup anymore. It has more tasks to handle and needs more people to work, people with different expertise. There are sales, operations, developers (with multiple expertise), lawyers, coordinators (of all kinds). Innovation is not a self-evident target, at some point startup needs to cash innovation.
There are frameworks which attempted to address that complexity, for example scrum or more flexible superset "agile manifesto" or even waterfall. They all may work or fail, but there is no guarantee, no recipe.
There is an anti-pattern I’ve seen at many companies I’ve worked for over the years: I’ll call it the “No-longer-in-touch customer proxy”.
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.
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.
"Who watches the watchers ?"
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.
At an early stage startup the founders are the product managers, and if they are bad at it, they won't get funding or revenue.
Well, he really struck a ligthning rod, people here seem to be arguing that,
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…
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…
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.
Those people are generally referred to as product managers
LOL somebody's PM told them to stay on task and stop making up features out of thin air
AFAIK Apple doesn’t have any PM roles for their major products. Think about that for a second.
The most successful product company doesn’t have Product Managers.
Saying this as a product person.
The most successful product company doesn’t have Product Managers.
Saying this as a product person.
I can easily imagine that.
My comment elsewhere aligns to this: https://news.ycombinator.com/item?id=34867766
My comment elsewhere aligns to this: https://news.ycombinator.com/item?id=34867766
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.
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 pretty wrong, but look at the upvotes. It obviously speaks to a lot of people.
I think it says more about the disconnect between dev and product, than the actual sins of product people.
I think it says more about the disconnect between dev and product, than the actual sins of product people.
And if those engineers read to the last line, I think they would pretty surprised at the author’s conclusion:
> Take your most competent sales person and put him in charge of the product.
> Take your most competent sales person and put him in charge of the product.
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.
I think it says more about the disconnect between dev and sales, than the actual sins of sales people.
Agreed and that hacker news readers may not be any different than the average news consumer, going on title and no content when forming an opinion.
Though mentions enterprise space (B2B), should mention that in hardware and software consumer product companies the product manager roles does not show much value.
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..
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..
I agree that design+engineering is the optimal team structure.
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.
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.
> ...to facilitate decision making, make the project move forward. This is what is called “delivery” in the product management discipline. And this is usually the part that “Product managers” hate doing. The other part is “discovery”, it is meant to discover what to build, and this is the part that “Product managers” love doing.
>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.
>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.
In the startups I've worked at, where they start hiring in product people, the point in time that normally happens it that critical t0 point. Basically, where the innovation will have to slow down, because you need to stop thinking about just coding the solution but start on the build pipelines, tests, infra, support, analytics, feedback loops... And yes, you can think of these things on day one, but it is that point, t0, where you need to actually have those things defined (even if it's simply a wikipage that has"No" written on it). And that is the point of bringing in a PM.
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.
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.
+1 on this. People forget product development is a collaborative process. If a PM is just chucking work over a fence, they’re not a PM. They can’t be doing their job effectively if they’re not spending as much time with developers as with customers.
This is overstating the case by a lot. I guess I agree that innovation should not come from the management layer of a company, organization and motivation should. But, I have worked with great PMs who multiplied the effectiveness of their teams, and they were indispensible. A lot of people who should not be PMs end up in PM roles, but I wouldn't generalize that to the whole profession.
> 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.
> 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.
> 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
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.
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.
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.
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.
Product manager - person that screwed up Evernote.
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.
Edited for typo.
Edited for typo.
I think this is what separates good from bad PMs.
I work with a good PM who gives engineers a bit of room for innovation, and importantly identifies how to productise that innovation.
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.
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 article is terrible. Lots of speculation and biased opinion, with absolutely no facts or alternative team structure suggestions. It's more of a rant.
I've wondered in the past if product management (especially for externally facing functionality) is too much to ask for one person:
* 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
* 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
> 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)
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.
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.
> 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?
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.
PM to me means communicators. They free developers from doing such social work. Developers in most case is the implementers, not communicators.
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 ?
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 ?
My motto as a PM when talking to my engineering teams is "I go to meetings so that you don't have to" =)
They seem to appreciate my sacrifice...
They seem to appreciate my sacrifice...
I have a theory about when innovation slows down to a crawl. Its the inflection point of where there are too many stakeholders to take quick decisions. I don't know what that inflection point is (3-4 ?) but its what I have observed again and again in big organisations.
Didn't read article but can react to headline.
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.
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.
I don't think you read the headline, either. The headline (and the article) both make no mention of engineering. In fact, you said nothing about innovation, which is the core premise of the article. From the post:
> 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".
> 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".
Fair enough! You're right.
I don't know what awful experiences this author has had with product managers, but all this article has done is made me appreciate the brilliant PMs I get to work with every day.
This is the kind of post a shitty PM would write...
Ironic that the author calls PMs "not very smart at making product decisions" while the author is not smart enough to understand the role of sales or product.
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.
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.
Is this phenomena better or worse if you make your tech lead a product manager?
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 whole article seems really juvenile and poorly written.
[deleted]
I immediately thought. Tech culture has become... "Im upset. Im going to rage write a blog post. Im going to publish it on another site. Now I somewhat have to manage the blow back." Why? What an overly complex way to vent, but as a "PM", exactly what Ive come to expect. My recommendation would have been to vent to a friend in private, research says "over beer" works best...
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.
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.