The product manager role is a mistake(sollecitom.github.io)
sollecitom.github.io
The product manager role is a mistake
https://sollecitom.github.io/software-product-development-blog/posts/2023/2023-10-21-product-manager-role-is-a-mistake/
369 comments
> "hiring low performers will hurt your company"
People who hire people just can't seem to help themselves but hire shit people, especially people who talk a lot about how they need process etc so it doesnt happen.
Day in day out, they always hire low performers, and I have no idea why. An untrained chimp with a stack of CVs would have a better strike rate.
People who hire people just can't seem to help themselves but hire shit people, especially people who talk a lot about how they need process etc so it doesnt happen.
Day in day out, they always hire low performers, and I have no idea why. An untrained chimp with a stack of CVs would have a better strike rate.
Because all the good ones are not looking for a job or at least not as often as bad ones. So it is hard to get good ones, you have to be lucky.
With regards to hiring, this is tricky because all candidates will try to put their best food forward and have a reasonable explanation for everything on their resume. In addition, low performers can look like high performers if their experience was painted by working at places with low expectations. I’ve hired very high performing people who later admitted to being PIPed many times throughout their career but these places were either greatly dysfunctional and/or just not a good fit for them.
Additionally, high/low performance has little to do with competence in the role in my experience and hiring someone truly unqualified is very rare. Some of the lowest performing people (in the long-term) were the sharpest during the interview and I still consider very bright people. Higher performers can run the gambit but a lot of companies miss out of great talent because the prospective employee fumbles over a closed book, live coding challenge.
Lower performers typically have something else going on in their life (relationship problems, housing or living situation stressors, financial stress, family stress, undiagnosed/under-addressed mental health problems, etc) and maybe during another time in their life could very well have been very high performing.
My point is, when dealing with people, it’s complicated.
Additionally, high/low performance has little to do with competence in the role in my experience and hiring someone truly unqualified is very rare. Some of the lowest performing people (in the long-term) were the sharpest during the interview and I still consider very bright people. Higher performers can run the gambit but a lot of companies miss out of great talent because the prospective employee fumbles over a closed book, live coding challenge.
Lower performers typically have something else going on in their life (relationship problems, housing or living situation stressors, financial stress, family stress, undiagnosed/under-addressed mental health problems, etc) and maybe during another time in their life could very well have been very high performing.
My point is, when dealing with people, it’s complicated.
A bigger population just hasn't been trained properly. We have no controls for that, so people get lucky with disparate learning being just enough for their first job, then that turns into experience towards the next job.
Then they find themselves among high performers and can't keep up, really through no fault of their own.
Some high performers are just natural and born with it, which is unfair to let that affect how anyone judges others' performance, but it still happens too (esp. if the high performer is doing the judgment).
What I generally see when people categorize their workers into high/low performance is from a bigger issue of poor stewardship over the industry and training its talent.
This means I don't actually have to improve, I can instead just spam job applications and get lucky just because technology is such a large industry.
Then they find themselves among high performers and can't keep up, really through no fault of their own.
Some high performers are just natural and born with it, which is unfair to let that affect how anyone judges others' performance, but it still happens too (esp. if the high performer is doing the judgment).
What I generally see when people categorize their workers into high/low performance is from a bigger issue of poor stewardship over the industry and training its talent.
This means I don't actually have to improve, I can instead just spam job applications and get lucky just because technology is such a large industry.
> A bigger population just hasn't been trained properly. We have no controls for that, so people get lucky with disparate learning being just enough for their first job, then that turns into experience towards the next job.
I agree, but I am also hesitant to advocate for controls in the form of certification (degrees, licenses, etc) because it just adds a layer that provides a strong positive signal for a while until it’s just inundated by grifters yet again, so now we’re back to square one.
We see this take the form of degree mills and accelerated trade schools initially, which ends up creating more problems, more barriers, and ceases to benefit the companies looking to hire. Everything can and will be gamified, and I am also hesitant to tie people to former employers so heavily as that creates an unhealthy power imbalance.
Then how can we control for talent? I don’t know the answer to this question or if it’s even the right question to ask, but I’m fairly confident that we cannot solve this using 20th century nor modern hiring and screening processes.
I agree, but I am also hesitant to advocate for controls in the form of certification (degrees, licenses, etc) because it just adds a layer that provides a strong positive signal for a while until it’s just inundated by grifters yet again, so now we’re back to square one.
We see this take the form of degree mills and accelerated trade schools initially, which ends up creating more problems, more barriers, and ceases to benefit the companies looking to hire. Everything can and will be gamified, and I am also hesitant to tie people to former employers so heavily as that creates an unhealthy power imbalance.
Then how can we control for talent? I don’t know the answer to this question or if it’s even the right question to ask, but I’m fairly confident that we cannot solve this using 20th century nor modern hiring and screening processes.
If I hire a plumber to do work I don't care about his life experiences, he can either fulfill the obligation or not.
nowadays there's entirely too much of this externalizing responsibility and making excuses for people.
nowadays there's entirely too much of this externalizing responsibility and making excuses for people.
Was going to say much the same thing.
1. Don't hire product managers because they won't be great people.
2. Instead, hire great people, but not one of them, a whole team of them!
Ok....
1. Don't hire product managers because they won't be great people.
2. Instead, hire great people, but not one of them, a whole team of them!
Ok....
> It reads like someone had a bad experience with a PM who thought they were Steve Jobs.
I had the opposite understanding about the article. Steve Jobs was an extraordinary leader who through immense will power created good products; an attempt to replace someone like Jobs as the product manager with an ordinary person will result in a mediocre product.
I had the opposite understanding about the article. Steve Jobs was an extraordinary leader who through immense will power created good products; an attempt to replace someone like Jobs as the product manager with an ordinary person will result in a mediocre product.
TL;DR With or without the PM title or experience, hire smart people.
It's a fairly harsh take, as a whole, but there's parts of this that absolutely ring true. Once you get that "product org" in a company, it tends to progress the way the author describes, with committees and OKRs and review cycles and planning and a lot of bureaucracy.
I took, naively, a product manager job at one place I worked, thinking it would finally give me formal control over the product that I'd been previously asserting through influence - very successfully - in my client-facing sales engineering role. Of course as soon as I got in the chair I discovered it was a highly-constrained clerical job that I was completely unsuited to. Managing tickets and a backlog; coordinating decisions instead of making them; writing interminable powerpoint reports; the most creative thing was putting together a process for the company to follow in formalizing its product roadmaps. I lasted six months before running away.
The function is quite useful in supplying some visibility into what's getting built and in managing conflicting priorities for a growing product, but one thing it is not is shaping or controlling the evolution of the product in any way. It's a sorting, filtering, and (if you're lucky) a data collection function, producing an auditable decision trail and an impression of maturity in decision making which helps the MBAs higher up sleep a little easier.
I took, naively, a product manager job at one place I worked, thinking it would finally give me formal control over the product that I'd been previously asserting through influence - very successfully - in my client-facing sales engineering role. Of course as soon as I got in the chair I discovered it was a highly-constrained clerical job that I was completely unsuited to. Managing tickets and a backlog; coordinating decisions instead of making them; writing interminable powerpoint reports; the most creative thing was putting together a process for the company to follow in formalizing its product roadmaps. I lasted six months before running away.
The function is quite useful in supplying some visibility into what's getting built and in managing conflicting priorities for a growing product, but one thing it is not is shaping or controlling the evolution of the product in any way. It's a sorting, filtering, and (if you're lucky) a data collection function, producing an auditable decision trail and an impression of maturity in decision making which helps the MBAs higher up sleep a little easier.
I agree. So, I think the question is, how do you effectively implement stewardship and accountability on product matters without having an organization strictly dedicated to it? The author doesn’t give much of a framework here
[deleted]
Ultimately the issue is a lack of clear roles and responsibilities of a PM role defined, and a lack of accountability.
I agree with you that the "product org" is an entity that can become a political and bureaucratic entity rather than an enabler.
Personally, I think the Product role should be embedded within engineering teams and report up to the same leaders (level is debatable) so that a bad PM can be dealt with just like a bad engineer. Of course if your company can't get rid of bad engineers either, you have other problems.
I agree with you that the "product org" is an entity that can become a political and bureaucratic entity rather than an enabler.
Personally, I think the Product role should be embedded within engineering teams and report up to the same leaders (level is debatable) so that a bad PM can be dealt with just like a bad engineer. Of course if your company can't get rid of bad engineers either, you have other problems.
Just to offer you another perspective: In all of the (B2C) companies in which I have worked as a PM (three, across two different industries), I have been closely involved in shaping and controlling the evolution of the product.
My normal month has always consisted of creating anywhere from four to twelve unique proposals (PRDs) for new features for the company to build, with the number created varying based on the size of the company and the amount of process needed as a result. But regardless, it has always looked like: "Our users currently have X problem, and we should build Y to solve it. Y looks like this...". Yes this comes with some coordination and communication challenges, but those are always in service of figuring out what to build next.
I understand not all PM roles are like this, but I do disagree that PM never gets better than "sorting/filtering/decision maturity theatre". I am curious: if you were simply ordering an existing backlog, who was defining the new items to add to the backlog?
My normal month has always consisted of creating anywhere from four to twelve unique proposals (PRDs) for new features for the company to build, with the number created varying based on the size of the company and the amount of process needed as a result. But regardless, it has always looked like: "Our users currently have X problem, and we should build Y to solve it. Y looks like this...". Yes this comes with some coordination and communication challenges, but those are always in service of figuring out what to build next.
I understand not all PM roles are like this, but I do disagree that PM never gets better than "sorting/filtering/decision maturity theatre". I am curious: if you were simply ordering an existing backlog, who was defining the new items to add to the backlog?
Is that not a straight up engineering job? A good chunk of "engineer school" is practicing "customer has an issue, design a solution" type problems, in-between all the math.
Customers are rarely able to express their underlying issue. They usually communicate what they think the solution is.
A good product person is able to drill down to the fundamental problem the customer really has and articulate that to engineers.
Also, good product people should be evaluating the customers problem in terms of the whole market.
After all, engineering is a limited resource. So you need to solve the problems that exist for your target market, not just a single customer.
Of course, I’ve seen good engineers who can do this, but it takes time and effort to sift through all of the customers issues and work out which ones to solve. So product managers are focused on this to free up the good engineers to design solutions to those problems.
A good product person is able to drill down to the fundamental problem the customer really has and articulate that to engineers.
Also, good product people should be evaluating the customers problem in terms of the whole market.
After all, engineering is a limited resource. So you need to solve the problems that exist for your target market, not just a single customer.
Of course, I’ve seen good engineers who can do this, but it takes time and effort to sift through all of the customers issues and work out which ones to solve. So product managers are focused on this to free up the good engineers to design solutions to those problems.
>Customers are rarely able to express their underlying issue. They usually communicate what they think the solution is.
In my experience the vast majority of PMs do exactly this. Half of my job since I became a staff+ engineer almost a decade ago is taking “solutions” from product managers and trying to figure out what they really want.
In my experience the vast majority of PMs do exactly this. Half of my job since I became a staff+ engineer almost a decade ago is taking “solutions” from product managers and trying to figure out what they really want.
Good Product people don't just build exactly what the customer described as their problem. They understand that sometimes there's a better way to solve it. In "engineering school", you can't tell your professor "I understand what you're actually trying to achieve, so I built X instead of Y because I think it'll be better for you".
Product figures out what to build, and Engineering figures out how.
Product figures out what to build, and Engineering figures out how.
Sure you can. I’ve literally had classes that worked exactly like that. I had classes where I had to interview and observe actual customers using our product.
What you’re describing is a huge part of engineering. Engineers have been doing this long before Product Managers existed. When I started, software engineers used to just talk directly to customers, domain experts, business analysts, and business leaders.
At “product led companies” the engineers just end up trying to figure out what the product manager actually wants because it’s not really possible in most cases to separate the what from the how.
Having worked with both systems, I don’t think the way it works now is better.
What you’re describing is a huge part of engineering. Engineers have been doing this long before Product Managers existed. When I started, software engineers used to just talk directly to customers, domain experts, business analysts, and business leaders.
At “product led companies” the engineers just end up trying to figure out what the product manager actually wants because it’s not really possible in most cases to separate the what from the how.
Having worked with both systems, I don’t think the way it works now is better.
A lot of traditional engineering (civil, mechanical, etc) are non-competitive endeavors. For example, if you are supposed to make a bridge, you just design what you think a good bridge to be.
In the modern consumer application, you have to understand business concepts like differentiation. If your product is very good, but it’s strictly worse than another product in every dimension, you don’t get any credit for second place. You actually get close to zero sales because no consumer chooses your product over the alternative, in contrast to a “bad” product that does at least something very well in a niche.
In the modern consumer application, you have to understand business concepts like differentiation. If your product is very good, but it’s strictly worse than another product in every dimension, you don’t get any credit for second place. You actually get close to zero sales because no consumer chooses your product over the alternative, in contrast to a “bad” product that does at least something very well in a niche.
Clearly there’s a difference between building a bridge and getting customers to use your free app, but the vast majority of Engineers aren’t working in big infrastructure projects. Even the ones who do are competing with everyone else who bids on the project.
And in software there are plenty of cases where the 2nd or 3rd place product gets tons of sales even if it’s strictly worse in every category. There are so many things that impact market success that are completely out of the hands of product or engineering.
And in software there are plenty of cases where the 2nd or 3rd place product gets tons of sales even if it’s strictly worse in every category. There are so many things that impact market success that are completely out of the hands of product or engineering.
This doesn’t sound like any university CS degree I know of, apart from maybe a single class actually called “software engineering”, which in many cases isn’t even required
And even if it was, no, engineer personalities are horrible at designing solutions that actually meet customers’ and the business’s needs
And even if it was, no, engineer personalities are horrible at designing solutions that actually meet customers’ and the business’s needs
The engineering classes I took were full of stories and problems centered around solving erroneous customer reports. A good example is the ice cream story [0], where a customer reports their car malfunctioning when they buy the wrong kind of ice cream, which was used as an introduction to root causing techniques. That specific story is apocryphal and the manufacturer varies, but there's an entire mythology of such stories being used to introduce topics / provide "realistic" problems / do design projects for students.
This sort of stuff is a not-insignificant portion of my job as well, since PMs rarely have the technical skills to know what's feasible as a solution anyway in my experience.
[0] https://www.snopes.com/fact-check/cone-of-silence/
This sort of stuff is a not-insignificant portion of my job as well, since PMs rarely have the technical skills to know what's feasible as a solution anyway in my experience.
[0] https://www.snopes.com/fact-check/cone-of-silence/
My CS degree was full of classes where we had to deal with problems like that.
My experience was B2B. I was certainly expecting a lot more of the problem identification and solution generation work that you described.
The difficulty was that the owners at the top had unshakeable ideas about what the product should be. That's ok, single minded vision can be good and all that. In my very hands-on sales engineering role I'd make things that my prospects were asking for, put them in the product, they'd buy it, and my prototypes and hacks and tools would end up getting refined, hardened, and supported by the implementation team. It worked well because everything I did had big dollars attached to it (so the org itself didn't mind) and the product advanced in a way that the market wanted.
The problems arose when we put in the product management process - the whole committee/requirement/signoff thing the article describes and I mentioned in my earlier comment. That created a formal bureaucratic mechanism for various players to stop all the ideas I had. Before, they'd be fait accomplis necessary for winning a big deal. Now they were just ideas divorced from value from some guy who should've known his place. Back then I was hopeless at understanding how to get a group of people with different agendas to agree on something (I think it's called 'politics').
> if you were simply ordering an existing backlog, who was defining the new items to add to the backlog?
It's over 15 years ago but what I remember is that there were thousands of semi-structured documents which represented things that, with the new product org, got turned into backlog items (stories, epics). This was part of an attempt to move engineering to a more agile way of working while creating a product function to support it. So it's more that we didn't have a backlog as such, then we stood it up and triaged everything we already had into it. All this was happening while the company was trying to learn about agile. I remember day long meetings where we all tried to argue about whether technical tasks belonged on a backlog, and if not how you could write a user story for remediating a piece of technical debt. Basic stuff but none of us had a clue.
The difficulty was that the owners at the top had unshakeable ideas about what the product should be. That's ok, single minded vision can be good and all that. In my very hands-on sales engineering role I'd make things that my prospects were asking for, put them in the product, they'd buy it, and my prototypes and hacks and tools would end up getting refined, hardened, and supported by the implementation team. It worked well because everything I did had big dollars attached to it (so the org itself didn't mind) and the product advanced in a way that the market wanted.
The problems arose when we put in the product management process - the whole committee/requirement/signoff thing the article describes and I mentioned in my earlier comment. That created a formal bureaucratic mechanism for various players to stop all the ideas I had. Before, they'd be fait accomplis necessary for winning a big deal. Now they were just ideas divorced from value from some guy who should've known his place. Back then I was hopeless at understanding how to get a group of people with different agendas to agree on something (I think it's called 'politics').
> if you were simply ordering an existing backlog, who was defining the new items to add to the backlog?
It's over 15 years ago but what I remember is that there were thousands of semi-structured documents which represented things that, with the new product org, got turned into backlog items (stories, epics). This was part of an attempt to move engineering to a more agile way of working while creating a product function to support it. So it's more that we didn't have a backlog as such, then we stood it up and triaged everything we already had into it. All this was happening while the company was trying to learn about agile. I remember day long meetings where we all tried to argue about whether technical tasks belonged on a backlog, and if not how you could write a user story for remediating a piece of technical debt. Basic stuff but none of us had a clue.
>The problems arose when we put in the product management process - the whole committee/requirement/signoff thing the article describes and I mentioned in my earlier comment. That created a formal bureaucratic mechanism for various players to stop all the ideas I had. Before, they'd be fait accomplis necessary for winning a big deal. Now they were just ideas divorced from value from some guy who should've known his place.
precisely, the introduction of a PM means that the people who actually implement the product are put below pure talkers. You suddenly go from being able to influence the product daily to everything being up for a vote and every vote being overriden by the PM. The PM gets to decide which issues are important enough to be included even though he really doesn't know better 99.9% of the time. 99.9% of the time he didn't talk to customers about it, he just has his own opinion and was put into this artificial leadership position that ruins the fun of the job for everyone else. Oh sure he talked to leadership but that ends up being about how to achieve his own dreams and goals, certainly not to help make the ideas of engineers a reality. I've literally never seen a PM that goes and asks what ideas of the engineers we can help make reality. Just let that sink in for a moment: Isn't that what a product is? Ideas of engineers? I mean it really is. The whole agile movement is one of the strangest gaslighting ventures that human psychology has ever produced. We are told that there is no boss while actively being micro managed issue by issue, hour by hour almost, while literally being asked every single day in the standup when X will be finished.
precisely, the introduction of a PM means that the people who actually implement the product are put below pure talkers. You suddenly go from being able to influence the product daily to everything being up for a vote and every vote being overriden by the PM. The PM gets to decide which issues are important enough to be included even though he really doesn't know better 99.9% of the time. 99.9% of the time he didn't talk to customers about it, he just has his own opinion and was put into this artificial leadership position that ruins the fun of the job for everyone else. Oh sure he talked to leadership but that ends up being about how to achieve his own dreams and goals, certainly not to help make the ideas of engineers a reality. I've literally never seen a PM that goes and asks what ideas of the engineers we can help make reality. Just let that sink in for a moment: Isn't that what a product is? Ideas of engineers? I mean it really is. The whole agile movement is one of the strangest gaslighting ventures that human psychology has ever produced. We are told that there is no boss while actively being micro managed issue by issue, hour by hour almost, while literally being asked every single day in the standup when X will be finished.
I am living the reality described by the article. The PM role has too much power and too little accountability if things go south. The usual scrape goats are sales, then engineering and support.
That sounds like a very painful situation. But this is a problem with the organization and/or the individual product managers, rather than the role.
Meh, the article's solution smells like great man theory.
> Tremendous people envision alternative realities, fully commit themselves to their work, and move mountains with their willpower.
The last part is so reductive. It's not willpower moving mountains. It's the underlings actually making the vision come to pass. At most the "great person" is aligning the incentives to motivate the actual doers and experts.
> Tremendous people envision alternative realities, fully commit themselves to their work, and move mountains with their willpower.
The last part is so reductive. It's not willpower moving mountains. It's the underlings actually making the vision come to pass. At most the "great person" is aligning the incentives to motivate the actual doers and experts.
> You hire everyday great people. Each one needs to be great at something, obsessed by their craft, and driven by quality. You then put them together in a team, without individual responsibilities, ensuring that there’s minimal overlap in areas of greatness.
My current company is full of smart people, and (for a variety of reasons) we don't have product managers. It sucks. What happens is that the things a PM does do not get done. Very few engineers want to maintain relationships with customers, interview users to identify potential features, manage leadership, play politics for resource allocation, and so on. So it doesn't get done. That's what happens there.
At my last company, where I worked for about a year, I had three product managers. Two of them were fired because they were incompetent. One was really, really good (tremendous, in the parlance of this article). Our team still got more done in a year with a fraction of a good PM than my current company has gotten done in over two years without any PMs.
I agree with one thing: there aren't enough good PMs to go around. My belief is the number of people cut out to be a good product manager scales linearly with the size of the population. You need certain personality traits and other qualities that can't be taught. You can mint mediocre PMs in school, but you can't make good ones that way, let alone great ones. The problem we are dealing with is that the software industry did not scale linearly, it exploded exponentially, and it needed 100x the number of people wearing the PM hat than there were actual, bonafide PMs in the world.
My current company is full of smart people, and (for a variety of reasons) we don't have product managers. It sucks. What happens is that the things a PM does do not get done. Very few engineers want to maintain relationships with customers, interview users to identify potential features, manage leadership, play politics for resource allocation, and so on. So it doesn't get done. That's what happens there.
At my last company, where I worked for about a year, I had three product managers. Two of them were fired because they were incompetent. One was really, really good (tremendous, in the parlance of this article). Our team still got more done in a year with a fraction of a good PM than my current company has gotten done in over two years without any PMs.
I agree with one thing: there aren't enough good PMs to go around. My belief is the number of people cut out to be a good product manager scales linearly with the size of the population. You need certain personality traits and other qualities that can't be taught. You can mint mediocre PMs in school, but you can't make good ones that way, let alone great ones. The problem we are dealing with is that the software industry did not scale linearly, it exploded exponentially, and it needed 100x the number of people wearing the PM hat than there were actual, bonafide PMs in the world.
In my experience: working with a good or great PM is fun and productive. Working without a PM is ok. Working with a bad PM is somewhere between irritating and infuriating.
Yep. A great PM is an amazing force multiplier. A bad PM drags the whole org down.
[deleted]
So you're saying PMs are powerful.
One of my most enjoyable experiences in regards to project management was working at a fortune 500 with an entire PM Org. The PMO grew out of IT where it was really formalized and then got its tentacles into all of the different orgs, sales, marketing, finance, etc. What an amazing force multiplier is right. Before IT would be sitting around waiting for Finance, now Finance was part of a global PM situation.
Those PMs in the PMO knew their shit, they were realistic, they understood different strategies, they handled managing up and down, and ensuring everyone knew what they had to do.
I wrote a linkedin review for my favorite PM and it's as follows:
When I first met Rajitha, she was in the process of managing a company wide Windows 7 to 10 upgrade. As it turns out I was one of the last holdouts and was badly overdue. She was incessant! I hated it!. Finally, I gave into her demands and as these things go, I was pleasantly surprised how smoothly it went.
Fast forward a few months and Rajitha was tasked to work along side myself and others on several complex tech merger/acquisition projects. Moving parts, moving people, the whole thing was a whirlwind held down by a few important people on the team, including her. My initial resentment was replaced with a new deeply held respect for her capabilities and skillset. She was amazingly diligent and focused, friendly and compassionate.
If you're get a chance to work with Rajitha, count yourself among the lucky few!
Sorry Rajitha, this recommendation is many years overdue. I was cleaning out my filing cabinet and found a stack of old Church & Dwight papers. A print out of "How I learned to stop worrying and love Direct To Consumer". A "Magneto", not "Magento" project cover, and a handwritten note -- left on my desk -- from you to make sure I followed up a task that was in my queue".
Those PMs in the PMO knew their shit, they were realistic, they understood different strategies, they handled managing up and down, and ensuring everyone knew what they had to do.
I wrote a linkedin review for my favorite PM and it's as follows:
When I first met Rajitha, she was in the process of managing a company wide Windows 7 to 10 upgrade. As it turns out I was one of the last holdouts and was badly overdue. She was incessant! I hated it!. Finally, I gave into her demands and as these things go, I was pleasantly surprised how smoothly it went.
Fast forward a few months and Rajitha was tasked to work along side myself and others on several complex tech merger/acquisition projects. Moving parts, moving people, the whole thing was a whirlwind held down by a few important people on the team, including her. My initial resentment was replaced with a new deeply held respect for her capabilities and skillset. She was amazingly diligent and focused, friendly and compassionate.
If you're get a chance to work with Rajitha, count yourself among the lucky few!
Sorry Rajitha, this recommendation is many years overdue. I was cleaning out my filing cabinet and found a stack of old Church & Dwight papers. A print out of "How I learned to stop worrying and love Direct To Consumer". A "Magneto", not "Magento" project cover, and a handwritten note -- left on my desk -- from you to make sure I followed up a task that was in my queue".
This applies to colleagues in all roles, especially the ones with more authority.
Been having this lately with one of our clients, and my impression is that more than one of these PMs have their role as a placeholder while something else is found for them to do.
I had several companies where the PM were horrible, lost, and egotistical. I then ran into a company where the PM spent ten years as a developer for some popular game companies. That guy was worth his weight in gold.
Development was so much smoother. I didn't have to spend time explaining why we couldn't do this or that. He'd nix bad ideas at higher levels before it even hit us. We were given ample warning on how we approach things ("Custom B will want this, and if box what you're doing now it'll be harder blah blah blah").
Development was so much smoother. I didn't have to spend time explaining why we couldn't do this or that. He'd nix bad ideas at higher levels before it even hit us. We were given ample warning on how we approach things ("Custom B will want this, and if box what you're doing now it'll be harder blah blah blah").
> Very few engineers want to maintain relationships with customers, interview users to identify potential features, manage leadership, play politics for resource allocation, and so on
Ah, so that's what a product manager is supposed to do. When product managers were introduced at a company I worked at, they did very little of any of that. They certainly weren't speaking to customers. They weren't technical, so they weren't managing our Jira tickets. And "managing leadership" fell mostly on our managers' plates. I think the PMs mostly had meetings, talked to leadership, talked to engineers, wrote documents, and presided over the (now very long) sprint planning meetings.
I can imagine product managers that did your list of things being a lot more valuable.
Ah, so that's what a product manager is supposed to do. When product managers were introduced at a company I worked at, they did very little of any of that. They certainly weren't speaking to customers. They weren't technical, so they weren't managing our Jira tickets. And "managing leadership" fell mostly on our managers' plates. I think the PMs mostly had meetings, talked to leadership, talked to engineers, wrote documents, and presided over the (now very long) sprint planning meetings.
I can imagine product managers that did your list of things being a lot more valuable.
Sounds a lot more like a project or program manager than a product manager.
And ironically it seem like the things you'd positively attribute here to a product manager used to be/are actually part of the scope of what was traditionally a "project manager" or "program manager."
For example, look at the scope and definition of a "program manager" from Microsoft or the US DoD in the 1980s, 1990s+, as well as literature describing the role of a program manager and the discipline from that time.
For example, look at the scope and definition of a "program manager" from Microsoft or the US DoD in the 1980s, 1990s+, as well as literature describing the role of a program manager and the discipline from that time.
Why’s that ironic? There didn’t used to be frontend / backend / full stack devs either. As software engineering has matured and grown in scale, more subdivision of responsibilities is a natural outcome of that. We’re not all just directly writing code on mainframes and our customers aren’t just < 1k of users who directly call us on the phone if something goes wrong anymore, it’s millions of people using services 24x7
now. MS wasn’t making real-time collaboration systems and cloud sync in the 80s and 90s. They were making a stand-alone offline machine that barely could install device drivers and didn’t know what the internet was. Completely different products, and much simpler.
What subdivision of responsibilities? Clients and servers were divided for as long as clients and servers existed. Full stack is aggregation of responsibilities. DevOps too. Dedicated QA is rare now.
Most companies with product managers have fewer customers and less complex products than 1990s Microsoft.
Most companies with product managers have fewer customers and less complex products than 1990s Microsoft.
Nevertheless it is the role called "product manager" at many companies.
Yep, a common pitfall is to not understand how product managers are supposed to do, and thus they just do project management, which often has neutral or negative value.
I've seen competent project managers work very hard to achieve that neutral-value proposition. I haven't yet seen any one succeed.
In my experience, as soon as you decide your projects will be formal and managed, you are already doomed to that negative value.
In my experience, as soon as you decide your projects will be formal and managed, you are already doomed to that negative value.
Sometimes you need a formal project. We’re kitting out a new office over the next couple of years, it’s a major programme of multiple projects, all which interact. At the end of it though we have a building fit for purposes following the plans currently set. I’m sure those plans will adjust a little, but the end date is January 2025, or July, or something - I’m sure the date will slip.
You can’t build a £20m facility with a series of sprints.
You can’t build a £20m facility with a series of sprints.
Well, the Empire State Building was famously built as a series of sprints...
You need a formal design. This doesn't mean you need a formal project. Some amount of planning ahead very obviously helps, but how much is debatable, and when you have people whose sole specialization is "planning ahead", you are certainly past the point where it's too much.
Anyway, the most valuable people are the ones "planning behind", looking for what was left broken and could be done better from now on. Project management defines those people out of existence.
You need a formal design. This doesn't mean you need a formal project. Some amount of planning ahead very obviously helps, but how much is debatable, and when you have people whose sole specialization is "planning ahead", you are certainly past the point where it's too much.
Anyway, the most valuable people are the ones "planning behind", looking for what was left broken and could be done better from now on. Project management defines those people out of existence.
Think of the "formal project" is the API by which executing the design can be understood by all stakeholders.
It is a high level abstraction that allows all parties to understand what they need to do and when they need to do it. For large projects it is simply essential - you need your external vendors to plan their availability, months or sometimes years in ahead, so that they can commit to the timeline.
If you're lucky enough to work on large software projects where there are no managers or other stakeholders asking "and how long will this take, exactly?" then maybe the design is enough.
But pretending planning ahead on large projects that is something that will just happen by osmosis or people "just doing it" simply won't work. Good project managers who do what they're supposed to are worth their weight in gold (just like good product managers).
It is a high level abstraction that allows all parties to understand what they need to do and when they need to do it. For large projects it is simply essential - you need your external vendors to plan their availability, months or sometimes years in ahead, so that they can commit to the timeline.
If you're lucky enough to work on large software projects where there are no managers or other stakeholders asking "and how long will this take, exactly?" then maybe the design is enough.
But pretending planning ahead on large projects that is something that will just happen by osmosis or people "just doing it" simply won't work. Good project managers who do what they're supposed to are worth their weight in gold (just like good product managers).
> If you're lucky enough to work on large software projects where there are no managers or other stakeholders asking "and how long will this take, exactly?" then maybe the design is enough.
How well can your project managers answer how long will this take? Because on my experience, 10000% delays are all but routine (ok, on construction it's usually bounded to something around 1000%). And how much value do people that can give you an estimate between 1% and 10000% of the target?
> But pretending planning ahead on large projects that is something that will just happen by osmosis
I'm telling you that planning ahead has a small value, following up with the plan has a high negative value, and the thing with a high positive value that is reexamining the plan is fought against by the practitioners.
How well can your project managers answer how long will this take? Because on my experience, 10000% delays are all but routine (ok, on construction it's usually bounded to something around 1000%). And how much value do people that can give you an estimate between 1% and 10000% of the target?
> But pretending planning ahead on large projects that is something that will just happen by osmosis
I'm telling you that planning ahead has a small value, following up with the plan has a high negative value, and the thing with a high positive value that is reexamining the plan is fought against by the practitioners.
If they are good project managers, they plan for non-routine delays and account for them in the project schedule. Before people are allowed to commit to schedule, the project managers make sure that these people have properly scoped and estimated their part of the work, by asking pointed questions, using their domain expertise and general experience to figure out if they're being bullshitted or not.
If things start to slip, they find out where and why and apply what pressure they can to get them on track. If they cannot get them on track, they then liaise with everyone downstream to make them aware of the slippage, adjust the entire schedule, and get everyone reorganised.
It's not just putting things in the calendar and forgetting about them - it's a constant, ongoing herding of cats to get them all going the same way.
It sounds like you just might not have been lucky enough to work with really great project managers!
If things start to slip, they find out where and why and apply what pressure they can to get them on track. If they cannot get them on track, they then liaise with everyone downstream to make them aware of the slippage, adjust the entire schedule, and get everyone reorganised.
It's not just putting things in the calendar and forgetting about them - it's a constant, ongoing herding of cats to get them all going the same way.
It sounds like you just might not have been lucky enough to work with really great project managers!
It sounds like you had a project manager, not a product manager. A good product manager is very valuable.
Agree. Similar to a developer vs. SWE.
there is no difference between a developer and an SWE except a fancy title
Disagree. Project manager is extremely different to product. Dev vs SWE is completely arbitrary
What do you see as the difference between a developer and a SWE?
One is DevOps and one is a programmer
They’re both programmers and you can’t “be devops”.
The vast majority of my colleagues would say "that person is a devops" instead of "that person does devops", which I don't get at all. I've assumed it's some deeply rooted misunderstanding of language (my colleagues are eastern european) that has taken hold across the entire local industry.
That didn’t really clarify for me, which is which? What is DevOps to you? (Seems to be different for everyone)
The wiki for “programmer” has “software developer, a software engineer, a programmer or a coder” as interchangeable terms in the first sentence.
[1] https://en.m.wikipedia.org/wiki/Programmer
The wiki for “programmer” has “software developer, a software engineer, a programmer or a coder” as interchangeable terms in the first sentence.
[1] https://en.m.wikipedia.org/wiki/Programmer
Last time I saw one of these types of articles on here it quickly became apparent that a lot of companies don't know the difference and call their project managers by the wrong name.
People using "PM" is adding to the confusion.
That’s why I use PMP for Product Management Professional. Much clearer
For what it's worth, I enjoyed that joke. I work in education and the number of redundant acronyms and initialisms (if that's a word) is astounding.
BIT meeting on my calendar. Is it behavioral intervention team or something about the bachelor of information technology or Business Information technology or bachelor of industrial technology or are we talking about income taxes or what?
BIT meeting on my calendar. Is it behavioral intervention team or something about the bachelor of information technology or Business Information technology or bachelor of industrial technology or are we talking about income taxes or what?
Agreed, PjM and PdM are what I use when referring to them.
A lot of teams with poor business operations seem to treat project, product, and program management as a generic blob of “help us be organized please” duties instead of specific jobs with specific operational missions.
What is the difference then, between a project manager, product manager, a project owner and a product owner? Always thought they're approximately the same thing. Isn't any product you're working on a project too?
The main difference is between a product and a project. The gist is that projects are short term specific plans while products are a bit more open-ended ideas with continual feedback. Here’s a decent overview: https://martinfowler.com/articles/products-over-projects.htm...
Imo projects are company details, products are what your users see.
The split between project manager and product owner seems clearest.
A project manager is running the team. Who does what and when? How do we plan the work?
A product owner is kind of like the representative stakeholder. What should this do? How important is launching now Vs fixing these bugs?
How Vs what.
Good people in these roles are incredible. I've been fortunate to work with some.
The split between project manager and product owner seems clearest.
A project manager is running the team. Who does what and when? How do we plan the work?
A product owner is kind of like the representative stakeholder. What should this do? How important is launching now Vs fixing these bugs?
How Vs what.
Good people in these roles are incredible. I've been fortunate to work with some.
Product Manager: They are essentially the voice of the customer and upper management. They work on the product roadmap and determine the requirements for the product based on the needs that are determined by conversations with the stakeholders as well as other market research. In addition to this they also work on things like product pricing, release strategy, etc.
Project Manager: They ensure that all the tasks for a project get done on time. They make the gantt charts, work with teams to break it down into sections, keep track of budgets, manage risks, report on progress to stakeholders, etc.
I've never worked with a Product Owner since I understand it is mostly a software related position and that is not my area. From what I understand, they are an intermediary that sits between PdM and PjM.
Project Manager: They ensure that all the tasks for a project get done on time. They make the gantt charts, work with teams to break it down into sections, keep track of budgets, manage risks, report on progress to stakeholders, etc.
I've never worked with a Product Owner since I understand it is mostly a software related position and that is not my area. From what I understand, they are an intermediary that sits between PdM and PjM.
It seems like whoever named these titles did a poor job. They’re so close, can you blame people for not seeing a difference?
What is a product but a large project anyways?
What is a product but a large project anyways?
A product manager is expected to view things from a business point of view. To identify features for the product and help it succeed in the market.
A project manager is in charge of planing, execution and governance of a project. They don’t define any of the goals or vision.
Saying product is a large project is a big over simplification. If we go that route anything could be called a “large project”.
A project manager is in charge of planing, execution and governance of a project. They don’t define any of the goals or vision.
Saying product is a large project is a big over simplification. If we go that route anything could be called a “large project”.
> Saying product is a large project is a big over simplification. If we go that route anything could be called a “large project”.
Yes. That's precisely the point. What's the difference between "X manager" and a "project manager" when the X itself is obviously a project?
Yes. That's precisely the point. What's the difference between "X manager" and a "project manager" when the X itself is obviously a project?
> in charge of planing, execution and governance of a project. They don’t define any of the goals or vision.
This sounds like if you were trying to hire a race-car driver instead hired two people, and put one of them in charge of steering to the left and the other in charge of steering to the right.
This sounds like if you were trying to hire a race-car driver instead hired two people, and put one of them in charge of steering to the left and the other in charge of steering to the right.
this is exactly why back-to-office initiatives have value - it's easier to coordinate when the steerers are next to each other
Navigating and driving the car are two very obviously distinct tasks that regular people and rally drivers split up.
The product manager decides which direction the car should be turned and the project manager turns the wheel.
A project has a planned end date, a product typically doesn't.
Most modern products seem to have planned end dates.
Development phase is the project. Maintenance phase before sunsetting is I guess another project.
Isn't it the other way around? Projects tend to never end. Products eventually get released.
A released product is not the end of the product. See: Google, Facebook, WhatsApp, X, Gmail, Dropbox, Firefox, etc.
A release ist just the begining of a product. After that you have to collect customer feedbackand figure out what to prioritize for the next release.
My company had project managers and product owners to avoid that verbal confusion.
A project has a defined start and end. You know when it’s done, and you should know that before it even starts.
A product is ongoing. It reacts to business changes.
A project has a defined start and end. You know when it’s done, and you should know that before it even starts.
A product is ongoing. It reacts to business changes.
Project managers co-ordinate the teams and stakeholders associated with a project. It only applies to bigger companies. In smaller projects senior engineers and engineering managers do the same job.
There's sometimes also program managers who organize relevant projects across the company (for example with GDPR compliance a program manager might coordinate between legal and various products, identify risks and report progress to C-level, and each product will have a project kick off to get it into compliance (depending on the effort, the person overlooking this project and working with program might be a dedicated project manager, engineering manager, some engineer etc).
Most companies don’t understand what a product manager does, and they are busy eliminating project management roles in favor of an “agile” workflow, so they just repurpose the project managers to be product managers because it’s only two letters different. With predictable results.
Project management was the role Larry Page once axed in 2001: https://medium.com/illumination/google-once-fired-all-manage...
Sounds like he fired a type of project manager - one who controlled the team. A project manager can manager the team by supporting them and unblocking them while doing non-implementation type work such as managing and reporting the project's budget, managing and reporting progress and delivery aims.
Google currently has program managers (and technical program managers). I could not tell you the difference between them and product or project managers.
It changes between companies. At my company the Product Owner is the one who maintains the relationship with customers. Product Managers are there for prioritizing the feature requests. We also have Project Managers for inter-project dependency tracking and Engineering Managers for resource allocation and work output.
I think that’s the challenging part. A product manager is supposed to stuff holes in your team that no one else currently does. Do you have a strong TL with a good product sense? Then the PM should probably spend their time talking to customers, and not interfere with the engineering team so much.
Do you have a good UX team, but the engineering team is just a bit too big to be comfortable? Then the PM should work with the team to streamline communications and processes.
The hard part about this is that on the one hand, you need a PM that is experienced enough that they can set up processes and be disciplined enough to make sure they are followed. On the other hand, you need a PM that is able to embrace the chaos on aspects of the teams organization where it is beneficial for the team. Oh, and also they should be a domain expert, if possible. Know SQL. Know how to talk to management. Etc.
I think if you have a good one, it is a strong force multiplier for the team. If you have a bad one, it is a force subtractor.
And it is extremely difficult to tell beforehand (or even while they are actually working in that team!) which kind of PM you have. It’s one of those roles that, if it’s done perfectly, people won’t be sure whether you have done anything at all.
But I agree with the premise that there are probably too many bad ones in circulation right now.
Do you have a good UX team, but the engineering team is just a bit too big to be comfortable? Then the PM should work with the team to streamline communications and processes.
The hard part about this is that on the one hand, you need a PM that is experienced enough that they can set up processes and be disciplined enough to make sure they are followed. On the other hand, you need a PM that is able to embrace the chaos on aspects of the teams organization where it is beneficial for the team. Oh, and also they should be a domain expert, if possible. Know SQL. Know how to talk to management. Etc.
I think if you have a good one, it is a strong force multiplier for the team. If you have a bad one, it is a force subtractor.
And it is extremely difficult to tell beforehand (or even while they are actually working in that team!) which kind of PM you have. It’s one of those roles that, if it’s done perfectly, people won’t be sure whether you have done anything at all.
But I agree with the premise that there are probably too many bad ones in circulation right now.
There are certainly more bad managers than good ones. (Just like programmers.)
So it follows there will be more anecdotes about bad managers than good ones.
With respect, if you've never had a good, or great, manager then I understand it'll be hard to envision a good one.
I say this not to invalidate your anecdote but yo say that managers, like programmers, are not created equal and they cannot just be swapped like burgers at macdonalds.
So it follows there will be more anecdotes about bad managers than good ones.
With respect, if you've never had a good, or great, manager then I understand it'll be hard to envision a good one.
I say this not to invalidate your anecdote but yo say that managers, like programmers, are not created equal and they cannot just be swapped like burgers at macdonalds.
My experience with product managers is that they wedge themselves between the business and the technical teams and then wield political power while doing very little.
I'm currently trying desperately to get two different PM's to talk to each other so we can be consistent with permissions sets across two different projects. Both projects use the same set of API's.
One of the PM's is basically incognito, the other has actively been trying to avoid doing any of the work.
But the technical teams will get blamed for this, I know because I've watched these same PM's blame the technical teams for their own failings on other projects.
I'm with the article, fuck Product Managers, grab a senior developer and let him or her spend part of their time interfacing with business while also teaching the younger developers the skills necessary to do it.
The problem isn't that their responsibilities aren't useful, it's that there shouldn't be a role dedicated to their responsibilities, it immediately draws moats around everything and suddenly the need for communication and collaboration jumps through the roof because the people in that role don't understand the technology the way a senior developer would.
There's a segment of the developer population that wants to put their head in the sand, do their job, and clock out. These developers are low value and will never be able to take on the role described above.
I'm currently trying desperately to get two different PM's to talk to each other so we can be consistent with permissions sets across two different projects. Both projects use the same set of API's.
One of the PM's is basically incognito, the other has actively been trying to avoid doing any of the work.
But the technical teams will get blamed for this, I know because I've watched these same PM's blame the technical teams for their own failings on other projects.
I'm with the article, fuck Product Managers, grab a senior developer and let him or her spend part of their time interfacing with business while also teaching the younger developers the skills necessary to do it.
The problem isn't that their responsibilities aren't useful, it's that there shouldn't be a role dedicated to their responsibilities, it immediately draws moats around everything and suddenly the need for communication and collaboration jumps through the roof because the people in that role don't understand the technology the way a senior developer would.
There's a segment of the developer population that wants to put their head in the sand, do their job, and clock out. These developers are low value and will never be able to take on the role described above.
> My experience with product managers is that they wedge themselves between the business and the technical teams and then wield political power while doing very little.
There's a large number of companies where the company is the one wedging the PMs there.
My view is that a PMs job should include (but not be limited to) diplomacy, negotiation and facilitation. But if your heart isn't in that (and it can be easy to become disheartened), then it easily becomes "politics", and the worst parts of politics, at that.
There's a large number of companies where the company is the one wedging the PMs there.
My view is that a PMs job should include (but not be limited to) diplomacy, negotiation and facilitation. But if your heart isn't in that (and it can be easy to become disheartened), then it easily becomes "politics", and the worst parts of politics, at that.
I wonder if part of the gap here is about whether a company is B2B or B2C. In my experience at a largely B2B company, the product managers are people that aren't necessarily technical, but have experience in the relevant domain and meet with customers to find out what they need and coordinate launches etc., with them.
I don't know if the same role makes as much sense at a B2C company, so maybe people are B2Bs see their value and people at B2C companies don't as much?
I don't know if the same role makes as much sense at a B2C company, so maybe people are B2Bs see their value and people at B2C companies don't as much?
I've seen shops hire product managers for INTERNAL customer facing apps, and then have the PMs basically not talk to those customers. They did instead talk extensively to product & tech management as well as the c-suite.
So tech people (even IC non-leads) end up on weekly calls with various internal stakeholders that the PM can't make (literally this is your job dude) and take the brunt of all the feedback/relationship management/etc with the trickier ones.
The worst was when he said he would take the weekly calls with Asia users but wanted to pre-meet with me first and ask I ride along with the weekly user call for a while. So we would pre-meet and then he would ghost on the user call so I end up having two calls instead of one.
Just cargo cult CTOs reading too many books and not actually looking at the evidence in front of their eyes.
So tech people (even IC non-leads) end up on weekly calls with various internal stakeholders that the PM can't make (literally this is your job dude) and take the brunt of all the feedback/relationship management/etc with the trickier ones.
The worst was when he said he would take the weekly calls with Asia users but wanted to pre-meet with me first and ask I ride along with the weekly user call for a while. So we would pre-meet and then he would ghost on the user call so I end up having two calls instead of one.
Just cargo cult CTOs reading too many books and not actually looking at the evidence in front of their eyes.
Same experience, but I have one hypothesis: in B2C the “client” after some point become some abstract entity where people ship code/product to. A great PM can talk with those masses and extract exactly what needs to be done. This is a very hard skill.
In B2C the customer is way clearer and the relationship is everything and it’s quite hard a bad professional hide for long.
In B2C the customer is way clearer and the relationship is everything and it’s quite hard a bad professional hide for long.
The issue too often is business analysts wanting to be product managers when technical analysts may enable to learn the role better.
TA’s will devour the BA’s because tech folks can learn business easier than the other way around.
Still, BA’s can learn the details and get more fluent in working with them.
TA’s will devour the BA’s because tech folks can learn business easier than the other way around.
Still, BA’s can learn the details and get more fluent in working with them.
My experience with B2B PMs is that exactly one that I've worked with was amazing and the rest were just an awful intermediary that added a day of latency to any communication with our contact at customers and often managed to mangle things too.
I feel like that list of responsibilities describes a staff engineer too
Are they really that smart if they’re ignoring those things? Talking to users has always been on my list of things required for engineers.
A decade+ of low-interest-rate fueled growth in the tech sector has meant a lot of us have succeeded just by showing up.
A decade+ of low-interest-rate fueled growth in the tech sector has meant a lot of us have succeeded just by showing up.
In my experience, close technical customer-developer collaboration is incredibly valuable.
What’s not great is customers arguing with engineers about which features to implement first or whether their bug report ought to have been backlogged. This is where a strong product role is essential.
What’s not great is customers arguing with engineers about which features to implement first or whether their bug report ought to have been backlogged. This is where a strong product role is essential.
I agree. Have the product team facilitate communications between customers and engineers and guide efforts towards development that has the biggest returns. Sadly I don’t really ever see it functioning that way anymore.
> Talking to users has always been on my list of things required for engineers.
For any product of reasonable complexity, taking to users is something a PM should be spending ~1.5 days/wk on. Plus overseeing quantitative user research.
If your engineers are all spending that kind of time on users, that's slowing down the amount of time writing software by a huge amount.
For any product of reasonable complexity, taking to users is something a PM should be spending ~1.5 days/wk on. Plus overseeing quantitative user research.
If your engineers are all spending that kind of time on users, that's slowing down the amount of time writing software by a huge amount.
In big companies there is not even a way for engineers to reach out to users. They come to you through feedback.
Someone's gotta own the roadmap and prioritize the work queue, be it at a project level or updating the Microsoft project plan or the sprint. There's always a multitude of stakeholders. Devs, sales, marketing, ops, all have needs and idea. Someone must be the arbiter.
I operate as principle on a project, and I have opinions, but I cannot set the roadmap alone
I operate as principle on a project, and I have opinions, but I cannot set the roadmap alone
If all you want is someone to do team-level project management toil, a line manager can do that (or hire them a part time assistant if they don't want to and you don't want to invest in better automation). This is not a whole career-level job.
I get the feeling you don't work on massively complex projects.
We have loads of project managers where I work and I thank my stars we have every one of them. The coordination and planning required is ferocious for the work we need to deliver. It is not trivial and it would quickly fall apart without them.
We have loads of project managers where I work and I thank my stars we have every one of them. The coordination and planning required is ferocious for the work we need to deliver. It is not trivial and it would quickly fall apart without them.
Some of what you described in the comment I replied to fits the description of complicated company-spanning project management - a valuable role I have typically seen referred to as "program management" - but some of it, the team level dealing-with-task-backlogs type stuff, are things that managers and team members can just do in the course of their work.
But you're right that my comment focused only on the latter thing and ignored the former one.
But setting that aside, there is certainly a personality thing at play here. If I worked where you work, I would probably be more skeptical of the value of all the time being put into project management, and if you worked at my favorite companies that I've worked at, you would probably feel like it's a poorly managed mess (I've had lots of coworkers who felt that way!).
To some extent different folks just like different strokes, and that's one of the things that makes it really hard to do things that require lots of people to pull in the same direction.
But you're right that my comment focused only on the latter thing and ignored the former one.
But setting that aside, there is certainly a personality thing at play here. If I worked where you work, I would probably be more skeptical of the value of all the time being put into project management, and if you worked at my favorite companies that I've worked at, you would probably feel like it's a poorly managed mess (I've had lots of coworkers who felt that way!).
To some extent different folks just like different strokes, and that's one of the things that makes it really hard to do things that require lots of people to pull in the same direction.
There is certainly a distinction between teams just dealing with their task backlog and project management. I wouldn't waste a project manager on that.
Program management is a level above project management as you say, coordinating multiple projects. But there is definitely a space for complex single projects (not programs) that still require detailed planning and coordination.
It's not really about personal preference though, unless this issue is a show stopper for you in terms of where you work. I've worked in both informal and formal settings. I personally dislike heavyweight project management processes but they are sometimes required!
Program management is a level above project management as you say, coordinating multiple projects. But there is definitely a space for complex single projects (not programs) that still require detailed planning and coordination.
It's not really about personal preference though, unless this issue is a show stopper for you in terms of where you work. I've worked in both informal and formal settings. I personally dislike heavyweight project management processes but they are sometimes required!
Yeah I was thinking last night that my comments here were a lot more strident about this than I am in real life. I agree with your whole comment, except I think the middle ground between team-level management and program management is more often better served by tooling, architecture, requirements, or team structure changes rather than project management.
(I get it, sometimes the need for a lot of planning is imposed from the top, like if you sign a contract with an immovable delivery date, but I think most organizations should do whatever they can to avoid doing that, in order to enable them to structure projects flexibly and have small mostly-autonomous teams.)
I think the personality thing is important both in terms of contentment with your work (and thus which organizations and projects you choose) and in terms of how you analyze the relative value of things when evaluating trade-offs between the different things an organization can invest its time and resources on.
(I get it, sometimes the need for a lot of planning is imposed from the top, like if you sign a contract with an immovable delivery date, but I think most organizations should do whatever they can to avoid doing that, in order to enable them to structure projects flexibly and have small mostly-autonomous teams.)
I think the personality thing is important both in terms of contentment with your work (and thus which organizations and projects you choose) and in terms of how you analyze the relative value of things when evaluating trade-offs between the different things an organization can invest its time and resources on.
In our case we are a heavily regulated industry and the level of coordination, governance and compliance that is required to make change is shocking!
I agree that it's good if it's possible to avoid all that and still deliver what you need to!
Also agree that many people simply can't stand working in really heavyweight environments. While I dont love it, I can live with it.
I agree that it's good if it's possible to avoid all that and still deliver what you need to!
Also agree that many people simply can't stand working in really heavyweight environments. While I dont love it, I can live with it.
Yep! I think, somewhat humorously for how this thread started - which was entirely mea culpa! - our perspectives on this are pretty closely aligned.
One thing I think is that a lot (though not all!) of the requirements imposed in heavily-regulated industries are actively counter-productive, because they more effectively introduce friction on positive changes than risky ones. But it's basically impossible to strike the exact right balance between mitigating tail risks, which is critical, vs. introducing counter-productive friction. So I have sympathy, I just also find it very frustrating to work in such environments.
One thing I think is that a lot (though not all!) of the requirements imposed in heavily-regulated industries are actively counter-productive, because they more effectively introduce friction on positive changes than risky ones. But it's basically impossible to strike the exact right balance between mitigating tail risks, which is critical, vs. introducing counter-productive friction. So I have sympathy, I just also find it very frustrating to work in such environments.
Yeah, we aren't too far apart! It's why I like HN, you can actually have a civilised conversation :)
Friction certainly makes it harder to introduce positive change. I don't think it makes it easier to make riskier ones though, but you often can't do everything you'd like to get done.
Friction certainly makes it harder to introduce positive change. I don't think it makes it easier to make riskier ones though, but you often can't do everything you'd like to get done.
Just to clarify, I didn't mean regulatory friction makes it easier to do things that are risky. I think regulation is pretty much entirely successful at making that harder. What I meant is that, in my view, regulations that reduce the chance of tail risks by let's say X% often seem to increase the friction on making improvements by more like say 2X%. Of course this isn't scientific or anything, but it's my intuition, that the trade-off doesn't seem to be 1:1 when you take on some friction to reduce the likelihood of some tail risk.
Eh, in my current role (engineer) we have a PM but they’re not all that useful. In theory, they do what you describe, but because they don’t have a technical background they struggle to identify blockers & engineers drive most prioritisation sessions.
They may jump in occasionally to tell us another team needs X or the business wants to see more Y so we should re-think what we work on next, but I struggle to see why that couldn’t be handled by our technical team lead.
They may jump in occasionally to tell us another team needs X or the business wants to see more Y so we should re-think what we work on next, but I struggle to see why that couldn’t be handled by our technical team lead.
> Our team still got more done in a year with a fraction of a good PM than my current company has gotten done in over two years without any PMs
This is a great testimony. I think that stretching their capacity is a forcing function to stay high level and vision oriented, and avoid having PMs go too deep and start building up useless processes, or over-define features.
This is a great testimony. I think that stretching their capacity is a forcing function to stay high level and vision oriented, and avoid having PMs go too deep and start building up useless processes, or over-define features.
Product Management is a hard job. You need to be technical enough to understand whats happening and have a bullshit detector, but high EQ enough to speak human. The dumb ones become sort-of project managers, tracking another set of books for tasks. The smart ones tend to deeply understand the business and move up or out. It's also a tough role to govern in that sometimes they get alot of credit for the work of others, or get no credit for anything and languish from a career pov.
When this role is dumped into engineering, engineering management or general management, it weakens the engineering practice. If I need engineers, I need to select for that ability and frankly shield them from people on the outside. If the org requires that my teams handle interaction, now I'm hiring people with mixed skillsets in one org, which inevitably waters down the engineering side.
When this role is dumped into engineering, engineering management or general management, it weakens the engineering practice. If I need engineers, I need to select for that ability and frankly shield them from people on the outside. If the org requires that my teams handle interaction, now I'm hiring people with mixed skillsets in one org, which inevitably waters down the engineering side.
I really hope you're not implying that project managers are or need to be less smart than product managers.
They are different disciplines, and like any profession there's likely more people who are not good at it than people that are.
But I've worked with great visionary product people and excellent project and program managers (and strive to be one every day myself). Neither could do the other's job well or effectively. They need to be laser focused on different things, and their EQ tends to be tuned to different wavelengths.
They are different disciplines, and like any profession there's likely more people who are not good at it than people that are.
But I've worked with great visionary product people and excellent project and program managers (and strive to be one every day myself). Neither could do the other's job well or effectively. They need to be laser focused on different things, and their EQ tends to be tuned to different wavelengths.
Project managers usually don't need to know as much as product managers, or be as thoughtful as them to be a great value add. Project managers have a larger range of "acceptable" performance to be able to add value, so their job certainly is easier.
Perhaps it was inelegantly put by the original commenter, but I think the gist is that the product managers who lack some of the important product management skills around vision, ability to be customer facing, and effective and articulate communications tend to work more like project managers—effective acting as tactical managers within a product as opposed to strategic ones for the product.
We can define and name the roles all sorts of things (project manager, product owner, product manager, product marketing manager), but what it boils to is for any complex product there is a need for the management of the product at a holistic level and a need for management of a product at a granular level.
We can define and name the roles all sorts of things (project manager, product owner, product manager, product marketing manager), but what it boils to is for any complex product there is a need for the management of the product at a holistic level and a need for management of a product at a granular level.
I wasn’t writing a treatise on every occupation and was being a little jocular.
What I’ve witnessed over a 20 year career is that weak product people devolve to mediocre project managers. It’s easier to be a shitty project manager.
Good project managers are gold. I worked with one who stood out a decade ago - his leadership at execution was such that a $350M, 20 month implementation, with collaboration with construction, tech, and external suppliers completed 45 minutes ahead of the original schedule. He’s since retired and passed away, but an inspirational leader I was privileged to get to know. Ponder that - how many project managers are acknowledged as leaders?
What I’ve witnessed over a 20 year career is that weak product people devolve to mediocre project managers. It’s easier to be a shitty project manager.
Good project managers are gold. I worked with one who stood out a decade ago - his leadership at execution was such that a $350M, 20 month implementation, with collaboration with construction, tech, and external suppliers completed 45 minutes ahead of the original schedule. He’s since retired and passed away, but an inspirational leader I was privileged to get to know. Ponder that - how many project managers are acknowledged as leaders?
Couldn't agree more. I didn't really get project management until I'd worked with a few good ones.
> his leadership at execution was such that a $350M, 20 month implementation, with collaboration with construction, tech, and external suppliers completed 45 minutes ahead of the original schedule
This made me smile. I'm assuming you mean 45 days or something. Not that any number 'ahead of schedule' is inherently a bad thing (within reason), but my mind went to "Are there really companies out there tracking 2 year projects and counting the minutes?" (and sadly, there probably are).
This made me smile. I'm assuming you mean 45 days or something. Not that any number 'ahead of schedule' is inherently a bad thing (within reason), but my mind went to "Are there really companies out there tracking 2 year projects and counting the minutes?" (and sadly, there probably are).
It's a little tongue in cheek. There were completion incentives around certain tasks, especially on the construction and physical side, being completed on a date. Date was defined as 4PM on the date, and there was a financial benefit to be early in many cases. The last physical task required to be completed and submitted was done at 3:15, thus "45 minutes early".
That said, some major elements were tracked to the minute. I wish I could share more, it's a great story!
That said, some major elements were tracked to the minute. I wish I could share more, it's a great story!
> When this role is dumped into engineering, engineering management or general management, it weakens the engineering practice. If I need engineers, I need to select for that ability and frankly shield them from people on the outside. If the org requires that my teams handle interaction, now I'm hiring people with mixed skillsets in one org, which inevitably waters down the engineering side.
I'd argue that the position taken above weakens the engineering practice. Understanding requirements (e.g. constraints) is a core element of engineering, engineering management, and general management. Part of the problem plaguing the tech industry is the "dumping" of this responsibility, and others such as "project management" into some other role. What some like to call a "specialization" may also be called an abdication of responsibilities and ultimately accountability.
In my opinion, the essence of engineering is the methodical art and practice of solving problems. A fundamental part of engineering is understanding the problem(s) to be solved, the constraints, as well as the trade space and trade offs of solutions for those problems.
Not all aspects of (engineering) problems are "technical" in nature, and a failure to understand this and cultivate this understanding weakens the engineering practice.
I'd argue that the position taken above weakens the engineering practice. Understanding requirements (e.g. constraints) is a core element of engineering, engineering management, and general management. Part of the problem plaguing the tech industry is the "dumping" of this responsibility, and others such as "project management" into some other role. What some like to call a "specialization" may also be called an abdication of responsibilities and ultimately accountability.
In my opinion, the essence of engineering is the methodical art and practice of solving problems. A fundamental part of engineering is understanding the problem(s) to be solved, the constraints, as well as the trade space and trade offs of solutions for those problems.
Not all aspects of (engineering) problems are "technical" in nature, and a failure to understand this and cultivate this understanding weakens the engineering practice.
> I'd argue that the position taken above weakens the engineering practice. Understanding requirements (e.g. constraints) is a core element of engineering, engineering management, and general management.
Determination, evaluation, and articulation of requirements is the sweet spot of the product manager role. Understanding those requirements is certainly necessary for an engineer to build to the requirements.
Determination, evaluation, and articulation of requirements is the sweet spot of the product manager role. Understanding those requirements is certainly necessary for an engineer to build to the requirements.
An engineer's understanding of requirements entails determination, evaluation, and articulation of those requirements. Calling oneself an engineer doesn't preclude their ability to do these things, and force them to call themselves a "product manager" for doing so. And quite often, especially at more senior levels, an engineer must do these things.
Once upon a time, this too was a formalized practice in engineering that people called "Systems Engineering":
https://en.wikipedia.org/wiki/Systems_engineering
https://www.nasa.gov/reference/2-0-fundamentals-of-systems-e...
Once upon a time, this too was a formalized practice in engineering that people called "Systems Engineering":
https://en.wikipedia.org/wiki/Systems_engineering
https://www.nasa.gov/reference/2-0-fundamentals-of-systems-e...
Doesn’t preclude the ability, no, but there are only so many hours in the day.
Writing good code is a very separate skill set from that kind of problem-space work, and software engineers are mostly hired for the former.
Writing good code is a very separate skill set from that kind of problem-space work, and software engineers are mostly hired for the former.
Once you get to staff+ level, engineers are no longer hired mostly for writing good code.
That’s fair, but that is… what, 1% of all software engineer hires?
I don’t know about as a percent of total hires, because staff+ engineers tend to stick around a bit longer. But in my current bigco it’s a bit north of 10% and I’ve seen it go as high as 20%.
It does, but it's still not something engineers do well.
Imagine developing an AAA game with no one in charge of the overall product. Or creating a movie without a producer or a director, expecting the talent to somehow organise itself.
PM isn't an engineering job, it's a vision job - one that needs enough technical knowledge to create a vision that's grounded in reality, while also appealing to customers, while also being able to sell it up and down the org.
That skillset is incredibly rare.
Imagine developing an AAA game with no one in charge of the overall product. Or creating a movie without a producer or a director, expecting the talent to somehow organise itself.
PM isn't an engineering job, it's a vision job - one that needs enough technical knowledge to create a vision that's grounded in reality, while also appealing to customers, while also being able to sell it up and down the org.
That skillset is incredibly rare.
Separating product from engineering, engineering management, and general management does not mean 1 person is in charge. Integrating them does not mean no one is.
The article was all about the consequences of the skill set being incredibly rare.
The article was all about the consequences of the skill set being incredibly rare.
That was well put. Imagine that. Still we train our product managers to follow checklists, write endless documents about personas, have discussions about methodology and such things only loosely connected to the work that goes into making the actual product.
Imagine if a director was a bureaucrat. One who followed checklists and made policy documents, and did not have the slightest clue about the actual craft of setting lights, working the camera, and acting.
What's our profession's equivalent of a film director? One with deep knowledge about data structures, who cared about getting it right, together with professionals?
Imagine if a director was a bureaucrat. One who followed checklists and made policy documents, and did not have the slightest clue about the actual craft of setting lights, working the camera, and acting.
What's our profession's equivalent of a film director? One with deep knowledge about data structures, who cared about getting it right, together with professionals?
> What's our profession's equivalent of a film director?
Scrum master.
Scrum master.
Hardly. Scrum master is more like a production assistant. Make sure everyone knows when and where they are supposed to be. Communicate any issues with the plan
Good engineers work to deeply understand the problem given to them. They understand the different possible solutions, and implement the best one they can, given their constraints.
Good product managers identify the problems to be solved, and prioritize which ones should be solved first.
Good product managers identify the problems to be solved, and prioritize which ones should be solved first.
> If the org requires that my teams handle interaction, now I'm hiring people with mixed skillsets in one org, which inevitably waters down the engineering side.
Why on earth would being able to handle interactions “water down” engineering? They’re two perpendicular skillsets. We’re not in Hollywood, engineers don’t have to be autistic
Why on earth would being able to handle interactions “water down” engineering? They’re two perpendicular skillsets. We’re not in Hollywood, engineers don’t have to be autistic
[deleted]
> maintain relationships with customers, interview users to identify potential features
Those are the marketing people. On most places they are stupidly completely focused on sales, but that's not ideal.
Product management is also a task for those people, but singlemindly focusing them on PM is about as bad as doing that for sales.
> manage leadership, play politics for resource allocation
And those are management tasks. It makes no sense at all to give both sets of tasks to the same set of people.
Those are the marketing people. On most places they are stupidly completely focused on sales, but that's not ideal.
Product management is also a task for those people, but singlemindly focusing them on PM is about as bad as doing that for sales.
> manage leadership, play politics for resource allocation
And those are management tasks. It makes no sense at all to give both sets of tasks to the same set of people.
PMs at most companies DO NOT play politics for resource management, the stakeholders are frequently just other departments within the company so there isn’t a lot of maintaining client relationships. TPMs with sales people are generally the ones that maintain relationships with clients. PMs do very little besides put out a high level requirement document that then truly gets fleshed out by the engineering team and the EMs.
Every thing you just said rings true. I went from 20 years engineering into engineering management, and took my first PM role last year. I took the role at a twenty year-old software company that's never had good product management, and the place is horrible.
Over and over, the staff were pounded with "we are an engineering first company." Well, that means the engineering teams were allowed to do whatever the hell they wanted and chase the shiny newest techs. There's 3.5 main products (really 4.5) each made from a different tech stack. There's another eight or so legacy products we have to support due to legacy demands. There's no inter-operability of standardization between products. Basically, there's no knowledge transfer, so the cost of development is through the roof.
Twice this year, I had to explain to 20 year-tenure engineers that don't understand why it's a bad thing that one API is TLS 1.3 only, another is 1.x, and another doesn't even require TLS.
Customers hate us. For my product, they literally wrote the marketing materials first, and let the engineers figure it out. One stage of my product takes Oracle data and puts it into parquet. The guys who did it did it in three different languages, two other DBs inbetween (MySQL AND PG), and was going to introduce Redis before I stopped the insanity. Everything is fragile and sucks.
Thankfully, PE took over two years ago and we now have an ultimatum to make money or else. We are a twenty year old company that has never made money (we've been a cost center). Even if we don't meet it, I feel like the Universe will be better off without the travesties against software design that we created.
Over and over, the staff were pounded with "we are an engineering first company." Well, that means the engineering teams were allowed to do whatever the hell they wanted and chase the shiny newest techs. There's 3.5 main products (really 4.5) each made from a different tech stack. There's another eight or so legacy products we have to support due to legacy demands. There's no inter-operability of standardization between products. Basically, there's no knowledge transfer, so the cost of development is through the roof.
Twice this year, I had to explain to 20 year-tenure engineers that don't understand why it's a bad thing that one API is TLS 1.3 only, another is 1.x, and another doesn't even require TLS.
Customers hate us. For my product, they literally wrote the marketing materials first, and let the engineers figure it out. One stage of my product takes Oracle data and puts it into parquet. The guys who did it did it in three different languages, two other DBs inbetween (MySQL AND PG), and was going to introduce Redis before I stopped the insanity. Everything is fragile and sucks.
Thankfully, PE took over two years ago and we now have an ultimatum to make money or else. We are a twenty year old company that has never made money (we've been a cost center). Even if we don't meet it, I feel like the Universe will be better off without the travesties against software design that we created.
In my experience, the vast majority of PMs could not describe the difference between TLS 1.3 and 1.x.
The problems you describe are legit but unless you have extremely technical product managers, hiring more PMs will only make the problem worse.
The problems you describe are legit but unless you have extremely technical product managers, hiring more PMs will only make the problem worse.
I do believe that the traditional PM role/background should be considered obsolete, especially in software companies. Well-rounded engineers should be in these roles these days.
Are there enough of them?
The vast majority of engineers I encountered do not have what it takes to be a good PM. I'm an engineer myself.
> In my experience, the vast majority of PMs could not describe the difference between TLS 1.3 and 1.x.
Does the vast majority of PMs need to tell the difference between TLS 1.3 and 1.x?
I mean, is that a relevant aspect of the vast majority of products?
If not, why should a PM bother about irrelevant details?
One of the cardinal sins of proponents of this "engineers should rule everything" mentality is failing to tell apart the critical factors from the irrelevant details, and conflate not caring about obscure implementation details with incompetence. Except the cheekiest little fallacy in software development circles is that the purpose of all software projects is not correctness or code coverage or uptime or resilience. The purpose of each and every single software project is to serve their users' interests. That's the critical part of a project, and the thing that PMs focus on for the right reasons. Naturally, PMs prioritize work with the biggest impact. Does TLS trivia fit this requirement? No.
Does the vast majority of PMs need to tell the difference between TLS 1.3 and 1.x?
I mean, is that a relevant aspect of the vast majority of products?
If not, why should a PM bother about irrelevant details?
One of the cardinal sins of proponents of this "engineers should rule everything" mentality is failing to tell apart the critical factors from the irrelevant details, and conflate not caring about obscure implementation details with incompetence. Except the cheekiest little fallacy in software development circles is that the purpose of all software projects is not correctness or code coverage or uptime or resilience. The purpose of each and every single software project is to serve their users' interests. That's the critical part of a project, and the thing that PMs focus on for the right reasons. Naturally, PMs prioritize work with the biggest impact. Does TLS trivia fit this requirement? No.
Generally it is quite important especially for SaaS. Old TLS will cause SOC2 cert, PCI cert failures and similar. It is the kind of thing that can derail a major deal as often the 'whale' clients are the ones that really care about security certs while smaller companies and startups don't.
Non-technical PMs tend to gloss over things like that as an engineering-driven feature. Clients don't ask for TLS 1.3 (at least until it's often too late) because they generally aren't considering TLS trivia until it comes time for their next audit.
Non-technical PMs tend to gloss over things like that as an engineering-driven feature. Clients don't ask for TLS 1.3 (at least until it's often too late) because they generally aren't considering TLS trivia until it comes time for their next audit.
> Generally it is quite important especially for SaaS.
You see, I don't think that's true at all. If it was, certainly you'd have clients complain loudly enough for the PMs to notice.
But that doesn't seem to even register a concern, both from the client and from the PM point of view.
Convenience is a nice-to-have, and fixing problems that don't exist registers even lower in the priority queue.
> Non-technical PMs tend to gloss over things like that (...)
See, this is where I think we disagree at a very basic level.
There is no such thing as a technical and non-technical Product Manager, because a product isn't technical. A product is something that meets the needs and expectations of its customers. A Product Manager's responsibility is to know their product and manage it to meet its clients' needs, and in the process help guide the development effort to maximize its returns on investment. Whether it's to paint a button red instead of blue, or to tell if they need to upgrade TLS, a PM's job is to read the room and deliver what meets the needs.
You see, I don't think that's true at all. If it was, certainly you'd have clients complain loudly enough for the PMs to notice.
But that doesn't seem to even register a concern, both from the client and from the PM point of view.
Convenience is a nice-to-have, and fixing problems that don't exist registers even lower in the priority queue.
> Non-technical PMs tend to gloss over things like that (...)
See, this is where I think we disagree at a very basic level.
There is no such thing as a technical and non-technical Product Manager, because a product isn't technical. A product is something that meets the needs and expectations of its customers. A Product Manager's responsibility is to know their product and manage it to meet its clients' needs, and in the process help guide the development effort to maximize its returns on investment. Whether it's to paint a button red instead of blue, or to tell if they need to upgrade TLS, a PM's job is to read the room and deliver what meets the needs.
> If not, why should a PM bother about irrelevant details?
Because engineering failed to consider these details. Now I'm the one that has to point out how amateur we look when in some areas we don't require TLS and others we're so strict, we only have 1.3. Engineers (management or rank and file) who can't understand why this is a problem is exactly the reason you need technical PMs.
Because engineering failed to consider these details. Now I'm the one that has to point out how amateur we look when in some areas we don't require TLS and others we're so strict, we only have 1.3. Engineers (management or rank and file) who can't understand why this is a problem is exactly the reason you need technical PMs.
> Because engineering failed to consider these details.
I don't think you got the point. The point is that no one cares, or think it's important enough and much less critical to justify wasting time with it. Product Managers are there to create value, and spending time on things no one notices is not how you create value.
I don't think you got the point. The point is that no one cares, or think it's important enough and much less critical to justify wasting time with it. Product Managers are there to create value, and spending time on things no one notices is not how you create value.
A good PM doesn't have to know the differences, but should understand that mixing encryption protocols is going to break things. Ideally an eng lead would be flagging these issues.
This certainly sounds like your company is having a gap. But the gap sounds to me more like the lack of technical leadership (a strong lead, principal engineer, etc) than a PM. 10 out of 10 PMs I worked with (and it had been more) wouldn't commend on software architecture and internals and wouldn't prevent the needless complexity and unmaintainability aspects. They can at most point out that feature development and bugfixes are too slow, and then its up to the engineering team to improve on this. But also for 10 out of 10 PMs feature development will always be too slow, since customers are asking for things being done yesterday, so this alone isn't a great indicator that engineering is broken.
APIs using different TLS versions falls into the same category. Unless the TLS version is part of the product (which is the case for e.g. API Gateways, webservers and proxies) PMs will likely not care. They should however care about the difference between no TLS at all and a "somewhat modern TLS", because "no security" is definitely an important gap in the product.
APIs using different TLS versions falls into the same category. Unless the TLS version is part of the product (which is the case for e.g. API Gateways, webservers and proxies) PMs will likely not care. They should however care about the difference between no TLS at all and a "somewhat modern TLS", because "no security" is definitely an important gap in the product.
A lack of engineering leadership is certainly true. As is often told, the VP of engineering enjoyed creating PRs more than actually leading. There has never been an architect.
The point is though, product never challenged on approaches, and you’re right. They never came from technical backgrounds. Product managers were promoted from the BA ranks. They never raised technical questions like that - “Is it a bad thing if the customer has to connect this way for this API and another way for another API?” If the idea is that engineering asks those questions, I’d counter with that’s venturing squarely into product’s realm.
The point is though, product never challenged on approaches, and you’re right. They never came from technical backgrounds. Product managers were promoted from the BA ranks. They never raised technical questions like that - “Is it a bad thing if the customer has to connect this way for this API and another way for another API?” If the idea is that engineering asks those questions, I’d counter with that’s venturing squarely into product’s realm.
I don't claim greatness at modern product design/theory, but I'd expect "what version(s) of TLS are supported?" to be primarily an engineering responsibility (say 80-90%) versus a product concern (say 10-20%).
I think that most "good" engineering managers share the same traits as good Product Managers.
- Someone to understand the customer's desires and shut down unnecessary work.
- Drive the team to deliver features that the customers/business actually needs.
- drive tech decisions to prevent future inoperability with other products
- roadshow and maintain a team's reputation across the org
- etc
- Someone to understand the customer's desires and shut down unnecessary work.
- Drive the team to deliver features that the customers/business actually needs.
- drive tech decisions to prevent future inoperability with other products
- roadshow and maintain a team's reputation across the org
- etc
If TLS version support was materially affecting your client’s ability to integrate with your products’ APIs then the Product Manager should have picked this up and worked with the development team on a way to remove this friction.
I can think of a bunch of different ways of solving this that would take a few days to build out.
I can think of a bunch of different ways of solving this that would take a few days to build out.
I agree. Founders who are bad engineers surround themselves with non-technical people who don’t question them.
How does a company not make any money for 20 years that sounds insane
I don’t know if it applies to the situation the GP described, but profit != revenue.
It seems to me, especially in the wild and woolly mom-n-pop end of the market, that there might be ample room for a company to sustainably put food on a certain number of employees’ family tables without much left over to characterize as profit.
It seems to me, especially in the wild and woolly mom-n-pop end of the market, that there might be ample room for a company to sustainably put food on a certain number of employees’ family tables without much left over to characterize as profit.
I work at a 20 year old company about like this. We’re all comfortable, it’s really nice.
cost center
Most the problems described here are just bad software engineering. Never seen a PM with any oversight on which DB is used, how shiny the tech is, how the API works, any of that. It definitely seems like there's a lack of coherence and customer focus, which would be in the PM's wheelhouse to deal with, but that's it. Need a better lead engineer with the time and authority to implement good practices.
the grift is strong with this one.
well just remember that engineers do this to have portfolio pieces on their resume. they need validation from other people that they worked on a software stack, and to be able to do live interview assignments about that software stack.
this actually just another symptom of a really bad interviewing process where nobody can tell that you're a competent engineer unless you pigeon-hole yourself to one stack that might not always have jobs for it, or for very long. there is also pressure to work on the coolest software stacks, because maybe you will be a scarce resource for a few years and get a major premium in compensation on the fastest growing companies. the other symptom is that companies aren't doing training, they're allergic to it, so they only want engineers that have years of potentially verifiable experience working on the exact stack they have, so that engineer could "hit the ground running" despite needing to keep the job opening up for 6 months to find that person.
well just remember that engineers do this to have portfolio pieces on their resume. they need validation from other people that they worked on a software stack, and to be able to do live interview assignments about that software stack.
this actually just another symptom of a really bad interviewing process where nobody can tell that you're a competent engineer unless you pigeon-hole yourself to one stack that might not always have jobs for it, or for very long. there is also pressure to work on the coolest software stacks, because maybe you will be a scarce resource for a few years and get a major premium in compensation on the fastest growing companies. the other symptom is that companies aren't doing training, they're allergic to it, so they only want engineers that have years of potentially verifiable experience working on the exact stack they have, so that engineer could "hit the ground running" despite needing to keep the job opening up for 6 months to find that person.
> I took the role at a twenty year-old software company that's never had good product management, and the place is horrible.
> Over and over, the staff were pounded with "we are an engineering first company." Well, that means the engineering teams were allowed to do whatever the hell they wanted and chase the shiny newest techs. There's 3.5 main products (really 4.5) each made from a different tech stack. There's another eight or so legacy products we have to support due to legacy demands. There's no inter-operability of standardization between products. Basically, there's no knowledge transfer, so the cost of development is through the roof.
I read this and thought you worked at my previous employer (household name in IT).
Engineering first company. Oof. This meant that as a PM, I got introduced to two of the products I'd be managing when Engineering and Architects had come up with a grand idea to build a component/subsystem to replace a previous one which had been over-engineered and never gained traction. They hadn't talked to any customers who used it, or that had liked the idea, but not the execution. They were just given a wide latitude to experiment (don't get me wrong, some experimentation and exploration is useful), got a greenlight for some time to prototype it, and did so.
And then, and only then, was I called in as a PM, and told, here's our prototype, here's some vague documentation of what we wanted to solve with this - "Now, Mr PM, can you shoehorn a Product Requirements Document around what we've already built and where we see it going, and can you do the Market Requirements Document to answer the questions we probably should have asked before getting this far?"
And then I would get catch-22s. Express doubt over the needed research and potential for the product and I was told by management that "PMs need to be passionate and fearless advocates for their products"... and then when I do try to eke something out, but lo and behold, our internal 'market', let alone customers are ambivalent about why we are working on a "v2" of this feature, when the market is either accepting the weaknesses of "v1" or have long built out their own solutions and moved on, and as a result we have a stakeholders meeting where we decide to end the experiment, and I'm chastised for "poor product management judgment" for not killing the project far earlier... the project I have no authority to kill, because it's an Engineering first company, and the project whose existence I learned of when it was tossed into my lap as a 90% complete prototype/proof of concept.
And then you have a few hundred (yep) Product Managers in our BU all trying to do their own thing, some empire-building, some truly product-focused... and it's a shit show.
I love being a product manager. I took a similar path as you... although most of my engineering background is SysAdmin/Devops/SRE/infrastructure and then management thereof. I love being a product manager, and thought that this role, at this company, would have untold potential and I could settle in, learn, grow, build from there. But it was everything from a Dilbert cartoon.
I read this and thought you worked at my previous employer (household name in IT).
Engineering first company. Oof. This meant that as a PM, I got introduced to two of the products I'd be managing when Engineering and Architects had come up with a grand idea to build a component/subsystem to replace a previous one which had been over-engineered and never gained traction. They hadn't talked to any customers who used it, or that had liked the idea, but not the execution. They were just given a wide latitude to experiment (don't get me wrong, some experimentation and exploration is useful), got a greenlight for some time to prototype it, and did so.
And then, and only then, was I called in as a PM, and told, here's our prototype, here's some vague documentation of what we wanted to solve with this - "Now, Mr PM, can you shoehorn a Product Requirements Document around what we've already built and where we see it going, and can you do the Market Requirements Document to answer the questions we probably should have asked before getting this far?"
And then I would get catch-22s. Express doubt over the needed research and potential for the product and I was told by management that "PMs need to be passionate and fearless advocates for their products"... and then when I do try to eke something out, but lo and behold, our internal 'market', let alone customers are ambivalent about why we are working on a "v2" of this feature, when the market is either accepting the weaknesses of "v1" or have long built out their own solutions and moved on, and as a result we have a stakeholders meeting where we decide to end the experiment, and I'm chastised for "poor product management judgment" for not killing the project far earlier... the project I have no authority to kill, because it's an Engineering first company, and the project whose existence I learned of when it was tossed into my lap as a 90% complete prototype/proof of concept.
And then you have a few hundred (yep) Product Managers in our BU all trying to do their own thing, some empire-building, some truly product-focused... and it's a shit show.
I love being a product manager. I took a similar path as you... although most of my engineering background is SysAdmin/Devops/SRE/infrastructure and then management thereof. I love being a product manager, and thought that this role, at this company, would have untold potential and I could settle in, learn, grow, build from there. But it was everything from a Dilbert cartoon.
You can stil be engineering focused (whatever that means) and have strong leadership. The issue is that a person who lacks significant stake in the company (i.e. most) is not going to want to be a strong leader - you're just risking yourself as personally accountable for any failures vs. limited rewards.
> Very few engineers want to maintain relationships with customers, interview users to identify potential features, manage leadership, play politics for resource allocation, and so on.
I’ve never met a PM that did any of that either ;)
I’ve never met a PM that did any of that either ;)
> Very few engineers want to maintain relationships with customers
That’s what CX is for.
> interview users to identify potential features
That’s what designers are for.
> manage leadership, play politics for resource allocation
That’s what your lead/people manager is for.
You don’t need a PM. You need an org chart.
That’s what CX is for.
> interview users to identify potential features
That’s what designers are for.
> manage leadership, play politics for resource allocation
That’s what your lead/people manager is for.
You don’t need a PM. You need an org chart.
This might make sense for a company with one product, but for a larger company with many products, there's a lot of benefit in having one person per product who understands their product deeply, and can put on any of these hats when required to make the product better.
Seems like you’d have a lot of overlap if what the PM is doing are the activities I listed, and you also employ the people I listed.
Also, what engineer doesn’t understand the product deeply from both a technical and business perspective? Maybe a contract dev, or a new hire.
Also, what engineer doesn’t understand the product deeply from both a technical and business perspective? Maybe a contract dev, or a new hire.
It’s about responsibility, the PM is responsible for the success of a product. To achieve this he collaborates with all the parties you mention, but in the end the PM has the responsibility. Key in this is bringing together knowledge of the market, the competitors, the customer problems, the value of a solution to these customers, determining a roadmap that will lead towards a successful product, coordinate launch, service, support, and continuous monitoring of the state of the product (does it have the right features, what is the competition doing, what does sales need to effectively sell the product, etc).
Reforge provides good training for product managers. This article provides a good overview of a role of a PM: https://www.reforge.com/previews/product/what-does-a-product...
Reforge provides good training for product managers. This article provides a good overview of a role of a PM: https://www.reforge.com/previews/product/what-does-a-product...
Having one product owner is fine. The problem is that it should be a role someone moves into from one of the disciplines involved. Design, engineering, domain expert etc…
Now we have Product Manager orgs with Associate PMs, junior PMs, senior PMs, group PMs etc…
A junior PM almost by definition can’t be a product owner. They don’t have the seniority to make decisions, so what you end up with is a situation where senior PMs are handing down solutions to junior PMs who are coming up with even more detailed solutions to engineers. I’ve seen it time and again.
Now we have Product Manager orgs with Associate PMs, junior PMs, senior PMs, group PMs etc…
A junior PM almost by definition can’t be a product owner. They don’t have the seniority to make decisions, so what you end up with is a situation where senior PMs are handing down solutions to junior PMs who are coming up with even more detailed solutions to engineers. I’ve seen it time and again.
Product Owner and Product Manager is not the same, especially in a larger organizations. Product Managers usually dont manage sprint backlogs, as its too fine grained. I often see sprint backlog that contain 20+ stories that add up to 1 customer facing capability/feature.
I’m not talking about “product owner” as it’s practiced in shitty scrum orgs.
I mean product owner as in the person responsible for the product.
I mean product owner as in the person responsible for the product.
> That’s what designers are for.
Designers interview people, and potential features may come out of that. They don't put those potential features into a roadmap and allocate resources to them. I'm a designer: if it were up to me, I'd spend 99% of my time improving the UX of the product we have, because that's what I care about most. Somebody has to own the vision for the product with respect to the company's business goals, and individual designers and engineers are not the right people for that. Maybe I ought to have phrased that better originally.
Designers interview people, and potential features may come out of that. They don't put those potential features into a roadmap and allocate resources to them. I'm a designer: if it were up to me, I'd spend 99% of my time improving the UX of the product we have, because that's what I care about most. Somebody has to own the vision for the product with respect to the company's business goals, and individual designers and engineers are not the right people for that. Maybe I ought to have phrased that better originally.
> individual designers and engineers are not the right people for that
That kind of depends. The product-minded ones (who are naturally interested in the "producty" kind of work) are excellent people for that. So you may find that in some companies the people doing product work are either engineers or designers. I've often done that from the engineering side, and I've seen it done really excellently by UX designers too. In other companies you may have dedicated people.
In my experience, whether it works well or not is less a function of how the roles are divided and more a function of whether the individuals doing product work are good at product work (which is difficult to find, even when they are dedicated product specialists). I think I would probably argue that due to the nature of the job being a lot about connecting different functions of the business and synthesising into a coherent whole, product people tend (on average) to better at their job when they do also have experience with at least some of the other roles they are interacting with (although this isn't necessary to do the job well).
That kind of depends. The product-minded ones (who are naturally interested in the "producty" kind of work) are excellent people for that. So you may find that in some companies the people doing product work are either engineers or designers. I've often done that from the engineering side, and I've seen it done really excellently by UX designers too. In other companies you may have dedicated people.
In my experience, whether it works well or not is less a function of how the roles are divided and more a function of whether the individuals doing product work are good at product work (which is difficult to find, even when they are dedicated product specialists). I think I would probably argue that due to the nature of the job being a lot about connecting different functions of the business and synthesising into a coherent whole, product people tend (on average) to better at their job when they do also have experience with at least some of the other roles they are interacting with (although this isn't necessary to do the job well).
A product manager works at a higher level than those roles. They aren't implementers - they collect information, identify needs, create plans, and get approvals. And then direct the roles you mentioned to do the work needed.
A PM will say things like: "I spent 120 hours talking with our users last quarter. They want a macro language added to the product to make their work easier. Our major competitor already has this feature. We have a budget from the executives and 6 months to get it done. We can get the CX person to do some focus groups to figure out how the users expect it to work, the designer to create some interface options for everyone to choose between and then do the UI wireframes, then the leads can work together to plan the coding schedule based on the implementation phases I will give them."
A PM will say things like: "I spent 120 hours talking with our users last quarter. They want a macro language added to the product to make their work easier. Our major competitor already has this feature. We have a budget from the executives and 6 months to get it done. We can get the CX person to do some focus groups to figure out how the users expect it to work, the designer to create some interface options for everyone to choose between and then do the UI wireframes, then the leads can work together to plan the coding schedule based on the implementation phases I will give them."
A project manager will do most of that without the unearned self-importance, minus the talking to customers part which should either be done by product marketing or design, depending on the specific business insight you seek.
yeah +1, I used to wear the product manager hat in an engineering role, while working with bad product managers, and so I thought the role was a grift at best. Also dealing with a herd of b2b clients sucked while trying to focus on doing the things we argued about / committed to doing. Then a good PM got hired, he actually understands what's going on / makes the effort to learn, and the life of "Engineering" roles got so much better. It may be significant in this case that product works with engineering in a kind of liason role and doesn't "dictate" much.
Now program managers, it remains to be seen where their value comes from and I hope it does
Now program managers, it remains to be seen where their value comes from and I hope it does
Yeah, the problem is that accountability for PMs is usually missing. No one checks whether the PM is adding or removing effectiveness, so the good PMs go unrecognized and the bad ones keep siphoning energy from the project.
Second, bad PMs just create unnecessary work for everyone around them. Everyone believes they just have to do what the PM says, and then suddenly you have a whole eng team contributing nothing.
Second, bad PMs just create unnecessary work for everyone around them. Everyone believes they just have to do what the PM says, and then suddenly you have a whole eng team contributing nothing.
I've legit seen PM's just move their own deadlines. Their decision, no attempt at justification, and I've seen it put everyone behind because they're waiting on the PM. I've legit seen a PM deliver a set of requirements 3 days before a deadline and blame the technical team for non-delivery (multiple times!).
It sounds so ridiculous, and yet ... it happened.
It sounds so ridiculous, and yet ... it happened.
> Now program managers, it remains to be seen where their value comes from and I hope it does
in my experience, they manage project managers for systems with a high degree of complexity, e.g. an aircraft, and the product managers work through them, instead of through project managers directly. Or they are themselves the product manager, just with different terminology depending on the industry
in my experience, they manage project managers for systems with a high degree of complexity, e.g. an aircraft, and the product managers work through them, instead of through project managers directly. Or they are themselves the product manager, just with different terminology depending on the industry
What made that one PM great? What did they do or what was their philosophy? The outcome was that they got the team to be more productive, but what was the input that differed from the other PMs?
I can't really say. I'll describe some of the things I observed: they had incredibly good people skills with both customers and coworkers, they had the ability to ask incisive questions, and make good decisions with imperfect information, they context switched smoothly, they were well organized, and they made people excited about what they were working on. They also worked longer hours than anyone I know of at the company.
This sounds like a combination of charisma, leadership, and drive, which makes sense as a pretty rare set of qualities for one person to have.
... And reading that, I think I left out that they were super nice, and everybody liked them.
This sounds like a combination of charisma, leadership, and drive, which makes sense as a pretty rare set of qualities for one person to have.
... And reading that, I think I left out that they were super nice, and everybody liked them.
[deleted]
>there aren't enough good PMs to go around. My belief is the number of people cut out to be a good product manager scales linearly with the size of the population. You need certain personality traits and other qualities that can't be taught. You can mint mediocre PMs in school, but you can't make good ones that way, let alone great ones.
there aren't enough good software developers to go around. My belief is the number of people cut out to be a good software developer scales linearly with the size of the population. You need certain personality traits and other qualities that can't be taught. You can mint mediocre SWDevs in school, but you can't make good ones that way, let alone great ones.
there aren't enough good software developers to go around. My belief is the number of people cut out to be a good software developer scales linearly with the size of the population. You need certain personality traits and other qualities that can't be taught. You can mint mediocre SWDevs in school, but you can't make good ones that way, let alone great ones.
So you're saying that the dude fired in 'Office Space' for bringing the specs from customers to engineers was necessary?
> What happens is that the things a PM does do not get done. Very few engineers want to maintain relationships with customers, interview users to identify potential features, manage leadership, play politics for resource allocation, and so on. So it doesn't get done.
That's not what a PM does. You're missing leaders.
Customer relations is generally under sales. Resource allocations, politics, that's engineering leadership stuff.
Customer interviews is part of what a PM (or UXer) does. It's never been a critical pain point in any business I've been though. It's part of defining the product, oftentimes companies have a X years backlog of features users asked for and not enough time to build.
That's not what a PM does. You're missing leaders.
Customer relations is generally under sales. Resource allocations, politics, that's engineering leadership stuff.
Customer interviews is part of what a PM (or UXer) does. It's never been a critical pain point in any business I've been though. It's part of defining the product, oftentimes companies have a X years backlog of features users asked for and not enough time to build.
Customer relations under sales? Who does that??
Want to corroborate, been through several companies and several PMs. The excellent ones are rare, and have disproportionate impact in the team's performance.
I can relate to this. At my previous company, the first PM our team had was absolutely amazing. She had an engineering background but transitioned to management ten or so years ago. At some point, she was promoted and the replacement PM, while good, was not as good.
Fast-forward to my current company, the PMs here are absolutely shocking. The people they report to have no clue. It seems like every PM at my company has fallen upwards, as a result of newly hired PMs quitting shortly after they join. Engineers here are technically competent, but lack direction. Projects spin up before requirements have been defined, leading to massive losses of time. I’ve considered reaching out to my former company’s PMs to offer a referral, but it’d be a disservice to them.
Fast-forward to my current company, the PMs here are absolutely shocking. The people they report to have no clue. It seems like every PM at my company has fallen upwards, as a result of newly hired PMs quitting shortly after they join. Engineers here are technically competent, but lack direction. Projects spin up before requirements have been defined, leading to massive losses of time. I’ve considered reaching out to my former company’s PMs to offer a referral, but it’d be a disservice to them.
As a PM I think this is spot on.
The path to becoming a great PM is longer and arguably harder than becoming a great engineer. Like you say a lot of what makes a great PM comes from years of experience in a variety of roles and companies.
The path to becoming a great PM is longer and arguably harder than becoming a great engineer. Like you say a lot of what makes a great PM comes from years of experience in a variety of roles and companies.
> Very few engineers want to maintain relationships with customers, interview users to identify potential features, manage leadership, play politics for resource allocation, and so on.
Because the more you do, the more you are responsible for, but what you get doesn't increase. It's a question of profit distribution.
Because the more you do, the more you are responsible for, but what you get doesn't increase. It's a question of profit distribution.
Apple never had product managers while Steve Jobs was alive.
The closest they had was Steve Jobs and Product MARKETING Managers, which are quite different than Product Managers.
The closest they had was Steve Jobs and Product MARKETING Managers, which are quite different than Product Managers.
When I was at Apple (during the interregnum between Jobs’ reigns) we had people called product managers, but yeah they were mostly about getting the product to market and interacting with the market.
We had project managers who nominally controlled product design decisions. We had test managers in a separate testing directorate (I was one of those).
My experience was that the three managers worked together to define the product, with the product manager trying to represent the market, the project manager representing engineering, and test manager asking pointed questions.
We had project managers who nominally controlled product design decisions. We had test managers in a separate testing directorate (I was one of those).
My experience was that the three managers worked together to define the product, with the product manager trying to represent the market, the project manager representing engineering, and test manager asking pointed questions.
I can't post a comment so I'll report a typo here:
"People are hired based on whether they’d represent no treat"
I think author means "threat".
"People are hired based on whether they’d represent no treat"
I think author means "threat".
More than a dozen years in tech have taught me that roles are simply ways of expressing organizational wishes. You want someone who thinks about something as a product? You open a PM position. You want a team lead? Here's an EM position. Job titles are elements of fiction that allow us to play that RPG called work under different angles. What you ultimately bring to work is your unique mix of talents and experience.
Some people will often break the boundaries of those roles, though, and that's ok. They have ideas and might even come up with their own job titles. An organization must be smart enough to let that people grow and thrive. That doesn't mean one cannot thrive as a PM, or do great work; it's just that an organization usually cannot invest time in deeply knowing who they're getting onboard and so offer precooked roles.
Some people will often break the boundaries of those roles, though, and that's ok. They have ideas and might even come up with their own job titles. An organization must be smart enough to let that people grow and thrive. That doesn't mean one cannot thrive as a PM, or do great work; it's just that an organization usually cannot invest time in deeply knowing who they're getting onboard and so offer precooked roles.
[emoji reaction: 100%];
[emoji reaction: thanks]
Wow, I guess this was un-funny enough to warrant downvoting.
> An organization must be smart enough to let that people grow and thrive.
Agree 100%, but this is where I've seen a lot of organizations fail, especially large ones.
Agree 100%, but this is where I've seen a lot of organizations fail, especially large ones.
Yes! I've really bought into this idea recently. Roles are about hiring someone to always think about things from that particular perspective.
Eng are capable of being PMs, but they will never think about everything from the PM point of view, because they are primarily engineers not PMs.
Something else I've realized in line with breaking the boundaries of roles is that usually, the most valuable aspects of a person's role are the responsibilities that are not explicitly defined. Hard to explain, but often people provide value in ways that are hard to describe and quantify.
Eng are capable of being PMs, but they will never think about everything from the PM point of view, because they are primarily engineers not PMs.
Something else I've realized in line with breaking the boundaries of roles is that usually, the most valuable aspects of a person's role are the responsibilities that are not explicitly defined. Hard to explain, but often people provide value in ways that are hard to describe and quantify.
Don't hate the player, hate the game… PMs are just doing exactly what leadership has asked them to do.
The real problem is unrealistic roadmaps filled with top-down strategic initiatives which are often made up by leadership with very little rigor—all in the pursuit of growth at any cost. The bad PM is an emergent property of that system.
The real problem is unrealistic roadmaps filled with top-down strategic initiatives which are often made up by leadership with very little rigor—all in the pursuit of growth at any cost. The bad PM is an emergent property of that system.
A good PM pushes back on those initiative and fixes them
I’ve seen good PMs get told “just do this.” Managers don’t run the business.
Alot of PMs want the job for the wrong reasons or are generally misguided. They want control, believe they are a visionary, use it for stepping stone to be a 'founder' one day, etc. Also, there's a trend of meh junior software developers clamoring to become PMs. I think they found out the recruiting recipe from FAANG where if you have a CS degree and a few years of engineering experience, you'll be recruited into a PM role where you won't have to code or look at a terminal again.
- Why is a company equated with one product?
- Without a "product manager", or, since I prefer scrum terminology, "product owner", who determines the direction of the product development? Who decides what the most important thing to work next is, and where to focus company resources? Who is responsible for making sure that the product is valuable, and that whatever developers work at any given moment serves to maximize its value?
- Without a single "product manager"/"product owner", who decides which of the multiple competing requests to the team takes the first priority?
- With the attitude of "hire everyday great people; each one needs to be great at something; you then put them together in a team", how do make sure that individuals you put on a team work toward a single goal, as a team?I was ready to hate this article based on the title - I presumed it was a typical "PMs are dumb, all your company needs is smart engineers who rule the world" piece. But it wasn't that, and the author nails the problem pretty much perfectly.
But: The author hand-waves the solution into oblivion:
"There’s an alternative model that works. You hire everyday great people. Each one needs to be great at something, obsessed by their craft, and driven by quality. You then put them together in a team, without individual responsibilities, ensuring that there’s minimal overlap in areas of greatness. And you pay them to have fun doing what they love doing, in exchange for putting their time and skills at the service of your company."
I mean, come on. That sounds lovely but can anyone point to a successful company larger than 100 people where that actually works in practice? (HOW could it work in practice?)
But: The author hand-waves the solution into oblivion:
"There’s an alternative model that works. You hire everyday great people. Each one needs to be great at something, obsessed by their craft, and driven by quality. You then put them together in a team, without individual responsibilities, ensuring that there’s minimal overlap in areas of greatness. And you pay them to have fun doing what they love doing, in exchange for putting their time and skills at the service of your company."
I mean, come on. That sounds lovely but can anyone point to a successful company larger than 100 people where that actually works in practice? (HOW could it work in practice?)
The "solution" doesn't even universally work in companies < 10 people.
We do it but we’re 15 people so it doesnt count.
Valve seems to do (or at least, have done) something very similar. Their employee handbook[0] used to be a staple on HN but I haven’t seen it flying around much lately. I wonder if it’s working out of them.
[0] https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployee...
Valve seems to do (or at least, have done) something very similar. Their employee handbook[0] used to be a staple on HN but I haven’t seen it flying around much lately. I wonder if it’s working out of them.
[0] https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployee...
Valve doesn’t ship
Woa! I mean I stopped gaming when Half-Life was new but that’s quite an indictment for their model huh.
Pinning this on product is IMO a mistake. Most companies don't understand the discipline of performance management; they don't care to learn beyond asking people "hey how did you do OKRs?"; and they substitute organizational design for performance management. This can show up in many ways, including substantially delegating the entire fate of the business to product management.
Also, I've found it a lot easier to reason about organizational issues if you don't fixate so much on "great people." More and more people enter the workforce with the idea of competence as a "ladder" being firmly ingrained in their heads. It doesn't work that way; people succeed as a function of who they are and the environment they're in. Your "smart person" is often totally useless somewhere else (see, for example: the huge numbers of FAANG-ish employees that struggle to do anything in smaller companies, and vice-versa.)
I found this entire article to read like it comes from the heyday of "only associate with people as _great_ as you want to be", which I think (a) was terribly reasoned and (b) hasn't really worked out that great, especially for the people who followed this advice.
Also, I've found it a lot easier to reason about organizational issues if you don't fixate so much on "great people." More and more people enter the workforce with the idea of competence as a "ladder" being firmly ingrained in their heads. It doesn't work that way; people succeed as a function of who they are and the environment they're in. Your "smart person" is often totally useless somewhere else (see, for example: the huge numbers of FAANG-ish employees that struggle to do anything in smaller companies, and vice-versa.)
I found this entire article to read like it comes from the heyday of "only associate with people as _great_ as you want to be", which I think (a) was terribly reasoned and (b) hasn't really worked out that great, especially for the people who followed this advice.
Yeesh, I am sorry this person has had such a bleak experience. By the end I took away that their core issues were with people that had: an excess of process, a lack of passion for craft, and a generally narrow outlook.
These are not the attributes I would associate with success or appreciation in any role.
These are not the attributes I would associate with success or appreciation in any role.
I've been thinking about this as well, but from a different angle: the product manager role just feels too much weight for a single human being to shoulder. When my last company went through the exercise of writing down roles & and responsibilities, the PM's responsibilities ended up being something akin to "general contractor", or someone that does everything that's left over after responsibilities are split up across different team members. It's great when you find that outlier person who can handle this responsibility, but when you can't, the older model of having a team consisting of a business analyst, architect, engineering manager or project manager seems to work (although not in a very satisfying way).
I am not sure this person has ever worked in a place without PMs (or people who do "the PM stuff") because nothing they are talking about is "about" PMs. PMs are, essentially, the people who sit at the center of: customer desires, engineering resources, and internal priorities. They can also do more of course - they could manage the project, manage the team, etc. But they do not have to! You can have this authors' weird great-man-esq "high performers" who will happily rely on their PM to go to all the client meetings they are too busy being great to attend.
Currently I work for a big tech company that mostly doesn't employ PM roles, so I can give a first hand take on this.
My feelings so far are mixed. I've worked in PM-heavy organizations before and I agree that those suck. But at the end of the day there is some work that a PM would do that still needs to be done. In my org that responsibility officially falls into Software Managers and Senior+ Developers.
For example, if you are leading an initiative for your team as a Senior Engineer, you are in charge of doing all the activities that a PM would otherwise do. For other activities, the Manager or Senior Manager of the team is in charge.
Suffice to say that as a developer this sucks. Not only you need to deliver your own work as an IC, but you need to coordinate other people and ensure that things get done. Not only this is extra work, but let's be honest, many developers don't have the skills to be effective PMs. It also makes inter-team collaboration difficult, since now you have to coordinate people that don't share a reporting structure with you.
Often this approach results in lack of ownership, lack of accountability, duplicated efforts or things falling between the cracks, and general disorganization. That being said, it tends to work well for small intra team initiatives involving a few people, since it removes the overhead of a PM and places control in the hands of builders. But for larger initiative, I'm not quite convinced it works.
My feelings so far are mixed. I've worked in PM-heavy organizations before and I agree that those suck. But at the end of the day there is some work that a PM would do that still needs to be done. In my org that responsibility officially falls into Software Managers and Senior+ Developers.
For example, if you are leading an initiative for your team as a Senior Engineer, you are in charge of doing all the activities that a PM would otherwise do. For other activities, the Manager or Senior Manager of the team is in charge.
Suffice to say that as a developer this sucks. Not only you need to deliver your own work as an IC, but you need to coordinate other people and ensure that things get done. Not only this is extra work, but let's be honest, many developers don't have the skills to be effective PMs. It also makes inter-team collaboration difficult, since now you have to coordinate people that don't share a reporting structure with you.
Often this approach results in lack of ownership, lack of accountability, duplicated efforts or things falling between the cracks, and general disorganization. That being said, it tends to work well for small intra team initiatives involving a few people, since it removes the overhead of a PM and places control in the hands of builders. But for larger initiative, I'm not quite convinced it works.
To give another perspective:
> Not only you need to deliver your own work as an IC, but you need to coordinate other people and ensure that things get done.
That for me is the definition of a senior/lead engineer
> Not only this is extra work, but let's be honest, many developers don't have the skills to be effective PMs.
To be fair, Many PMs don’t have the skills to be effective PMs
> It also makes inter-team collaboration difficult, since now you have to coordinate people that don't share a reporting structure with you.
As is the case for a PM
I think our core disagreement comes around “is it worth spinning off this part of the job to a dedicated role”. I happen to believe that’s nearly never true for engineers
> Not only you need to deliver your own work as an IC, but you need to coordinate other people and ensure that things get done.
That for me is the definition of a senior/lead engineer
> Not only this is extra work, but let's be honest, many developers don't have the skills to be effective PMs.
To be fair, Many PMs don’t have the skills to be effective PMs
> It also makes inter-team collaboration difficult, since now you have to coordinate people that don't share a reporting structure with you.
As is the case for a PM
I think our core disagreement comes around “is it worth spinning off this part of the job to a dedicated role”. I happen to believe that’s nearly never true for engineers
What a waste of time reading that was, just wow.
I kind of agree with the initial precept. I have seen useless PMs more than I can count, and organizations turned into government bureaucracies on the altar of cargo cultish "best practice" processes. Retro-engineering okrs from a pre-existing list of features, looking at data only for vanity purposes (how good are we).
I think it goes one step too far and throws the baby, the bath tub, and the whole house with the bathwater.
> Do you know what else they had in common? None of them were motivated by OKRs, KPIs, data, or other people’s opinion.
This is not true for Bezos for example. He was famously driving the company through data, metrics and process, and there's countless examples of "Jeff meetings" where he changed his mind after reading the data presented by others.
All those examples are tools, that you can, and often shouldn't use. It makes no sense to have a heavy process when you're small, in direct touch with the customer, and are fully driven by an idea. Similarly, it makes no sense keeping on wet-fingering it and single-person driving once you have a set of established customers and want to increase your penetration.
Same is true for all aspects of a company, from engineering to sales to marketing. As you grow you get more people working, and you need a minimum of coordination and standardization to avoid going in antagonistic positions all over. And same goes with seems between these functions. Let me tell you that I prefer having a good PM to handle these needs and that coordination rather than having to deal with synchronizing their needs as an engineer.
I went in there hoping I would have a good resource to share about the topic, but it's too sour and mono-directed into some weirdly "aw common just be smart about it" to be credible. Ironically, the conclusion of the article (no structure, just smart people everywhere) contradicts one of its central argument (everything doesn't apply everywhere).
I think it goes one step too far and throws the baby, the bath tub, and the whole house with the bathwater.
> Do you know what else they had in common? None of them were motivated by OKRs, KPIs, data, or other people’s opinion.
This is not true for Bezos for example. He was famously driving the company through data, metrics and process, and there's countless examples of "Jeff meetings" where he changed his mind after reading the data presented by others.
All those examples are tools, that you can, and often shouldn't use. It makes no sense to have a heavy process when you're small, in direct touch with the customer, and are fully driven by an idea. Similarly, it makes no sense keeping on wet-fingering it and single-person driving once you have a set of established customers and want to increase your penetration.
Same is true for all aspects of a company, from engineering to sales to marketing. As you grow you get more people working, and you need a minimum of coordination and standardization to avoid going in antagonistic positions all over. And same goes with seems between these functions. Let me tell you that I prefer having a good PM to handle these needs and that coordination rather than having to deal with synchronizing their needs as an engineer.
I went in there hoping I would have a good resource to share about the topic, but it's too sour and mono-directed into some weirdly "aw common just be smart about it" to be credible. Ironically, the conclusion of the article (no structure, just smart people everywhere) contradicts one of its central argument (everything doesn't apply everywhere).
This article mischaracterizes the roles of PM's and engineers in most companies.
It sets up a strawman of "delegating control to a single person", and assuming that person is either an engineer or a PM. Everywhere I've worked, the product teams/leaders and engineering teams/leaders were peers. Engineering didn't report to product, and product didn't report to engineering. Rather, both reported directly to the CEO, often as separate CTO and CPO heads, or they both reported to an executive VP or director or similar.
Because the reality is, you need both. Engineers are great at building but they're not spending time with customers or UX research to know what the market and users need. The main job of a PM is to understand what the market and users need by spending a lot of time with customers and researchers, and to marry that with the business priorities coming from executives. And then a PM and eng lead negotiate back and forth to figure out what can be built that meets everyone's needs.
The idea that a product manager role is a mistake makes as much sense as saying an engineering lead role is a mistake, or a sales lead is a mistake, or a marketing manager is a mistake. A successful business needs all parts.
(Occasionally you're building a product that's by developers for developers, where the engineers do have an accurate understanding of users/market, and a PM isn't necessary. But that's exceedingly rare.)
It sets up a strawman of "delegating control to a single person", and assuming that person is either an engineer or a PM. Everywhere I've worked, the product teams/leaders and engineering teams/leaders were peers. Engineering didn't report to product, and product didn't report to engineering. Rather, both reported directly to the CEO, often as separate CTO and CPO heads, or they both reported to an executive VP or director or similar.
Because the reality is, you need both. Engineers are great at building but they're not spending time with customers or UX research to know what the market and users need. The main job of a PM is to understand what the market and users need by spending a lot of time with customers and researchers, and to marry that with the business priorities coming from executives. And then a PM and eng lead negotiate back and forth to figure out what can be built that meets everyone's needs.
The idea that a product manager role is a mistake makes as much sense as saying an engineering lead role is a mistake, or a sales lead is a mistake, or a marketing manager is a mistake. A successful business needs all parts.
(Occasionally you're building a product that's by developers for developers, where the engineers do have an accurate understanding of users/market, and a PM isn't necessary. But that's exceedingly rare.)
Here's my solution: get (or be) a strong tech lead that can write tickets, negotiate features, and steer technical direction. They can optionally run the team as well, or that can have a separate person, who is still technical, in the team who keeps the trains running on time with meetings etc. The product person is slightly more distant; not in every meeting, and the tech lead makes sure work is synced with the product requirements, which are documented not in tickets, but at a higher level in written+diagram form.
That way you don't have "product" people who are really just status reporting for the team, or "product" people who are really just writing bad tickets that need rewriting. You have actual product people who focus on where the product should be going.
You also don't have a "delivery manager" role. The team needs to be steered into doing this by a decent lead who can do the 3% admin required to keep on top of this sort of thing.
That way you don't have "product" people who are really just status reporting for the team, or "product" people who are really just writing bad tickets that need rewriting. You have actual product people who focus on where the product should be going.
You also don't have a "delivery manager" role. The team needs to be steered into doing this by a decent lead who can do the 3% admin required to keep on top of this sort of thing.
[deleted]
What you are describing sounds like a Technical Product Manager, not a tech lead. The minute you have them “run a team”, you are combining both roles into one.
Nothing I've mentioned is anything to do with product management. The optional "run a team" bit is "team lead". Not product.
Writing a tickets is usually not owned by engineering. Some engineering managers may do this work, but it’s usually owned by Product while Engineering helps refine and turn tickets into actionable work. Engineering also doesn't negotiate features. Engineerings job is to help product determine LOE and help Product prioritize requirements for a future release. Again, strong engineering leads can do this work, but I believe Product Owner should hold these responsibilities.
> I believe Product Owner should hold these responsibilities
That's inarguable, as you haven't said why, but I'm saying the structure I described works well. My rationale is: product people don't generally write great tickets, and they also aren't in a position to negotiate features based on technical constraints.
That's inarguable, as you haven't said why, but I'm saying the structure I described works well. My rationale is: product people don't generally write great tickets, and they also aren't in a position to negotiate features based on technical constraints.
What a bad take.
I do agree with the red-flag symptoms like KPI and other “measurements”, and I’ll go as far as to say it’s extremely difficult to find a great PM and the field is riddled with mediocre ones.
In my several decades of software engineering work, good product managers were almost non-existent.
Today I’m working with one who has a strong competitive streak, is quite smart, and deeply understands our users and competition.
I’ve been making sure to give her stellar feedback during reviews and peer feedback, as I know how rare this combination is.
Edit: Reading through the responses, perhaps I should reconsider. The expectation of the role and responsibilities are misunderstood and misaligned to what businesses and engineering teams actually need.
That is to say, my team PM’s a success despite the role and not because of it.
I do agree with the red-flag symptoms like KPI and other “measurements”, and I’ll go as far as to say it’s extremely difficult to find a great PM and the field is riddled with mediocre ones.
In my several decades of software engineering work, good product managers were almost non-existent.
Today I’m working with one who has a strong competitive streak, is quite smart, and deeply understands our users and competition.
I’ve been making sure to give her stellar feedback during reviews and peer feedback, as I know how rare this combination is.
Edit: Reading through the responses, perhaps I should reconsider. The expectation of the role and responsibilities are misunderstood and misaligned to what businesses and engineering teams actually need.
That is to say, my team PM’s a success despite the role and not because of it.
Confusing article. “We should get rid of the PM role” but also “We still need people dedicated to do PM things… but don’t call them PMs, they’re just everyday great people.” I feel like the author had a bad experience working with a PM (the MBA comment is telling) and now wants to throw the baby out with the bath water. Business scale creates + requires role specialization. Sure, there are shitty PMs, and it’s a hard job, but I’d be super disappointed to lose my team’s PM.
Definitely sounds like a bad PM experience, especially with the repeated insistence about handing control of the company over to the PM.
Maybe I just have good experiences with PMs? At my company they're there to figure out what customers want and what the product should deliver, and then with our EMs to balance that with what's technically feasible and what we have capacity to implement. If an EM says "there's no way we can do that on this timeline" the PM works out some alternative plan for the product.
Maybe I just have good experiences with PMs? At my company they're there to figure out what customers want and what the product should deliver, and then with our EMs to balance that with what's technically feasible and what we have capacity to implement. If an EM says "there's no way we can do that on this timeline" the PM works out some alternative plan for the product.
Yeah the "handing control of the company over" thing struck me as odd as well. I haven't ever seen that particular problem.
In the good cases I've seen, it's just as you describe, with EMs and PMs working together with high trust to get to a decent level of consensus between them, and then parlaying that consensus into leadership buy in for their roadmap.
In the bad cases, there is some breakdown in trust between the EM, PM, or leadership. Or, worse, between the EM and their team.
But I haven't run into this thing where the PM reigns supreme, above the leadership team.
In the good cases I've seen, it's just as you describe, with EMs and PMs working together with high trust to get to a decent level of consensus between them, and then parlaying that consensus into leadership buy in for their roadmap.
In the bad cases, there is some breakdown in trust between the EM, PM, or leadership. Or, worse, between the EM and their team.
But I haven't run into this thing where the PM reigns supreme, above the leadership team.
Handing the company over to PMs is a very common problem I’ve seen at smaller startups.
It’s generally not that they are above the leadership team, but that that the leadership team have abdicated responsibility for product development to the head of product.
It’s generally not that they are above the leadership team, but that that the leadership team have abdicated responsibility for product development to the head of product.
Interesting. I'll take your word for it. I'm glad I haven't seen that.
My company is product led. That means PMs have huge influence on what gets built. The how is still left to the engineers.
I think it works pretty well. We ship a lot of great stuff.
I think it works pretty well. We ship a lot of great stuff.
I think what I described is system where PMs have huge influence on what gets built. But also a system where engineering and strategic leadership also do. Personally that seems like the the balance to me. I think all three things - tactical product decisions, execution decisions, and strategic decisions - are important and separate.
An extremely common organisational leadership failure mode is “[role/thing] is useless, get rid of it… Ooops, we actually needed that. Bring it back, but call it something else so that we don’t have to admit our mistake.”
The author has, apparently, decided to skip the intermediate step and just rename things for no reason.
The author has, apparently, decided to skip the intermediate step and just rename things for no reason.
Also, bring it back but don’t call it that and maybe we can get by paying someone less to do the same work.
I've been lucky to work with a series of really good product managers, with one exception who thankfully didn't last long enough to do too much damage (though he did result in me having to attend the single most awkward meeting I've ever had to attend, where right from the top, and throughout the entire hour, he was demonstrating to his skip level manager that he really didn't understand the product at all, and the skip level did).
They help us out a lot by understanding what the customers want, what we can provide, what time lines are sane, handling interacting with legal and business interests galore, and I help them out when they need to check in on technical sides of things. Teams rarely lack for ideas of things they can build, ways they can improve the product or operational experience. A product manager tries to make sure you build the right thing.
They help us out a lot by understanding what the customers want, what we can provide, what time lines are sane, handling interacting with legal and business interests galore, and I help them out when they need to check in on technical sides of things. Teams rarely lack for ideas of things they can build, ways they can improve the product or operational experience. A product manager tries to make sure you build the right thing.
Yeah, and then they go on to say that all of the great sages weren't PM's, just great people.
I disagree. All of those greats that were mentioned succeeded because they kept the customer and the product tantamount to all else. So really they were just fantastic PM's.
I disagree. All of those greats that were mentioned succeeded because they kept the customer and the product tantamount to all else. So really they were just fantastic PM's.
I truly wish (and I know some do) that MBA programs had an industry experience prerequisite.
I have 20 years IT experience. I'm a PM. I'm looking to do an MBA for knowledge, learning about more formal business understanding, etc., and to help as I advance.
The PMs I know who are similar don't get an MBA and immediately start playing fuckfuck games (to borrow from military parlance). It's those who went high school > college > MBA > managerial role, without a day's experience in the field except maybe a brief internship half way through their undergrad.
I have 20 years IT experience. I'm a PM. I'm looking to do an MBA for knowledge, learning about more formal business understanding, etc., and to help as I advance.
The PMs I know who are similar don't get an MBA and immediately start playing fuckfuck games (to borrow from military parlance). It's those who went high school > college > MBA > managerial role, without a day's experience in the field except maybe a brief internship half way through their undergrad.
It also says that you just build teams where everyone is amazing (good luck pulling off that piece of recruiting magic) and then says “… give them good problems to solve…”
Who exactly does the author think should decide what problems the team should prioritize? That is the primary responsibility of the PM role. Seems like the author has indeed just had a bad experience with a PM who failed at that.
I never understood black and white thinking such as OP.
“Your personal experiences make up maybe 0.00000001% of what’s happened in the world, but maybe 80% of how you think the world works.” - Morgan Housel
Its the same with dating. If you date toxic people, you start generalising that all men are abusive.
Same with PMs. If you are working within a company that accepts subpar talent, you'll start seeing things based on your benchmark of quality. Until you actually work with a great PM that makes your life easier.
There are good engineers and bad engineers.
This polarisation is IMO an incredible bias.
“Your personal experiences make up maybe 0.00000001% of what’s happened in the world, but maybe 80% of how you think the world works.” - Morgan Housel
Its the same with dating. If you date toxic people, you start generalising that all men are abusive.
Same with PMs. If you are working within a company that accepts subpar talent, you'll start seeing things based on your benchmark of quality. Until you actually work with a great PM that makes your life easier.
There are good engineers and bad engineers.
This polarisation is IMO an incredible bias.
Good things to watch out for, but also watch out for project or program running the show. For example, project sees it as a piece of work to churn, and program is trying to execute a multitude of projects.
Someone has got to care about the user and the business.
It can be much worse with a project manager who doesnt care about the user, doesnt care about the business and is just trying to complete tasks per sprint without any focus. It is even worse when the project or program manager has no technical background and doesnt understand what it takes to build something.
In each role, product, project, program, and all the other lead roles (technical), it takes people who really care.
Someone has got to care about the user and the business.
It can be much worse with a project manager who doesnt care about the user, doesnt care about the business and is just trying to complete tasks per sprint without any focus. It is even worse when the project or program manager has no technical background and doesnt understand what it takes to build something.
In each role, product, project, program, and all the other lead roles (technical), it takes people who really care.
I wish I could find a better framing in my head than the negative thoughts that reoccur so regularly across so many years. It's not always: but maybe half the time, there's a sadness & sense of misfortune that boils down to companies that don't trust or believe in engineers. Companies who think the people doing the work are not to be trusted or given power. And org charts that try to create corresponding hierarchies of power with workers at the bottom and lots of buffer inbetween.
The engineers are most connected to the tremendous energy. Have the most idea of potential & costs & a savvy for appreciating what is most directly possible, sharp intuitive angles towards mechanistic sympathy/finess. But are made to mete with all manners of checks, have their will impeeded. Bargained down ongoingly from doing good.
There's definitely a lot of being a junior engineer where you want or need direction. The more formal org's high-structure is good here, is predictable. But on the whole, I think companies have become far lesser for being so managed. There was a great thread recently where the discussion turned to middle management, and it was great if sad hearing such stress & strain mirrored about. I will fucking haymaker you if you mention agile again, https://news.ycombinator.com/item?id=37894676
The engineers are most connected to the tremendous energy. Have the most idea of potential & costs & a savvy for appreciating what is most directly possible, sharp intuitive angles towards mechanistic sympathy/finess. But are made to mete with all manners of checks, have their will impeeded. Bargained down ongoingly from doing good.
There's definitely a lot of being a junior engineer where you want or need direction. The more formal org's high-structure is good here, is predictable. But on the whole, I think companies have become far lesser for being so managed. There was a great thread recently where the discussion turned to middle management, and it was great if sad hearing such stress & strain mirrored about. I will fucking haymaker you if you mention agile again, https://news.ycombinator.com/item?id=37894676
Ridiculous. That list of tremendous people are some founders that found success. There are plenty of tremendous founders we don't hear about that didn't do as well. There are plenty of tremendous people in regular jobs that can't act like iconoclastic dickheads because they'd be rightfully fired. More importantly hugely successful organizations have found a way to reproduce their own success despite specific people not because of them.
You want to build lasting success on good process, good organization and responsible management. People come and go. Organizations stick around.
You want to build lasting success on good process, good organization and responsible management. People come and go. Organizations stick around.
The realization I had the other day is that we worry about bus numbers for technical details and then we have a “single wring-able neck” which right there should have told us what a snake in the grass Schwaber and his ideas are. Not even internally consistent. And capital T Toxic.
Used to be we had two or three people responsible for owning the product design. Coherence of design, despite the name, doesn’t come from a single mind. It comes from a mind that is challenged at every turn to be better. I had a friend in college who had a love-hate relationship with Stephen King. He was a fan, but lamented the fact that King refuses to have an editor. “Great beginnings, terrible endings,” was how my friend described his books. And “he needs an editor, even if he doesn’t want one.” And repeated it at the end of each book he read. Which is how we end up with King saying the Movie Ending for The Mist was better than his ending. Nobody to push back. Nobody invested with the power to call him on his bullshit.
We used to have companies with a leader of engineering that insisted on what success would look like, a leader of quality that insisted on what corners we could not cut, and a leader of development that insisted on how we were going to get there. Now we have a product owner trying to be all three and doing a shitty job at two of them. If you’re lucky.
In traditional Kanban, everyone has a veto, a strong cultural drive not to use that veto unless it’s necessary, but as soon as it’s necessary. In Scrum the illusion of adaptability is an opiate for the masses. Agile theater for a process that has become almost entirely and practically Lean. If you think you’re doing Agile when you’re doing Lean, you’re gonna have a bad time.
Used to be we had two or three people responsible for owning the product design. Coherence of design, despite the name, doesn’t come from a single mind. It comes from a mind that is challenged at every turn to be better. I had a friend in college who had a love-hate relationship with Stephen King. He was a fan, but lamented the fact that King refuses to have an editor. “Great beginnings, terrible endings,” was how my friend described his books. And “he needs an editor, even if he doesn’t want one.” And repeated it at the end of each book he read. Which is how we end up with King saying the Movie Ending for The Mist was better than his ending. Nobody to push back. Nobody invested with the power to call him on his bullshit.
We used to have companies with a leader of engineering that insisted on what success would look like, a leader of quality that insisted on what corners we could not cut, and a leader of development that insisted on how we were going to get there. Now we have a product owner trying to be all three and doing a shitty job at two of them. If you’re lucky.
In traditional Kanban, everyone has a veto, a strong cultural drive not to use that veto unless it’s necessary, but as soon as it’s necessary. In Scrum the illusion of adaptability is an opiate for the masses. Agile theater for a process that has become almost entirely and practically Lean. If you think you’re doing Agile when you’re doing Lean, you’re gonna have a bad time.
This article is slick pabulum. Well written junk.
Every company relies on the quality of its people. Every company puts people into positions of responsibility. Any company would suffer if people abuse or cannot handle their responsibility. So what? Is this some kind of insight? No.
Incompetence is a problem regardless of role, and it’s more of a problem with more powerful roles. The author gives no reason why “product manager” should be his special target.
The author seems to think the solution is… teamwork? Really?
That’s it. Problem solved? No.
This article is part of a genre that extolls the amazing power of the group without discussing or acknowledging all the excellent reasons why hierarchies are so immensely popular in industry compared to self-organizing hives.
Most articles on teamwork assume the happy path. Speaking as a person with skills, experience, and strong opinions— I know what it means to collaborate with difficult people. I am one. Any company that consistently thrives with an egalitarian culture must either be tiny or it must develop a sophisticated and sober culture of conflict management. Ironically, only with strong leadership from the top can that be done.
Every company relies on the quality of its people. Every company puts people into positions of responsibility. Any company would suffer if people abuse or cannot handle their responsibility. So what? Is this some kind of insight? No.
Incompetence is a problem regardless of role, and it’s more of a problem with more powerful roles. The author gives no reason why “product manager” should be his special target.
The author seems to think the solution is… teamwork? Really?
That’s it. Problem solved? No.
This article is part of a genre that extolls the amazing power of the group without discussing or acknowledging all the excellent reasons why hierarchies are so immensely popular in industry compared to self-organizing hives.
Most articles on teamwork assume the happy path. Speaking as a person with skills, experience, and strong opinions— I know what it means to collaborate with difficult people. I am one. Any company that consistently thrives with an egalitarian culture must either be tiny or it must develop a sophisticated and sober culture of conflict management. Ironically, only with strong leadership from the top can that be done.
Steve Jobs was a product manager, the best in class.
The thing about PMs. They fulfill a very specific need, and that need is hard to quantify, but I can tell you that without a good PM everything falls apart.
Here's a list of what they tend to do:
- gather information from users on what is/isn't working for them
- gather information from executives about what needs to be done to keep the company working
- gather information from industry leaders who may or may not be part of the company about where the industry is going
- work with design
- take all 4 previous points and distill them into what actually needs to be built for a needed feature
- work with engineering to figure out what is practical, vs not, for building, and how long approximately it will take
- work with engineers / higher ups to remove features that take time but don't add as much value.
- work with engineers to ensure estimation and team velocity is more or less predictable
I've probably already described a 1 and 1/2 jobs. Now if you take product away, each of the above gets distributed among the engineering team, and not everyone in that team is good at it. And even if they get to a good homeostasis, one person leaves and now there's a non-obvious gap that we're not interviewing for.
Here's a list of what they tend to do:
- gather information from users on what is/isn't working for them
- gather information from executives about what needs to be done to keep the company working
- gather information from industry leaders who may or may not be part of the company about where the industry is going
- work with design
- take all 4 previous points and distill them into what actually needs to be built for a needed feature
- work with engineering to figure out what is practical, vs not, for building, and how long approximately it will take
- work with engineers / higher ups to remove features that take time but don't add as much value.
- work with engineers to ensure estimation and team velocity is more or less predictable
I've probably already described a 1 and 1/2 jobs. Now if you take product away, each of the above gets distributed among the engineering team, and not everyone in that team is good at it. And even if they get to a good homeostasis, one person leaves and now there's a non-obvious gap that we're not interviewing for.
Advocating funding for a project budget and trying to involve stakeholders as well.
omg yes!!!! this too.
In recent experience the PMs I have worked with have primarily concerned themselves with the desires of executives. Literally all the other responsibilities you mentioned were handled by others.
This… and trying to squeeze dates out of everyone to fill boxes in a document.
Yes, and this is exactly when you have ineffective PMs, and senior leadership isn't paying attention.
With a good product and design team, I have been part of engineering teams that have 5 engineers than can do the work of 20, without working overtime, consistently deliver, and rarely, have to implement anything twice.
The difference between effective product and not is absolutely night and day. The best analogy is driving a modern car, vs driving a modern car without vehicle stability, anti-skid, power steering, automatic transmission, or AC. Sure you absolutely can drive it, but after a while you will need way more breaks than those who have all the nice features, and won't roll over in bad situations.
With a good product and design team, I have been part of engineering teams that have 5 engineers than can do the work of 20, without working overtime, consistently deliver, and rarely, have to implement anything twice.
The difference between effective product and not is absolutely night and day. The best analogy is driving a modern car, vs driving a modern car without vehicle stability, anti-skid, power steering, automatic transmission, or AC. Sure you absolutely can drive it, but after a while you will need way more breaks than those who have all the nice features, and won't roll over in bad situations.
Yes. But this is because we have organizations where people survive by placating the higher-ups instead of producing value to the product and their team. Hence, these people survive.
It's human nature to find the best way to survive so we can't really blame these PMs for doing what they need to keep their job. Suck up to the people that will ultimately give them their paycheck.
The issue isn't the PM or shitty employees that aren't producing actual value, the issue is with the ego of the higher ups that rather keep people that agree with them on all things than have people who will constantly challenge them.
I have seen many CxOs (that aren't founders) who are very good at befriending the founders and thus they are more prone to survive. They are not necessarily doing anything useful to move the needle though, so this gives people the impression that the best thing you can do to survive is just be liked by the higher ups. Telling founders that they are wrong on a day to day basis because you work so closely with users and the engineering team, is not a good way to keep your job. If you are very smart maybe you can navigate this in a way that works, for awhile.
If my point is muddled, I'm saying that if you have a shitty PM it's because of the organization that employs people and keeps people based on the wrong criteria. Good leaders aren't threatened by getting challenged or feel the need to constantly get their egos validated.
Or maybe I'm wrong there too and it's just human nature to want to keep people that you always get along with.
It's human nature to find the best way to survive so we can't really blame these PMs for doing what they need to keep their job. Suck up to the people that will ultimately give them their paycheck.
The issue isn't the PM or shitty employees that aren't producing actual value, the issue is with the ego of the higher ups that rather keep people that agree with them on all things than have people who will constantly challenge them.
I have seen many CxOs (that aren't founders) who are very good at befriending the founders and thus they are more prone to survive. They are not necessarily doing anything useful to move the needle though, so this gives people the impression that the best thing you can do to survive is just be liked by the higher ups. Telling founders that they are wrong on a day to day basis because you work so closely with users and the engineering team, is not a good way to keep your job. If you are very smart maybe you can navigate this in a way that works, for awhile.
If my point is muddled, I'm saying that if you have a shitty PM it's because of the organization that employs people and keeps people based on the wrong criteria. Good leaders aren't threatened by getting challenged or feel the need to constantly get their egos validated.
Or maybe I'm wrong there too and it's just human nature to want to keep people that you always get along with.
I couldn’t agree more. I absolutely do not want to be without a functional product org.
I suspect a lot of teams have gotten burned from dysfunctional product orgs that seem disconnected (or disinterested) on the more customer/industry/organization side and instead burn through tons of meetings iterating on mock-ups, micromanaging designers (causing good ones to quit) and tying up engineers in product meetings they do not need to be in.
I suspect a lot of teams have gotten burned from dysfunctional product orgs that seem disconnected (or disinterested) on the more customer/industry/organization side and instead burn through tons of meetings iterating on mock-ups, micromanaging designers (causing good ones to quit) and tying up engineers in product meetings they do not need to be in.
I take issue with excellent product management being hard to quantify. There is a creative aspect, but one indicator that's easy to examine is whether they understand strategic competitive analysis, not just point-by-point features bingo. Secondly, have they got the stature in the org to communicate about a project to senior management. If they have got both those attributes, you are in good shape.
> gather information from users on what is/isn't working for them
trivial and part of analytics and bug reporting that anyone can have a look at and it's the same job that the QA team does too which you are in contact with as a programmer anyway
> gather information from executives about what needs to be done to keep the company working
the boss tells you what to implement whether there is a PM in the middle or not
> gather information from industry leaders who may or may not be part of the company about where the industry is going
reading the news? I think everyone does it enough, it's not a hard job
> work with design
programmers are perfectly able to talk to designers, the issue is solely around who gets to make the decision. And I happen to believe that programmers should always be leading which is probably controversial and its own blog post but shortly summarized the reality is that programmers are at the intersection of the actual implementation, the design and all the decisions. They are in the perfect spot to make the call which features to do and which not to do.
> take all 4 previous points and distill them into what actually needs to be built for a needed feature
that's literally the job of programmers, to figure out how to implement something
> work with engineering to figure out what is practical, vs not, for building, and how long approximately it will take
once again, engineering is at the core of this and can do it on their own
> work with engineers to ensure estimation and team velocity is more or less predictable
this usually means that they want steady output on assigned issues and bugs which makes the job of engineers into a soulless daily issue list grind.
> Now if you take product away, each of the above gets distributed among the engineering team
Precisely, it lands there because it should land there at its natural intersection. The issue is that the engineers aren't given enough rights and decision making authority to make the calls so it becomes an awkward dance where you constantly have to ask for permission to do things because if you ever do something that the leadership doesn't like, you do get bad feedback. As Steve Jobs famously said and I'm paraphrasing: Once the engineers who actually make the products stop being at the center and the salespeople and managers take over it all becomes bad. It really doesn't matter how good a manager is, he will never be better than the guy who actually built the thing.
The reality is that a good PM would be advocating for engineers to be able to work on whatever things they want to work on, which is what never happens of course because that wouldn't help them. You can just look around in this thread: The PMs here all wanted to drive product direction, that's why they got into the job. Guess what every engineer went into the job for: They want to drive product direction too and they actually build the product. Who became an electrical engineer or programmer or game developer only to be told by some PM what to build? The PM is often not even really supposed to be his boss and yet it ends up being that way for absurd reasons. For utterly absurd reasons the PMs are given the ability to make product decisions even though they dont build anything and they aren't leadership. I've had PMs that were engaged, cared about making a product that makes sense etc. And yet ultimately the job is mostly around telling the actual implementors what to do while pretending that they aren't the boss of them but really, that's how it is because they talk to the leadership because what else would they be doing, of course half their job is to make sure that leadership does whatever the PM wants and they are generously given an entire job title just to talk to leadership and customers (which every engineer has to do too of course but with less time)
trivial and part of analytics and bug reporting that anyone can have a look at and it's the same job that the QA team does too which you are in contact with as a programmer anyway
> gather information from executives about what needs to be done to keep the company working
the boss tells you what to implement whether there is a PM in the middle or not
> gather information from industry leaders who may or may not be part of the company about where the industry is going
reading the news? I think everyone does it enough, it's not a hard job
> work with design
programmers are perfectly able to talk to designers, the issue is solely around who gets to make the decision. And I happen to believe that programmers should always be leading which is probably controversial and its own blog post but shortly summarized the reality is that programmers are at the intersection of the actual implementation, the design and all the decisions. They are in the perfect spot to make the call which features to do and which not to do.
> take all 4 previous points and distill them into what actually needs to be built for a needed feature
that's literally the job of programmers, to figure out how to implement something
> work with engineering to figure out what is practical, vs not, for building, and how long approximately it will take
once again, engineering is at the core of this and can do it on their own
> work with engineers to ensure estimation and team velocity is more or less predictable
this usually means that they want steady output on assigned issues and bugs which makes the job of engineers into a soulless daily issue list grind.
> Now if you take product away, each of the above gets distributed among the engineering team
Precisely, it lands there because it should land there at its natural intersection. The issue is that the engineers aren't given enough rights and decision making authority to make the calls so it becomes an awkward dance where you constantly have to ask for permission to do things because if you ever do something that the leadership doesn't like, you do get bad feedback. As Steve Jobs famously said and I'm paraphrasing: Once the engineers who actually make the products stop being at the center and the salespeople and managers take over it all becomes bad. It really doesn't matter how good a manager is, he will never be better than the guy who actually built the thing.
The reality is that a good PM would be advocating for engineers to be able to work on whatever things they want to work on, which is what never happens of course because that wouldn't help them. You can just look around in this thread: The PMs here all wanted to drive product direction, that's why they got into the job. Guess what every engineer went into the job for: They want to drive product direction too and they actually build the product. Who became an electrical engineer or programmer or game developer only to be told by some PM what to build? The PM is often not even really supposed to be his boss and yet it ends up being that way for absurd reasons. For utterly absurd reasons the PMs are given the ability to make product decisions even though they dont build anything and they aren't leadership. I've had PMs that were engaged, cared about making a product that makes sense etc. And yet ultimately the job is mostly around telling the actual implementors what to do while pretending that they aren't the boss of them but really, that's how it is because they talk to the leadership because what else would they be doing, of course half their job is to make sure that leadership does whatever the PM wants and they are generously given an entire job title just to talk to leadership and customers (which every engineer has to do too of course but with less time)
rofl, look at everything you commented on. You're basically making my point. Also it sounds like you never worked with a programmer before, because "that's literally the job of programmers, to figure out how to implement something" is by far vastly underestimating how good programmers are when you give them fuzzy information. Maybe by year 7 or 8 they can get fuzzy info and work that into a well functioning piece. Before then they either will complain "why can't someone just tell me what to build and I'll build it" or they never push back on "do we need to build this? And as such?" and by god try to get them to estimate. Oh wait and try to get those estimates to be less than 300% off.
Just saying, you are over trivializing everything which in my mind leads me to think you haven't lead an engineering team or maybe oversaw one or two junior or mid level engineers.
A good PM should _not_ be advocating for the engineers to do whatever. If they are doing this I would be the first in line to recommend either re-adjusting their priorities and having a senior pm oversee them, or kick them out. A good PM is what creates the space for engineers to do their job, and a bad one will not wrangle the chaos into an executable situation.
Just saying, you are over trivializing everything which in my mind leads me to think you haven't lead an engineering team or maybe oversaw one or two junior or mid level engineers.
A good PM should _not_ be advocating for the engineers to do whatever. If they are doing this I would be the first in line to recommend either re-adjusting their priorities and having a senior pm oversee them, or kick them out. A good PM is what creates the space for engineers to do their job, and a bad one will not wrangle the chaos into an executable situation.
You are talking from a fixed, assembly line perspective of having to deliver fixed value at fixed intervals. This is just not how I think of myself - as a cog in a machine. If you have to think of people this way because this is the only way your job functions in a huge corporation then do it but the ideal world doesn't work that way and therefore I don't want to work that way. I'm never going to be happy in a job where a PM isn't enabling me to do whatever I think is right for the product. Because just like you I happen to think that my ideas are good, so it would be a waste to just sit in a job like a soulless cog and work off an issue list every week with zero thought or input. Expecting people to be like this is probably why you get people like this.
I mean we are all cogs in a machine. And I found that a smart effective team who works in unison can develop novel things. Combined with a visionary who sits above the team pointing the brainpower into interesting directions you get quite interesting results.
I think the power of teams is not in individual contribution, but when the team is significantly greater than the sum of its parts.
I think the power of teams is not in individual contribution, but when the team is significantly greater than the sum of its parts.
I’m a PM and this is spot on. The PM is not some sort of authoritarian decision maker that tells the team what to build (like this article seems to say), the PM should be a close ally of the team. He/she will work closely with their team to define the roadmap and prioritise work that will have the biggest impact for customers and the business.
When The PM is doing a great job, it should be so obvious for the engineers what problems they need to solve next and understand why they need to solve it.
When The PM is doing a great job, it should be so obvious for the engineers what problems they need to solve next and understand why they need to solve it.
I really struggle with this sentiment because I often agree with it, specifically at large companies.
At Google product managers became the worst aspect of the entire company. They spent their time arbitraging credit, cutting off communications between builders and executives, and generally appearing for a while, not taking ownership, then leaving after they fucked up the roadmap so badly they couldn’t fix it.
They became the worst kind of leech on the company.
But then in starting my own company, PMs who need to own, execute, and deliver on a triads goals has become invaluable. It shortens communication pathways and distributes responsibility.
So I dunno I’m at a loss.
At Google product managers became the worst aspect of the entire company. They spent their time arbitraging credit, cutting off communications between builders and executives, and generally appearing for a while, not taking ownership, then leaving after they fucked up the roadmap so badly they couldn’t fix it.
They became the worst kind of leech on the company.
But then in starting my own company, PMs who need to own, execute, and deliver on a triads goals has become invaluable. It shortens communication pathways and distributes responsibility.
So I dunno I’m at a loss.
Your company is too small to attract power seekers, and you can easily filter them out at hiring.
You’re right. It only attracts people who are excited for the work not arbitrage power.
Coming from a technical background, I am pursuing a career in product, and I sincerely believe that engineers generally dislike any activity linked to a product owner/manager. Interviewing clients, prioritizing, and navigating politics are soft skills that technical people usually don't want to develop. I didn't want to either until I received an offer that doubled my salary.
> Do you know, though, what all the great people mentioned above have in common? None of them was a product manager. Not a single one.
Baffling argument. Not everyone has to be a visionary. Hire Picasso as your corporate lawyer, see how that works out for you.
Baffling argument. Not everyone has to be a visionary. Hire Picasso as your corporate lawyer, see how that works out for you.
Shades of C. Northcote Parkinson here.
I think most people have an incomplete understanding of what a product manager should do. It's bigger than "project management" or "project management + defining a roadmap + talking to customers."
What you are building, why, how you price it, how you speak to the market about it, how you position yourself in your category, how you partner with others to provide a better solution (either services companies to provide a turn-key solution or other software companies), how should you should allocate your engineering resources to best increase revenue, etc. And these questions touch almost every department in the company, so they have to be great communicators.
Just a few areas I routinely see bad PM's skip:
- Sales / Partner Enablement (awesome, you built something, but it doesn't matter if the field does't understand it or can explain it and its value)
- Market research / segmentation (are you building the right stuff for what you are targeting?)
- Creating new products / SKUs for opportunities within your existing target market/segments (growth)
- Identifying new/adjacent categories to develop products for (growth)
- Balancing building for today's customers vs building to get new customers
- Pricing/packaging (I'm not talking about physical product packaging)
- Build / buy / partner analysis
The Pragmatic Management Framework is a nice framework really shows the breadth of what a PM should be doing:
https://www.pragmaticinstitute.com/product/framework/
What you are building, why, how you price it, how you speak to the market about it, how you position yourself in your category, how you partner with others to provide a better solution (either services companies to provide a turn-key solution or other software companies), how should you should allocate your engineering resources to best increase revenue, etc. And these questions touch almost every department in the company, so they have to be great communicators.
Just a few areas I routinely see bad PM's skip:
- Sales / Partner Enablement (awesome, you built something, but it doesn't matter if the field does't understand it or can explain it and its value)
- Market research / segmentation (are you building the right stuff for what you are targeting?)
- Creating new products / SKUs for opportunities within your existing target market/segments (growth)
- Identifying new/adjacent categories to develop products for (growth)
- Balancing building for today's customers vs building to get new customers
- Pricing/packaging (I'm not talking about physical product packaging)
- Build / buy / partner analysis
The Pragmatic Management Framework is a nice framework really shows the breadth of what a PM should be doing:
https://www.pragmaticinstitute.com/product/framework/
I would argue that everything you described above falls under the umbrella of business development and should be in the hands of a VP level exec and their staff.
Unfortunately very often I've seen this role handed out to a person who does not have either the qualifications or experience for this role, despite perhaps being adept at the clerical parts of the job (the meetings, the JIRA management, the Power Points, the Agile theatre).
My sense is that product managers are a layer of management which frequently causes disconnects and friction between the executive team, engineering, and ultimately customers. They typically have no power to influence business strategy and frequently no expertise on the complexities of engineering the product. (As always there are exceptions - but few and far between).
I'll even point to a perfect example playing out with Creative Assembly, the studio behind the Total War game franchise. Here's a nice dissection of the situation (complete with insider company leaks) by Bellular News:
https://www.youtube.com/watch?v=RDcgpaypkQI
The TLDR is that an excessive focus on a product management driven strategy is hurting the long term viability of a multi-million dollar franchise with a very commited but increasingly dissapointed fan base. Also some good points on the dangers of letting technical debt accumulate and how not to intereact with your customers. There's an MBA case study unfolding here I think.
Unfortunately very often I've seen this role handed out to a person who does not have either the qualifications or experience for this role, despite perhaps being adept at the clerical parts of the job (the meetings, the JIRA management, the Power Points, the Agile theatre).
My sense is that product managers are a layer of management which frequently causes disconnects and friction between the executive team, engineering, and ultimately customers. They typically have no power to influence business strategy and frequently no expertise on the complexities of engineering the product. (As always there are exceptions - but few and far between).
I'll even point to a perfect example playing out with Creative Assembly, the studio behind the Total War game franchise. Here's a nice dissection of the situation (complete with insider company leaks) by Bellular News:
https://www.youtube.com/watch?v=RDcgpaypkQI
The TLDR is that an excessive focus on a product management driven strategy is hurting the long term viability of a multi-million dollar franchise with a very commited but increasingly dissapointed fan base. Also some good points on the dangers of letting technical debt accumulate and how not to intereact with your customers. There's an MBA case study unfolding here I think.
You might not need a dedicated product manager at all companies, but someone needs to embrace and act as it. In some situations I have gladly taken that role, in other not.
I would say this more aggressively, product manager shouldn't be a specific role at any company. Someone needs to do that work, but making a product manager role, who can be unable to do any of the actual tasks to make the product function, is a bad idea. It's just encouraging people to play politics, and discouraging people from playing politics is one of the most important things for any org.
IMO, PM as a “job” is a mistake. As a role that some domain expert can take in a project I believe it works to let others focus, but it only adds value is the person is really good, a bad PM will add negative value by adding another hop in the communication.
In the same way "software engineer" can encompass a broad spectrum of actual job functions, "product manager" can be a highly catch-all term that varies by product, seniority, company, and even personality.
In some companies, they are essentially project managers who groom the backlog and coordinate releases with support, and (ideally) take a variety of coordination tasks off of engineers plates. At the other extreme, they're pure concept+strategy, and (ideally) provide a clear vision that allows other teams to understand where they are going and allow them to prioritize independently.
There's a few other dimensions I could probably name, but wherever someone sits on these dimensions, it is possible for them to be bad at their job - either because they're a mismatch for the job they have or because they're just not very good.
This isn't unique to PMs, of course - I have worked with a lot of engineers who are bad at their job for the same reasons. And I could s/product manager/software engineer/ in the linked article and recognize a lot of the same negative behaviors and patterns.
I think one of the reasons there are a lot of bad SWEs and PMs is that roles that were once only appealing to people who were genuinely passionate about what they were doing are now considered general purpose desirable careers. When I started working in tech 25+ years ago, most of the people who were entering the software industry found computers and technology deeply interesting, and enjoyed working in the space. When product managers started to appear as a more defined job function, the best PMs were experienced engineers, marketers, etc. who cared about and understood their users, the business problems, and could help drive things forward as the landscape became increasingly complex.
Today, there are a lot of people who enter software engineering and product management who are not particularly interested in the work. It's just a job, it's just pushing bits or paperwork around, and while many of those people are still effective, it can engender the behaviors depicted in the article.
That doesn't mean the role is a mistake, especially since the article depicts the most negative version of product management: "These PMs you hire have no vision, charisma, expertise, strong beliefs, or technical skills."
That's the problem right there - the role of a product manager is fundamentally about driving clarity. That clarity could come in the form of better requirements, customer understanding, a strategic focus, and yes, even things like metrics and goals (if they are clarifying!). If a product manager is not providing clarity, they are bad at their job. If an engineering team knows with exact clarity what they should be prioritizing all the time, they don't need a PM.
In some companies, they are essentially project managers who groom the backlog and coordinate releases with support, and (ideally) take a variety of coordination tasks off of engineers plates. At the other extreme, they're pure concept+strategy, and (ideally) provide a clear vision that allows other teams to understand where they are going and allow them to prioritize independently.
There's a few other dimensions I could probably name, but wherever someone sits on these dimensions, it is possible for them to be bad at their job - either because they're a mismatch for the job they have or because they're just not very good.
This isn't unique to PMs, of course - I have worked with a lot of engineers who are bad at their job for the same reasons. And I could s/product manager/software engineer/ in the linked article and recognize a lot of the same negative behaviors and patterns.
I think one of the reasons there are a lot of bad SWEs and PMs is that roles that were once only appealing to people who were genuinely passionate about what they were doing are now considered general purpose desirable careers. When I started working in tech 25+ years ago, most of the people who were entering the software industry found computers and technology deeply interesting, and enjoyed working in the space. When product managers started to appear as a more defined job function, the best PMs were experienced engineers, marketers, etc. who cared about and understood their users, the business problems, and could help drive things forward as the landscape became increasingly complex.
Today, there are a lot of people who enter software engineering and product management who are not particularly interested in the work. It's just a job, it's just pushing bits or paperwork around, and while many of those people are still effective, it can engender the behaviors depicted in the article.
That doesn't mean the role is a mistake, especially since the article depicts the most negative version of product management: "These PMs you hire have no vision, charisma, expertise, strong beliefs, or technical skills."
That's the problem right there - the role of a product manager is fundamentally about driving clarity. That clarity could come in the form of better requirements, customer understanding, a strategic focus, and yes, even things like metrics and goals (if they are clarifying!). If a product manager is not providing clarity, they are bad at their job. If an engineering team knows with exact clarity what they should be prioritizing all the time, they don't need a PM.
This article gets it wrong imho, it seems to think the problem is the caliber of the people, rather than the setup of the organization. In my 20 years of experience I've observed most people are willing and ready to push themselves to great heights. But the setup of most organizations doesn't support such levels of independence or freedom of operation. Also a big reason why so many people are drawn to startups.
As a solo founder and dev I think the Product Manager complexity dwarfs Development work. For example, in the code I can search for all usages of something. But when spec'ing out I have to keep track of many things and their orthogonality at once.
----
Here is a nice story from a former MS Excel's Program Manager
"My First BillG Review" by Joel Spolsky
https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
----
Here is a nice story from a former MS Excel's Program Manager
"My First BillG Review" by Joel Spolsky
https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
>Actually, take a minute to think hard, and come up with one product manager that achieved anything comparable to these folks.
Andy Jassy started as a product manager at Amazon and is now CEO of Amazon. Product thinking and working backwards from customer needs (and not forward from technology), is not just a big-tech concept, but applicable to every business big or small.
Andy Jassy started as a product manager at Amazon and is now CEO of Amazon. Product thinking and working backwards from customer needs (and not forward from technology), is not just a big-tech concept, but applicable to every business big or small.
The article gets it backwards for large companies. Most of these things exist at the behest of leadership. In the absence of a PM, these responsibilities often fall on engineering managers or engineers.
There are two types of effective PMs in my experience: the visionary who shapes the product, and the exceptional "team cat herder" who adeptly manages outward from the team: KPIs, regulatory reviews, and similar things. Whether this person should have a different title is irrelevant: That's the title they have and the role they take.
When a PM like that departs, these duties don't vanish; instead, they often become the responsibility of engineers, adding to their workload.
There are two types of effective PMs in my experience: the visionary who shapes the product, and the exceptional "team cat herder" who adeptly manages outward from the team: KPIs, regulatory reviews, and similar things. Whether this person should have a different title is irrelevant: That's the title they have and the role they take.
When a PM like that departs, these duties don't vanish; instead, they often become the responsibility of engineers, adding to their workload.
I'm just building a team for a SaaS b2b company where I'm the cto.
I'm going crazy doing iso27001 stuff, recruiting, devops, programming and product development.
Just recently I've hired people to help me in most of those roles, except Product Mgmt. So stuff like good API documentation, ordering of what tasks should devs do next, prioritizing of Bugs raised by QA , planning for the next features to implement, etc etc doesn't get done.
I've worked with great ProdMs and also Technical Project Managers (shoot out to MissionCloud, one of the best PMs I worked with, is a lady from there) . The are invaluable.
I'm going crazy doing iso27001 stuff, recruiting, devops, programming and product development.
Just recently I've hired people to help me in most of those roles, except Product Mgmt. So stuff like good API documentation, ordering of what tasks should devs do next, prioritizing of Bugs raised by QA , planning for the next features to implement, etc etc doesn't get done.
I've worked with great ProdMs and also Technical Project Managers (shoot out to MissionCloud, one of the best PMs I worked with, is a lady from there) . The are invaluable.
The examples of “tremendous people,” we all have to acknowledge that we want to be like are all white, cis-het men. A good deal of the modern ones we know are assholes. And many of them are not that great at much of anything; it was privilege (and no small amount of luck) that got them where they ended up and myth making like the kind in this article that people aspire to.
That’s a silly bar to put before hiring someone to be a product manager.
That’s a silly bar to put before hiring someone to be a product manager.
> Picasso, Jeff Bezos, Mozart, Steve Jobs, Nikola Tesla, Elon Musk, Robert Oppenheimer, Peter Thiel, Leonardo, and others are worshipped by the masses.
I hesitantly have to give Elon Musk credit for proliferation of EVs and - yes, highly questionable - because of finally completing DARPAnet’s original mission via starlink’s usage in ongoing Ukraine war… (yikes, lot of “offset” should IMO be considered; on many ”fronts” with his business ventures actually).
But for what should Peter Thiel be worshipped again? Especially in comparison with the rest of the list?
I hesitantly have to give Elon Musk credit for proliferation of EVs and - yes, highly questionable - because of finally completing DARPAnet’s original mission via starlink’s usage in ongoing Ukraine war… (yikes, lot of “offset” should IMO be considered; on many ”fronts” with his business ventures actually).
But for what should Peter Thiel be worshipped again? Especially in comparison with the rest of the list?
Celebrated rather than worshipped.
Thiel is the philosopher behind all this.
I believe there's a recent interview with him originally in German.
A lot of the way you see tech companies operate today started with him
Thiel is the philosopher behind all this.
I believe there's a recent interview with him originally in German.
A lot of the way you see tech companies operate today started with him
Many PMs are lame ducks at companies because they have to "lead without influence" which is extremely challenging in many large companies where incentives do not align and takes time to build if you're good.
Clayton Christensen knew this all too well and calls this sustained innovation. In other words, to just make incremental improvements to a product to maintain a position in a market.
What this article is pointing out is a classic innovator's dilemma, in which the product manager role is unable to live up to the necessity to innovate and follow these great ideas of great PMs.
Overall a great article because it calls out the 10 dysfunctions of product management as told in books like "Build what matters". Especially this thought:
> Anyone with even a speckle of greatness eventually leaves. They either get pushed out by the mediocre dictator, or they leave on their own terms, as the environment has become intolerable to them.
The irony from my experience is that there are great people who want to do great things. They want a great PM and they want to follow a compelling vision. The modern day challenge is what companies are starting to identify... Vogons. "not actually evil, but bad-tempered, bureaucratic, officious and callous". Also known as middle management.
Clayton Christensen knew this all too well and calls this sustained innovation. In other words, to just make incremental improvements to a product to maintain a position in a market.
What this article is pointing out is a classic innovator's dilemma, in which the product manager role is unable to live up to the necessity to innovate and follow these great ideas of great PMs.
Overall a great article because it calls out the 10 dysfunctions of product management as told in books like "Build what matters". Especially this thought:
> Anyone with even a speckle of greatness eventually leaves. They either get pushed out by the mediocre dictator, or they leave on their own terms, as the environment has become intolerable to them.
The irony from my experience is that there are great people who want to do great things. They want a great PM and they want to follow a compelling vision. The modern day challenge is what companies are starting to identify... Vogons. "not actually evil, but bad-tempered, bureaucratic, officious and callous". Also known as middle management.
It sounds like this person has worked with some truly mediocre product managers. I’m a PM, from a self-taught engineering background, and I’ve worked with many mediocre folks too across all disciplines.
I view my job primarily as risk management. A great team of engineers and designers will face a huge number of risks to shipping great products, like not having the right skill set to articulate their vision to get others on board, or having lawyers impose requirements or restrictions on what can and cannot be done. My job is to manage that, to help bring out the best in the team so they can get on with the actually important work of building and shipping great products.
I judge success by how redundant I am. My goal is to not be needed, for the team to have the right context, confidence and support to make good decisions without me.
I love working with engineers to level-up their skills so they can do just this; I work with my EM partners to understand the strengths, weaknesses and goals of each engineer, and try and find ways I can help them progress.
In an ideal, utopian world maybe I’m not needed. I can understand that argument. But in most cases, doing truly great things will run up against challenges and risks, and a good PM works in partnership with their team to overcome them and is a net value add.
I view my job primarily as risk management. A great team of engineers and designers will face a huge number of risks to shipping great products, like not having the right skill set to articulate their vision to get others on board, or having lawyers impose requirements or restrictions on what can and cannot be done. My job is to manage that, to help bring out the best in the team so they can get on with the actually important work of building and shipping great products.
I judge success by how redundant I am. My goal is to not be needed, for the team to have the right context, confidence and support to make good decisions without me.
I love working with engineers to level-up their skills so they can do just this; I work with my EM partners to understand the strengths, weaknesses and goals of each engineer, and try and find ways I can help them progress.
In an ideal, utopian world maybe I’m not needed. I can understand that argument. But in most cases, doing truly great things will run up against challenges and risks, and a good PM works in partnership with their team to overcome them and is a net value add.
I’m a PM too and I agree; I judge how good a job I’m doing by how smooth everything runs for my team - how they have everything they need to do their best work, they have all the context, requirements, insight, metrics, goals….etc they have an understanding of what problem they’re trying to solve who we’re solving it for and crucially why we need to solve it.
A good PM creates an environment where engineers like OP thinks the PM is not needed because “PMs do nothing” or whatever. It’s short sighted and frankly insulting
A good PM creates an environment where engineers like OP thinks the PM is not needed because “PMs do nothing” or whatever. It’s short sighted and frankly insulting
Product managers are great when they actually manage the product. I've worked with 6 or 7 so far, and most of them seem to be better at playing corporate politics and discussing random stuff with their bosses than at describing accurately what they want you to build.
[deleted]
Boah... fallacies everywhere in this piece. Let's start:
> Picasso, Jeff Bezos, Mozart, Steve Jobs, Nikola Tesla, Elon Musk, Robert Oppenheimer, Peter Thiel, Leonardo [... would be amazing PMs]
I beg to differ. Mozart died at 35, completely indebted after years of excess drinking. Jobs ousted from his own company after poor strategic decisions and intolerable behaviour. Picasso / Leonardo were geniuses of their own without need for co-workers.
> None of them [geniuses mentioned before] were motivated by OKRs, KPIs, data, or other people’s opinion.
Wrong. We know from another genius, Kurt Gödel, that even intellectually brilliant people struggle with procrastination. In Gödel's notebooks we find a multidimensional planning system (goals for the day, week, quarter, next year) and clear OKRs ("finish preparation of Princeton lecture until end of this month").
> The enormous mistake you can make is to adopt a model that requires tremendous people, without having these tremendous people.
Again wrong. Great discoveries are made by employing great discipline over a long time, not by hiring some rock stars. Why else would Elon Musk call one of his most ambitious ventures "the boring company"? Why else was Katalin Kariko, who "invented" the Covid-19-vaccine and received the nobel prize for Medicine in 2023 ousted twice from Penn University, because her research was deemed "not sexy enough" for grants?
> Picasso, Jeff Bezos, Mozart, Steve Jobs, Nikola Tesla, Elon Musk, Robert Oppenheimer, Peter Thiel, Leonardo [... would be amazing PMs]
I beg to differ. Mozart died at 35, completely indebted after years of excess drinking. Jobs ousted from his own company after poor strategic decisions and intolerable behaviour. Picasso / Leonardo were geniuses of their own without need for co-workers.
> None of them [geniuses mentioned before] were motivated by OKRs, KPIs, data, or other people’s opinion.
Wrong. We know from another genius, Kurt Gödel, that even intellectually brilliant people struggle with procrastination. In Gödel's notebooks we find a multidimensional planning system (goals for the day, week, quarter, next year) and clear OKRs ("finish preparation of Princeton lecture until end of this month").
> The enormous mistake you can make is to adopt a model that requires tremendous people, without having these tremendous people.
Again wrong. Great discoveries are made by employing great discipline over a long time, not by hiring some rock stars. Why else would Elon Musk call one of his most ambitious ventures "the boring company"? Why else was Katalin Kariko, who "invented" the Covid-19-vaccine and received the nobel prize for Medicine in 2023 ousted twice from Penn University, because her research was deemed "not sexy enough" for grants?
> Great discoveries are made by employing great discipline over a long time, not by hiring some rock stars. Why else would Elon Musk call one of his most ambitious ventures "the boring company"?
Because it’s a company that makes tunnels. They bore holes in rock. It’s a company that bores – a boring company. It’s nothing more than a stupid pun.
Because it’s a company that makes tunnels. They bore holes in rock. It’s a company that bores – a boring company. It’s nothing more than a stupid pun.
100 percent agree. Humans love giving credit to individuals for the achievements of a community. It's not that individual leaders aren't important, it's that we give them the lion's share of the credit.
My org is full of people who were promoted because they can talk clearly and authoritatively about the project they botched the implementation of. But then they spent 10 people's time "influencing the team" to fix. But hey, they're loud, sure of themselves, and willing to break things so they must be good
My org is full of people who were promoted because they can talk clearly and authoritatively about the project they botched the implementation of. But then they spent 10 people's time "influencing the team" to fix. But hey, they're loud, sure of themselves, and willing to break things so they must be good
I think that we should change the name from Product Manager to Customer Advocate because that’s what the good PMs I’ve worked with are be up doing.
Product manager is such a weird term that can mean absolutely anything, and putting manager in the title leads to the expectation that PMs are supposed to be running the show instead of working cooperatively. The Customer advocate should be just one voice among many when making decisions.
And after nearly 20 years of building software, I have come to the conclusion that it is completely impossible to be an expert in generic “Product”.
Product manager is such a weird term that can mean absolutely anything, and putting manager in the title leads to the expectation that PMs are supposed to be running the show instead of working cooperatively. The Customer advocate should be just one voice among many when making decisions.
And after nearly 20 years of building software, I have come to the conclusion that it is completely impossible to be an expert in generic “Product”.
Not sure if the author is a newbie or never comes across a good product manager in his career. The post is very much generalised which it shouldn’t be.
I read: 'I had a bad experience with a product manager, so all are bad.'
I agree that there are tons of bad PMs out there. But allow me to summarize what a good PM does:
Talk to customers; either to dig deep into their use case, deescalate a situation, figure out solutions, or conduct research. Monitor the rest of the market. Plan launches, pricing, and coordinate with sales teams, etc. - I had Product Marketing staff before, but they missed context and delivered bad experiences. I find it way harder to find a good product marketing manager than a good product manager. The PM is the DRI (Directly Responsible Individual) and therefore takes a lot of shit. The PM acts as a filter so you can continue doing your job. A good PM can even write a line of code here and there. Prototyping is part of the job. Roadmap, strategy, vision, build vs. buy... often the center of friction between what the business wants, what customers want, what the business can afford, and what engineers want to build. Finding a middle ground. You are right; these are not skills you learn in school. A PM wears a lot of hats. People with a solution architect or engineering background with a customer-facing element to their past tend to have the best chance of being a good PM. But by no means is the PM job an unnecessary one - do you want to figure out how to price a product and be responsible if sales can't sell it? I hope you come across a good PM in your career.
'Just hire great people' - what's new?
PS: The success of a PM highly depends on the engineering culture. If engineers are convinced all PMs are useless and they have no real job, or as a real-life example: engineer thinks A, PM shows data that shows B, but engineer just thinks the data is wrong and will do A anyway... it will be a highly frustrating collaboration for both. Please keep an open mind.
I agree that there are tons of bad PMs out there. But allow me to summarize what a good PM does:
Talk to customers; either to dig deep into their use case, deescalate a situation, figure out solutions, or conduct research. Monitor the rest of the market. Plan launches, pricing, and coordinate with sales teams, etc. - I had Product Marketing staff before, but they missed context and delivered bad experiences. I find it way harder to find a good product marketing manager than a good product manager. The PM is the DRI (Directly Responsible Individual) and therefore takes a lot of shit. The PM acts as a filter so you can continue doing your job. A good PM can even write a line of code here and there. Prototyping is part of the job. Roadmap, strategy, vision, build vs. buy... often the center of friction between what the business wants, what customers want, what the business can afford, and what engineers want to build. Finding a middle ground. You are right; these are not skills you learn in school. A PM wears a lot of hats. People with a solution architect or engineering background with a customer-facing element to their past tend to have the best chance of being a good PM. But by no means is the PM job an unnecessary one - do you want to figure out how to price a product and be responsible if sales can't sell it? I hope you come across a good PM in your career.
'Just hire great people' - what's new?
PS: The success of a PM highly depends on the engineering culture. If engineers are convinced all PMs are useless and they have no real job, or as a real-life example: engineer thinks A, PM shows data that shows B, but engineer just thinks the data is wrong and will do A anyway... it will be a highly frustrating collaboration for both. Please keep an open mind.
[deleted]
Work long enough in one role and every other role starts to feel unnecessary. You start to learn what creates success for you personally, and expanding that will inevitably awkwardly slam you into other people who are now seemingly blocking you. Enter this feeling of “PMs are useless, just let me do it”.
I can guarantee that if you start being responsible for actual PM work for an extended period of time, you will start drafting your article about “they ask us to do too much, we need time to focus”
Working with other humans at scale is inherently difficult, we all take turns being the solution, and we all take turns being the problem. Such is life.
I can guarantee that if you start being responsible for actual PM work for an extended period of time, you will start drafting your article about “they ask us to do too much, we need time to focus”
Working with other humans at scale is inherently difficult, we all take turns being the solution, and we all take turns being the problem. Such is life.
I think Product Managers are extremely valuable.
I believe the author must have worked with PMINO or Product Manager in Name Only. AKA, when companies hire Product Mangers (let's call them PM uppercase) and make them program managers (pm, and please this isn't me demeaning program managers by using lower case- just a differentiation).
A PM is in charge of setting product vision and realizing it. A pm is in charge of ensuring that happens by aligning resources. Both are really valuable parts of the team, but they are different roles. I don't believe it is good to mix the two because they are two distinct set of skills.
The PM is the war strategist who understands opponents' weakness and opportunities to strike for the campaign's success, while the pm is in charge of staging the battlefield to ensure those tactics can be carried out by keeping the battalions equipped for success. I know military analogies aren't everyone's cup of tea, but just using what I know.
The best PMs I've worked with were purely product focused. They didn't engage in resource alignment and dealing with middle managers. The best pms were purely managers. They engaged in working with engineering managers/directors to ensure the right people were working on the right initiatives. They kept schedules on track and helped everyone stay sane with the work that had to be done.
Maybe I am wrong too, but this is what I believe is the right approach that I plan to employ at my company. When the company is small and only a single engineering team (like 5 people total) I don't think there's any reason to have a pm. When there are multiple teams and distinct organizations, you really need pm so the PM can stay focused in their role.
I believe the author must have worked with PMINO or Product Manager in Name Only. AKA, when companies hire Product Mangers (let's call them PM uppercase) and make them program managers (pm, and please this isn't me demeaning program managers by using lower case- just a differentiation).
A PM is in charge of setting product vision and realizing it. A pm is in charge of ensuring that happens by aligning resources. Both are really valuable parts of the team, but they are different roles. I don't believe it is good to mix the two because they are two distinct set of skills.
The PM is the war strategist who understands opponents' weakness and opportunities to strike for the campaign's success, while the pm is in charge of staging the battlefield to ensure those tactics can be carried out by keeping the battalions equipped for success. I know military analogies aren't everyone's cup of tea, but just using what I know.
The best PMs I've worked with were purely product focused. They didn't engage in resource alignment and dealing with middle managers. The best pms were purely managers. They engaged in working with engineering managers/directors to ensure the right people were working on the right initiatives. They kept schedules on track and helped everyone stay sane with the work that had to be done.
Maybe I am wrong too, but this is what I believe is the right approach that I plan to employ at my company. When the company is small and only a single engineering team (like 5 people total) I don't think there's any reason to have a pm. When there are multiple teams and distinct organizations, you really need pm so the PM can stay focused in their role.
Here's what I have found, working in a big software company: The company has rigid roles. Often they are not able to find a good fit for the role. Rather than leaving the role unfilled, they hire whoever then can find. The person is not able to fill the role well, and that's when the bad things mentioned in the article happens.
The solution is to not be rigid with the role. Have the person do whatever they are best at doing.
This is not just a PM thing. If you hired a developer and it turns out they are not good at coding but are good at DevOps then let them do DevOps full-time, offloading DevOps responsibilities from other developers.
The solution is to not be rigid with the role. Have the person do whatever they are best at doing.
This is not just a PM thing. If you hired a developer and it turns out they are not good at coding but are good at DevOps then let them do DevOps full-time, offloading DevOps responsibilities from other developers.
So who's going to do the thing you were hiring for?
Take the example of hiring developers. If the guy you hired turned out to be not so good at coding but is good at DevOps then have him offload DevOps work from other developers. This leaves other developers with more time for development. There's your answer.
[deleted]
I’ve been blessed to have worked as an engineer, an engineering manager, a product manager and a “product manager manager” alongside leaders and peers who “did product right” and am aware enough of companies and people who “did it wrong” to compare and contrast.
At the end of the day, someone needs to have a vision of how your product is going to be successful and can walk the team along that journey. Back in the day, and in small companies today, that person is often the engineering manager or even the technical founder. In large companies, this is the primary response of the PM.
The reason is that engineering managers who can also “do the product” thing are rare, both because there’s certain personality traits and skills that are required but not common and it takes a lot of bandwidth.
For example, in my first job as a PM, I traveled to 20+ countries every year meeting with hundreds and not thousands of clients and prospects to really feel out my product’s place and opportunity. That investment of time and breadth of “perception” put me in a really good place to lead my product.
It’s hopefully obvious that I wouldn’t be able to do that and also be responsible for careers of 50+ developers, technical direction etc, so yeah I had to be a PM, not an engineering manager, to operate like that.
In terms of impact, the most junior PMs take load off engineers. Eg: they go to the customer and write down what they ask for. The engineer could do that themselves but it’s deemed a better investment of their time to keep coding, so the junior PM is thrown at it to free them up. A middle level PM talks to a bunch of customers and defines a solution for their biggest problems (in contrast to the junior who depends on the customer to tell them what is needed in what order.) This PM synthesizes customer information into something different and hopefully easier to deliver and more scalable. This is where the skill set diverges from engineers. At the most senior level, the PM anticipates the kinds of problems their customers will have down the road and acts as a “visionary” to get the solutions built proactively.
PMs obviously can be asked to do other jobs, like I’ve often seen them tasked with running sprints etc. it’s fine if the PM or someone from engineering does it but in neither case is it a required part of the job and is better done by a project manager who is more inanely focused on running processes.
Another way I like to describe what a PM does - they are the teams interface into the world, on the hook for turning external ambiguity into internal clarity. They are on the hook for driving priorities with the team and that doesn’t just mean customer priorities. For example, sometime a purely technical thing can be the most important thing to work on and at other times the same thing could be a waste to address. The PM should be able to help the team understand which situation they are facing.
All this btw explains the massive pay disparity in PMs across seniority and across companies. Some companies view PM as that “leverage to engineer” model I described above which by definition pays less than the engineer. On the other extreme companies see senior PMs as the strategic leaders of multi-billion dollar product lines.
At the end of the day, someone needs to have a vision of how your product is going to be successful and can walk the team along that journey. Back in the day, and in small companies today, that person is often the engineering manager or even the technical founder. In large companies, this is the primary response of the PM.
The reason is that engineering managers who can also “do the product” thing are rare, both because there’s certain personality traits and skills that are required but not common and it takes a lot of bandwidth.
For example, in my first job as a PM, I traveled to 20+ countries every year meeting with hundreds and not thousands of clients and prospects to really feel out my product’s place and opportunity. That investment of time and breadth of “perception” put me in a really good place to lead my product.
It’s hopefully obvious that I wouldn’t be able to do that and also be responsible for careers of 50+ developers, technical direction etc, so yeah I had to be a PM, not an engineering manager, to operate like that.
In terms of impact, the most junior PMs take load off engineers. Eg: they go to the customer and write down what they ask for. The engineer could do that themselves but it’s deemed a better investment of their time to keep coding, so the junior PM is thrown at it to free them up. A middle level PM talks to a bunch of customers and defines a solution for their biggest problems (in contrast to the junior who depends on the customer to tell them what is needed in what order.) This PM synthesizes customer information into something different and hopefully easier to deliver and more scalable. This is where the skill set diverges from engineers. At the most senior level, the PM anticipates the kinds of problems their customers will have down the road and acts as a “visionary” to get the solutions built proactively.
PMs obviously can be asked to do other jobs, like I’ve often seen them tasked with running sprints etc. it’s fine if the PM or someone from engineering does it but in neither case is it a required part of the job and is better done by a project manager who is more inanely focused on running processes.
Another way I like to describe what a PM does - they are the teams interface into the world, on the hook for turning external ambiguity into internal clarity. They are on the hook for driving priorities with the team and that doesn’t just mean customer priorities. For example, sometime a purely technical thing can be the most important thing to work on and at other times the same thing could be a waste to address. The PM should be able to help the team understand which situation they are facing.
All this btw explains the massive pay disparity in PMs across seniority and across companies. Some companies view PM as that “leverage to engineer” model I described above which by definition pays less than the engineer. On the other extreme companies see senior PMs as the strategic leaders of multi-billion dollar product lines.
Our PM is so bad at her role she's rather a cheerleader.
I agree and disagree with the author
my take about all this and every other role is, it doesn't matter what roles and titles and processes you give people
if they suck
or if they're all great at what they do but cannot work together as a team (VERY common in tech where everyone has superiority complex towards everyone else)
the output will suck
teams composed of people who are good at what they do (they don't have to be tremendous) AND can work well together as a team kind of run themselves and don't reaaaally "need" pms or any other formal role - they just need goals that make sense to them and they will execute with speed, quality and efficiency
meanwhile not even the best PM/tremendous individual in the world can save a team composed of people who suck or are great but can't work together as a team
my take about all this and every other role is, it doesn't matter what roles and titles and processes you give people
if they suck
or if they're all great at what they do but cannot work together as a team (VERY common in tech where everyone has superiority complex towards everyone else)
the output will suck
teams composed of people who are good at what they do (they don't have to be tremendous) AND can work well together as a team kind of run themselves and don't reaaaally "need" pms or any other formal role - they just need goals that make sense to them and they will execute with speed, quality and efficiency
meanwhile not even the best PM/tremendous individual in the world can save a team composed of people who suck or are great but can't work together as a team
I've rarely seen a company went downhill because of engineering. And at all places, engineering wasn't marvellous rather quite the opposite.
But have seen companies from inside that totally went downhill because you could sense that product tier is totally clueless. They know nothing of the domain and if anything, pretty superficial. Have no spark, interest or intuition of what will work and what not.
May be this was limited to my own sample size. Great products are out their and they didn't fall from the sky.
But have seen companies from inside that totally went downhill because you could sense that product tier is totally clueless. They know nothing of the domain and if anything, pretty superficial. Have no spark, interest or intuition of what will work and what not.
May be this was limited to my own sample size. Great products are out their and they didn't fall from the sky.
"But the more somebody is mediocre, the more likely they are to be put off by this intensity and passion. The more they’re willing to compromise, to lower standards, and to cut corners."
There is IMO no correlation between being mediocre and being put off by intensity and passion.
Overall I think this article generalizes a lot. I can't say for sure that the article is not applicable to a certain part of the industry, but it certainly doesn't in any way represent my experience.
PMs can be good, bad, or anything inbetween. I've never experienced that a good PM was not a benefit to a project.
There is IMO no correlation between being mediocre and being put off by intensity and passion.
Overall I think this article generalizes a lot. I can't say for sure that the article is not applicable to a certain part of the industry, but it certainly doesn't in any way represent my experience.
PMs can be good, bad, or anything inbetween. I've never experienced that a good PM was not a benefit to a project.
> There is IMO no correlation between being mediocre and being put off by intensity and passion.
A lot of people hate those that outshine them, or “make them look bad” (in comparison). It’s sadly a part of human nature.
A lot of people hate those that outshine them, or “make them look bad” (in comparison). It’s sadly a part of human nature.
> Everybody runs just to stand still.
Ahh Red Queen strikes again! Such is life
Ahh Red Queen strikes again! Such is life
I've worked with exactly 1 exceptional product manager. The rest were all horrible and had a negative impact on the product/team.
The simplest thing I can boil it down to is how they respond when asked a question. With the exceptional PM, when you asked a question you got an answer.
With bad PMs, you ask a question and you get "Good callout! I'll try to get some alignment with our stakeholders on that". Every decision point spins out into this web of stakeholders and cross-functional team buy-in. And no decision is ever made, everything is always in flux and uncertain. During this process they have produced an entire literature of documentation, each version contradictory to the others. "That feature was only in the original doc, we got rid of it in v2" but also "That feature was in v1, I forgot to copy paste it into v2 but we never canceled it. Sorry!" Every variation of every feature exists somewhere, a kind of superposition of the product out there somewhere.
It consistently amazes me that they never seem to be able to grasp how self-destructive this is to the product development. Or maybe they do, but they just don't care and they are just exploiting their evaluation framework. Probably the latter.
The simplest thing I can boil it down to is how they respond when asked a question. With the exceptional PM, when you asked a question you got an answer.
With bad PMs, you ask a question and you get "Good callout! I'll try to get some alignment with our stakeholders on that". Every decision point spins out into this web of stakeholders and cross-functional team buy-in. And no decision is ever made, everything is always in flux and uncertain. During this process they have produced an entire literature of documentation, each version contradictory to the others. "That feature was only in the original doc, we got rid of it in v2" but also "That feature was in v1, I forgot to copy paste it into v2 but we never canceled it. Sorry!" Every variation of every feature exists somewhere, a kind of superposition of the product out there somewhere.
It consistently amazes me that they never seem to be able to grasp how self-destructive this is to the product development. Or maybe they do, but they just don't care and they are just exploiting their evaluation framework. Probably the latter.
Skill issue. Most product managers suck. A great product manager is amazing.
Principal Product Manager here. I agree... Way too many people took advantage of this role over the last 20 years, IMO, in the name of FOMO. Too many I avoided or fired because they just could never, never, understand the tech.
I wont hire a PM now that isn't also a contributor during work or in their spare time. Not only should they be excellent leads, they should be able to get down and dirty actually move the needle, design something, write code. Run their own damn prototype and test.
A big part of my current role is just empowering more Jr PMs to contribute more by educating them on certain skills, but it doesn't scale and none of them have the drive to study the subjects on their own.
I envision a shift coming. Ive never subscribed to the bullshit, but Im personally moving away from much of the "PM activities" and spending more time on my original skills, design and engineering...
I wont hire a PM now that isn't also a contributor during work or in their spare time. Not only should they be excellent leads, they should be able to get down and dirty actually move the needle, design something, write code. Run their own damn prototype and test.
A big part of my current role is just empowering more Jr PMs to contribute more by educating them on certain skills, but it doesn't scale and none of them have the drive to study the subjects on their own.
I envision a shift coming. Ive never subscribed to the bullshit, but Im personally moving away from much of the "PM activities" and spending more time on my original skills, design and engineering...
Agree PMs should be technically capable. It's an increasingly frustrating issue on my current team: the PM does nothing and is routinely caught between technical contributors and stakeholders above. I now think engineer/s should just take over the PM role.
edit: "nothing" meaning they just schedule meetings
edit: "nothing" meaning they just schedule meetings
I don't believe it should be a monoculture role. I think it should be held by generalist contributors like me. I cut my teeth and at a great cost/time to me, learned many skills professionally. I don't want some punk Software Engineer who thinks they are god coming in and making a mess of my hardware or my infrastructure.
Yes. Fundamentally product manager is a generalist role that spans across disciplines. These roles are always hard to fill because they don't have a standard template. Moreover, at the point when an organization attempts to formalize such a role, the culture has likely reached a point where people don't even know what they ought to be looking for in the first place.
We frequently assume that if someone has no specialty then they must be a generalist. There is the freshly minted MBAs who did a two year consulting stint out of school who is familiar with many topics though they are clearly not an expert. There is the person with a degree in the humanities who claims that they are a generalist just because they can't do math and never tried to learn javascript. There is the engineer who is not very talented and tries to push their way into management since they are great at scheduling meetings when everyone else was too busy doing the actual work.
This is not to say that an MBA or an MFA are not great degrees. It is simply to say that they are not enough on their own. One needs to actually do things - a lot of things. Real generalists developed their skill set through their own hard work over a long period of time.
We frequently assume that if someone has no specialty then they must be a generalist. There is the freshly minted MBAs who did a two year consulting stint out of school who is familiar with many topics though they are clearly not an expert. There is the person with a degree in the humanities who claims that they are a generalist just because they can't do math and never tried to learn javascript. There is the engineer who is not very talented and tries to push their way into management since they are great at scheduling meetings when everyone else was too busy doing the actual work.
This is not to say that an MBA or an MFA are not great degrees. It is simply to say that they are not enough on their own. One needs to actually do things - a lot of things. Real generalists developed their skill set through their own hard work over a long period of time.
product manager role is ubi.
Customer Analyst is the actual badly-needed role, while “Product Manager” is a double category error. The misleading title causes a lot of dysfunction
Project Managers can also be very useful in a complex project that spans departments but that’s a completely separate role
Project Managers can also be very useful in a complex project that spans departments but that’s a completely separate role
> the problems I described happen everytime anyone without vision, charisma, passion, technical skills, and willpower is put in charge. So why the focus on product managers? It’s because of this tendency to wanting people with a product manager title in charge of software product development.
That a Product Manager may seem "in charge," of development is incidental to the role, and not the purpose of it. The role exists to discover features and scale them to customer demand. Managing means "to extract value from," and a lot falls into place when that lands.
That a Product Manager may seem "in charge," of development is incidental to the role, and not the purpose of it. The role exists to discover features and scale them to customer demand. Managing means "to extract value from," and a lot falls into place when that lands.
The article approaches the problem in a strange way: In most big consumer-facing companies, product manager is a very important title and product managers have a lot of power.
One problem is that Scrum jargon uses the term "product owner." That might have been intended to give that person more influence, but the effect most often is that real product managers assign junior people to that role and it becomes the "features check-box accountant."
Real product managers should be directly engaged in product development teams because, if they are any good, they have clout with senior management and can grok concepts like minimum viable product, especially the viable part.
I can understand the frustration with mediocre product managers. But that's a symptom of being in a sub-scale organization that can't hire great product managers. If the senior management don't see that and engage better with their product teams to make up for it, you're screwed. And Scrum jargon often adds to the problem.
One problem is that Scrum jargon uses the term "product owner." That might have been intended to give that person more influence, but the effect most often is that real product managers assign junior people to that role and it becomes the "features check-box accountant."
Real product managers should be directly engaged in product development teams because, if they are any good, they have clout with senior management and can grok concepts like minimum viable product, especially the viable part.
I can understand the frustration with mediocre product managers. But that's a symptom of being in a sub-scale organization that can't hire great product managers. If the senior management don't see that and engage better with their product teams to make up for it, you're screwed. And Scrum jargon often adds to the problem.
Some engineers and designers simply cannot stomach the idea that they aren’t actually geniuses. This guy comparing great visionary engineers to Picasso immediately sounds like one of those people that pretty much anyone (in any role) hates working with due to their massive ego.
There are many many bad PMs who are either dead weight or actively drag down their teams. But most eng and design teams are so much more inept and slow without any PM that even a mediocre one clearly improves velocity (if not effectiveness).
There are many many bad PMs who are either dead weight or actively drag down their teams. But most eng and design teams are so much more inept and slow without any PM that even a mediocre one clearly improves velocity (if not effectiveness).
At Apple, we had Project Managers (for instance "Engineering Project Managers" or EPMs). These PMs were not our bosses, and functioned as our peers in the organizations. They had a well-defined role: to facilitate the project being completed and to manage the dependencies with other teams and projects. Apple PMs do this through a combination of meetings, Radar (issue tracking), and interfacing with ICs and their managers.
This is different from the "Product Manager" at other companies which typically "owns" a product's direction and has authority over the people building it. That mixes project management with people management, politics, and worst of all, ego.
I never worked with an EPM at Apple that caused interpersonal problems. They all just wanted to fix bugs, figure out what we could and couldn't do in a specific timeframe, and release products on schedule. IMO, this is one aspect of Apple's organizational process that other companies should emulate, but I've never encountered it anywhere else. Maybe this kind of thing can only work at large companies that can afford to hire people for such a well-defined role.
This is different from the "Product Manager" at other companies which typically "owns" a product's direction and has authority over the people building it. That mixes project management with people management, politics, and worst of all, ego.
I never worked with an EPM at Apple that caused interpersonal problems. They all just wanted to fix bugs, figure out what we could and couldn't do in a specific timeframe, and release products on schedule. IMO, this is one aspect of Apple's organizational process that other companies should emulate, but I've never encountered it anywhere else. Maybe this kind of thing can only work at large companies that can afford to hire people for such a well-defined role.
but that's how it's officially supposed to be in other companies as well and it never works out that way. The PM sits at the middle of customers, leadership and implementation and the leadership then continually talks to the PMs and tells them what they want and the PM relays it and so inevitably the PM becomes a sort of artificial authority figure even though it is supposed to be a flat hierarchy. And of course a professional, informal relationship develops between PM and leadership because they talk all the time and so if you ever dared to ask leadership directly for whether this is really what they want, they'll back up the PM.
Half of the product managers I have worked or interacted with don't have any real expertise and seem to have just fallen into the role. As a result, I don't think they often understand the complexities of their cross-functional stakeholders/peers and how things need to be completed in order to deliver a functional deliverable.
I'm not at all convinced of the author's argument. Mediocre people in any level of an organization will produce mediocre results. If that person is in a position of leadership, their mediocrity might reach further. I don't see how anything the author said is specific to a PM role.
Perhaps the author just doesn't understand the difference between managers and leaders? (many people don't) https://1.bp.blogspot.com/-Naz6pvFqGfk/VQ2JxTNg0UI/AAAAAAAAH...
I'm a product manager, and I'm glad that many commenters in this thread agree that we are not all useless :) Of course, just like with any role, there are those that are good and bad at it, but I am glad most of you worked with good PMs and know the value such a person can bring.
I also saw astute comments from folks that recognize that if the product manager role does not exist as a distinct role, someone else in the organization has to take on the work of determining what to build and when, based on market and customers needs - usually engineering or product marketing. There is nothing wrong with that, btw, just different way to slice the same pie of responsibilities. Finally, several folks rightfully pointed out that a product manager (person accountable for building the right product for the market) is very different from a project or program manager (a person coordinating internal activities).
The only thing I'd add here is that product management roles can also be very different, depending on the stage of the company (early stage vs late stage), the type of product it builds (e.g. B2B vs B2C), and the industry vertical. Looking at the author's LI profile, he seems to work for larger companies, in the financial sector, in the UK. Perhaps in that world (which I perceive to be a fairly rigid, regulated industry), the role of the product manager is quite different from what I have personally experienced working as a PM in the Bay Area for early and mid stage startups.
I also saw astute comments from folks that recognize that if the product manager role does not exist as a distinct role, someone else in the organization has to take on the work of determining what to build and when, based on market and customers needs - usually engineering or product marketing. There is nothing wrong with that, btw, just different way to slice the same pie of responsibilities. Finally, several folks rightfully pointed out that a product manager (person accountable for building the right product for the market) is very different from a project or program manager (a person coordinating internal activities).
The only thing I'd add here is that product management roles can also be very different, depending on the stage of the company (early stage vs late stage), the type of product it builds (e.g. B2B vs B2C), and the industry vertical. Looking at the author's LI profile, he seems to work for larger companies, in the financial sector, in the UK. Perhaps in that world (which I perceive to be a fairly rigid, regulated industry), the role of the product manager is quite different from what I have personally experienced working as a PM in the Bay Area for early and mid stage startups.
> anything short of perfection was inconceivable to them
them being the list of leonardo, steve jobs, peter thiel etc..
the part I quoted just isn't true
them being the list of leonardo, steve jobs, peter thiel etc..
the part I quoted just isn't true
Sounds like he wasn't happy with his last PM haha. Interesting convo starter article though, as the PM role seems to also draw a wide range of opinions. In my view, the PM duties are critical, but the PM function is what a company makes it, as there are multiple ways to divvy up work and get things shipped.
To me, great products are a result of having a leader in the company who brings strong vision, customer focus, prioritizing the needle movers, and assembles the right technical talent to turn concepts into reality. This leader "gets it", and they make the tough decisions.
So while simply having a PM doesn't ensure these things, it doesn't necessarily prevent them either. Once you scale, the PM function brings much needed order to chaos. But if a company is relying purely on IC PM's to bring the vision, focus, needle movers, leadership, the company is flying blind as it's a signal that the founders / execs / board are absent. And that's a bigger problem than not loving your PM.
To me, great products are a result of having a leader in the company who brings strong vision, customer focus, prioritizing the needle movers, and assembles the right technical talent to turn concepts into reality. This leader "gets it", and they make the tough decisions.
So while simply having a PM doesn't ensure these things, it doesn't necessarily prevent them either. Once you scale, the PM function brings much needed order to chaos. But if a company is relying purely on IC PM's to bring the vision, focus, needle movers, leadership, the company is flying blind as it's a signal that the founders / execs / board are absent. And that's a bigger problem than not loving your PM.
This is what happened at the last startup I worked at, before we had a product, even MVP level, the CEO hired an engineering manager, who however was really a process person, except for the title the progression of things is about the same. Things quickly went south. A career ladder was introduced, this is in an org with 6 engineers. Everything even the smallest changed required an RFC and a spec. Open sourcing unrelated stuff got me into trouble. Instead of working on product we got into endless discussions on how to tweak the career ladder or some other part of the org, when there was no org to speak off.
There are certainly issues with having product managers, but the op doesn’t even seem to understand what they do.
I usually see PMs get soft authority, but not a budget.
However, I’ve worked with excellent product managers that can break down features and work through modeling sessions with strong understanding of what the business needs and what stakeholders expect.
It’s a silly article from an inexperienced person.
I usually see PMs get soft authority, but not a budget.
However, I’ve worked with excellent product managers that can break down features and work through modeling sessions with strong understanding of what the business needs and what stakeholders expect.
It’s a silly article from an inexperienced person.
I know of several companies over the years started by former Product Managers for teams I have worked for in the past. For the most part they were very successful and were the CEOs of their startups. Percentage wise they were more successful than my peer engineers at the time.
Most of them worked on failed projects within a much larger company. The failure was due more to bad management of large Corp rather than them. One is a VP at Apple today. Gotta say my career hasn't really shot to the moon by staying in Engineering. Food for thought.
Most of them worked on failed projects within a much larger company. The failure was due more to bad management of large Corp rather than them. One is a VP at Apple today. Gotta say my career hasn't really shot to the moon by staying in Engineering. Food for thought.
> Everything involves a large committee, where anyone can say “no” to anything, but nobody can fully say “yes”.
the problem is noone says no - everyone says yes to what the PM says, because of politics.
the problem is noone says no - everyone says yes to what the PM says, because of politics.
Can great, quality software come out of a group of 'mediocre' people? I think you'll find that you do indeed need a strong(er) process and set of rules to follow, that's fine but not always applicable.
I think you need to tailor each group and their process carefully, depending on available talent pools and the complexity of the work being attempted, and sometimes you will need active management of requirements to achieve better outcomes. If your process grows faster than the core coding team does, you probably do have a negative process jerk happening you need to disrupt.
Maybe you'll get better results by not calling people 'mediocre' to start with, as if that's anything but a hateful subjective label.
I think you need to tailor each group and their process carefully, depending on available talent pools and the complexity of the work being attempted, and sometimes you will need active management of requirements to achieve better outcomes. If your process grows faster than the core coding team does, you probably do have a negative process jerk happening you need to disrupt.
Maybe you'll get better results by not calling people 'mediocre' to start with, as if that's anything but a hateful subjective label.
I think this phenomena is less about PMs and more about a "data driven" culture.
I worked at a mobile game development company for a couple years. While the industry was young, they had some really big hits and grew to be mid sized. While I wasn't there for that era, talking to the people that were, it was mostly driven by passion and people that cared about games, and while they monetized well it wasn't the focus.
However, they had a couple of misses after those hits. This is pretty normal in game development, although in my opinion those misses were mostly about being too ambitious: way too much tech requiring cutting edge phones, tools that were still not mature, team sizes that were larger than they knew how to handle, etc.
So, the founders stepped down, and they were replaced with a new C-level staff that came from the gambling industry, mainly slot machines.
These people LOVED the numbers, KPIs and all that jazz. They loved showing those numbers to the staff too, which credit for being transparent but realistically a group of creatives are not generally that interested.
The problem was, since every decision required "data", innovation became impossible. Have a cool idea out of left field nobodies done but everyone is excited about? Can't be done, where's the data? But we can make a match 3 with a familiar IP! Who cares that we're just copying the market leaders and entering the space once its already saturated.
Anyway, the company folded two or so years after that. It was a shame because there was a ton of talent there, but the C level management just did not understand the industry, how to get creatives excited, and they did not care about games. They just had "data"
I worked at a mobile game development company for a couple years. While the industry was young, they had some really big hits and grew to be mid sized. While I wasn't there for that era, talking to the people that were, it was mostly driven by passion and people that cared about games, and while they monetized well it wasn't the focus.
However, they had a couple of misses after those hits. This is pretty normal in game development, although in my opinion those misses were mostly about being too ambitious: way too much tech requiring cutting edge phones, tools that were still not mature, team sizes that were larger than they knew how to handle, etc.
So, the founders stepped down, and they were replaced with a new C-level staff that came from the gambling industry, mainly slot machines.
These people LOVED the numbers, KPIs and all that jazz. They loved showing those numbers to the staff too, which credit for being transparent but realistically a group of creatives are not generally that interested.
The problem was, since every decision required "data", innovation became impossible. Have a cool idea out of left field nobodies done but everyone is excited about? Can't be done, where's the data? But we can make a match 3 with a familiar IP! Who cares that we're just copying the market leaders and entering the space once its already saturated.
Anyway, the company folded two or so years after that. It was a shame because there was a ton of talent there, but the C level management just did not understand the industry, how to get creatives excited, and they did not care about games. They just had "data"
> since every decision required "data", innovation became impossible.
That makes me think of this quote about the "McNamara Fallacy" [0]:
> But when the McNamara discipline is applied too literally, the first step is to measure whatever can be easily measured. The second step is to disregard that which can't easily be measured or given a quantitative value. The third step is to presume that what can't be measured easily really isn't important. The fo[u]rth step is to say that what can't be easily measured really doesn't exist. This is suicide.
Or, for a punchier meme approach, this SMBC comic [1].
[0] https://en.wikipedia.org/wiki/McNamara_fallacy
[1] https://www.smbc-comics.com/comic/rise-of-the-machines
That makes me think of this quote about the "McNamara Fallacy" [0]:
> But when the McNamara discipline is applied too literally, the first step is to measure whatever can be easily measured. The second step is to disregard that which can't easily be measured or given a quantitative value. The third step is to presume that what can't be measured easily really isn't important. The fo[u]rth step is to say that what can't be easily measured really doesn't exist. This is suicide.
Or, for a punchier meme approach, this SMBC comic [1].
[0] https://en.wikipedia.org/wiki/McNamara_fallacy
[1] https://www.smbc-comics.com/comic/rise-of-the-machines
yes one of the most frustrating things is to deal with people who come in and ask for data to support an idea. You suddenly have to justify common sense and good ideas to people who don't have any data for their ideas either but they'll certainly push their ideas first before any data has landed. After all you have to develop something, you can't just do nothing. And then later you do a survey on what they ended up doing without any data and naturally the thing that was visible got selected. People very rarely look at something and say: "well this entire product you developed is just garbage." Take the netflix ui for example, I'm sure they did plenty of surveys. Or the Google+ ui or the Windows Metro Phone. And yet it's not human to expect the surveyed to say that this is all bad and redesign it all from the ground up. A human being when asked for specifics will give specifics of some kind and then they will fix those specifics and think that it's all better now. I mean it's all absurd. Knowing what feature or design to implement is not really easy to do based on data. By the time you can gather data you already had to implement designs, ideas etc to a quite advanced degree. Data is very useful but it certainly can't be used for new product or feature development until you already developed them. At which point the data is already old and you have to make decisions about the future again.
I've seen two types of PMs:
- micromanagers of tasks and features
- insightful data munchers
The first group is usually a bunch of people citing Marty Cagan, talking about continuous discovery and running in circles. They are not helpful and sometimes hurtful to performance.
The second group captures business and market data, process it and create insights from it. They keep the engineering effort focused. Those are very helpful.
This is just my personal experience, of course, but I'm yet to see a third type.
EDIT: to be fair, Marty's books seem to advocate for the second type.
- micromanagers of tasks and features
- insightful data munchers
The first group is usually a bunch of people citing Marty Cagan, talking about continuous discovery and running in circles. They are not helpful and sometimes hurtful to performance.
The second group captures business and market data, process it and create insights from it. They keep the engineering effort focused. Those are very helpful.
This is just my personal experience, of course, but I'm yet to see a third type.
EDIT: to be fair, Marty's books seem to advocate for the second type.
I think the model that the film industry has where films have a director and producer is an interesting one, and one that might be interesting to see followed more in software. The 'vision' for a product is a different skillset from the more logistic skills that are also needed to make good software.
How is Peter Thiel on the list of infectiously visionary and charismatic leaders?
That would be like putting Paul G on this list. Neither of those two are applauded and loved in the mainstream even if they are both rich and extremely smart.
That would be like putting Paul G on this list. Neither of those two are applauded and loved in the mainstream even if they are both rich and extremely smart.
> These PMs you hire have no vision, charisma, expertise, strong beliefs, or technical skills. So what do they do when you give them that kind of power? They play it safe, and they play politics.
I can relate with that.
I was working on an operation that has the incredible track record: 74% of reliability (in a daily batch), 2 Engineers to serve 12 Analysts, stack running an old version of Haddop and Spark (2 majors down at least) and the company hired a technical PM.
The first measure of this PM? Setup meetings with consulting behind our backs, plus tons of politics with upper management, and the cherry on the top was he thought that was a good idea to move the Data Engineering team to a Front End team since “it’s more or less the same and a developer is developer everywhere”.
Final result: everyone quited and he eventually was fired with 1 year of delay.
I can relate with that.
I was working on an operation that has the incredible track record: 74% of reliability (in a daily batch), 2 Engineers to serve 12 Analysts, stack running an old version of Haddop and Spark (2 majors down at least) and the company hired a technical PM.
The first measure of this PM? Setup meetings with consulting behind our backs, plus tons of politics with upper management, and the cherry on the top was he thought that was a good idea to move the Data Engineering team to a Front End team since “it’s more or less the same and a developer is developer everywhere”.
Final result: everyone quited and he eventually was fired with 1 year of delay.
That article is such a dumbfounded mess by inexperienced folks that i don’t even know where to start.
Lots of hubris coming out of this article, and likely a healthy helping Dunning-Kruger as well.
Product-level thinking isn't confined to PMs. In fact, a good engineer should be conversant on the most important aspects of the product they work on, and care about many of the same metrics.
Having a good product function in a company can be very impactful when it comes to scoping and prioritizing, validating ROI, understanding what success looks like, and ensuring that people take into account the real cost of the work they do.
Sometimes this means making sure that engineers aren't just building things they think are fun but pose no real ROI, or asking engineers for things they don't feel like doing, or -- the gravest of all crimes -- asking for status on in-flight progress, perhaps even in person. This is why these folks draw the ire of some of our less mature fellows.
Product-level thinking isn't confined to PMs. In fact, a good engineer should be conversant on the most important aspects of the product they work on, and care about many of the same metrics.
Having a good product function in a company can be very impactful when it comes to scoping and prioritizing, validating ROI, understanding what success looks like, and ensuring that people take into account the real cost of the work they do.
Sometimes this means making sure that engineers aren't just building things they think are fun but pose no real ROI, or asking engineers for things they don't feel like doing, or -- the gravest of all crimes -- asking for status on in-flight progress, perhaps even in person. This is why these folks draw the ire of some of our less mature fellows.
They talk to the GD customers so the engineers don’t have to. They’re good at speaking with people. What is wrong with you people?
I think a dedicated, well intentioned and PM who truly cares deeply about the product is important for a company.
The problem here is that the skill involved with being a PM are equivalent to janitorial jobs. Anyone can do it. Anyone can have intuition on how they think a product should work. This is not a high skill job. The work itself is not easy, just unskilled. The person in this role has to spend ALOT of time diving into the purpose of the product and thinking of new features... etc. Anyone can do it but not a lot of people are WILLING to do it.
What makes this role hard to find good people for is that it's hard to quantitatively measure how willing a PM guy actually is. Instead we end up measuring the persons political skills. How good is that person at making you THINK he cares about the product? And that is the metric and bar you need to be good at to land the PM job. Politics is a hard skill. It's hard to measure and it's hard to train for.
What happens is we try to measure skills in one dimension but politics and charisma can cover it all up. People can bullshit their way past everything. That's why algorithm questions are so pervasive in the industry. It's a way to cut through the bullshit specifically for software. It's a blurry metric but it is effective at removing a certain level of political bullshit.
For PMs you can't cut through the bullshit. Evaluation of the PM is directly through an API that is literally bullshit politics. The more charisma and the better you are playing politics the better you will be perceived at being a PM.
So what you get are a lot of shit PMs who are managing more politics than product. If the product doesn't do well, the PM is usually skilled enough in politics to redirect blame away from him. Both hiring for a PM and keeping a PM job is just a process of filtering for political skill.
A good example of a really good PM is Steve Jobs. But note his PM skill was orthogonal to actually keeping and holding the PM position. He got his own ass fired. He only came back because the company became desperate. This rarely happens in the real world where a fired PM will come back to his old job.
The problem here is that the skill involved with being a PM are equivalent to janitorial jobs. Anyone can do it. Anyone can have intuition on how they think a product should work. This is not a high skill job. The work itself is not easy, just unskilled. The person in this role has to spend ALOT of time diving into the purpose of the product and thinking of new features... etc. Anyone can do it but not a lot of people are WILLING to do it.
What makes this role hard to find good people for is that it's hard to quantitatively measure how willing a PM guy actually is. Instead we end up measuring the persons political skills. How good is that person at making you THINK he cares about the product? And that is the metric and bar you need to be good at to land the PM job. Politics is a hard skill. It's hard to measure and it's hard to train for.
What happens is we try to measure skills in one dimension but politics and charisma can cover it all up. People can bullshit their way past everything. That's why algorithm questions are so pervasive in the industry. It's a way to cut through the bullshit specifically for software. It's a blurry metric but it is effective at removing a certain level of political bullshit.
For PMs you can't cut through the bullshit. Evaluation of the PM is directly through an API that is literally bullshit politics. The more charisma and the better you are playing politics the better you will be perceived at being a PM.
So what you get are a lot of shit PMs who are managing more politics than product. If the product doesn't do well, the PM is usually skilled enough in politics to redirect blame away from him. Both hiring for a PM and keeping a PM job is just a process of filtering for political skill.
A good example of a really good PM is Steve Jobs. But note his PM skill was orthogonal to actually keeping and holding the PM position. He got his own ass fired. He only came back because the company became desperate. This rarely happens in the real world where a fired PM will come back to his old job.
The best products are made when a single highly competent person has complete control over the direction of the product. The problem is that's also how the worst products are made. Mediocre products are made through more democratic decision making processes.
If you think you can identity people with good taste, and incentive them properly to make the product better, and give them control to act on their taste, then you should do that. But you probably can't. One of the pieces is probably missing. Maybe you can't measure product quality very well. Or maybe you don't have good taste for people with good taste. Or maybe you don't have the authority to give someone control over the product.
The article gets at what I just called taste for good taste. It doesn't make sense to create a product manager role if you can't fill it with someone who has good taste concerning the product. Often, companies will get the PM roll wrong on multiple fronts: bad taste, and no ownership. At that point you've just hired on another voice adding noise to product discussions.
If you think you can identity people with good taste, and incentive them properly to make the product better, and give them control to act on their taste, then you should do that. But you probably can't. One of the pieces is probably missing. Maybe you can't measure product quality very well. Or maybe you don't have good taste for people with good taste. Or maybe you don't have the authority to give someone control over the product.
The article gets at what I just called taste for good taste. It doesn't make sense to create a product manager role if you can't fill it with someone who has good taste concerning the product. Often, companies will get the PM roll wrong on multiple fronts: bad taste, and no ownership. At that point you've just hired on another voice adding noise to product discussions.
A large proportion of software projects are internal systems which are not being delivered to external 3rd parties. Nor are they online products primarily for consumption by the public.
These are the systems that run the world in banking, finance, education, transportation, consumption, production, manufacturing and supply chain amongst others.
Stakeholders are internal and a Product Manager role really doesn't apply. I think it important to differentiate between types of software endeavor and much of the discussion here seems to view the software world and the need/role of a Product Manager narrowly.
These are the systems that run the world in banking, finance, education, transportation, consumption, production, manufacturing and supply chain amongst others.
Stakeholders are internal and a Product Manager role really doesn't apply. I think it important to differentiate between types of software endeavor and much of the discussion here seems to view the software world and the need/role of a Product Manager narrowly.
This article boils down to "if you hire mediocre people then you get mediocre results". This is true for all disciplines. But, the biggest problem here is not poor product managers (although that often is a problem) but poor-FIT product managers. Anyone hiring a career Google or Amazon PM to manage products at an early-stage, sales-led B2B supply chain startup is almost certainly committing hiring malpractice. That's not to say that the PM isn't any good, or can't adapt, but I wouldn't trust the hirer to make a good decision one little bit.
Problems with PMs generally boil down to "they're not very technical" (mostly irrelevant, because there's much more to being a successful PM than being arbitrarily "technical"), "they're just a project manager"/"they're just a status update monkey", which does happen depressingly often. However, this "prod-ject manager" archetype is generally something imposed on the PM by a company that has no interest in having anyone do actual product management work. The "all metrics all the time" people do, of course, exist. There's a place for them in bigger companies that are primarily optimising what they've got, but they won't last 5 minutes at a lot of companies.
So much of what people criticise as bad product management (or, but extension, bad product managers) is actually a systemic lack of product management at all. Leaders hire the wrong type of people for a role they have no interest in supporting, with inevitable results. However, are we expecting that these same leaders are going to make A-grade hires in engineering? In my experience, the engineers who complain most about product managers are the ones that would benefit from (good) product management the most.
Problems with PMs generally boil down to "they're not very technical" (mostly irrelevant, because there's much more to being a successful PM than being arbitrarily "technical"), "they're just a project manager"/"they're just a status update monkey", which does happen depressingly often. However, this "prod-ject manager" archetype is generally something imposed on the PM by a company that has no interest in having anyone do actual product management work. The "all metrics all the time" people do, of course, exist. There's a place for them in bigger companies that are primarily optimising what they've got, but they won't last 5 minutes at a lot of companies.
So much of what people criticise as bad product management (or, but extension, bad product managers) is actually a systemic lack of product management at all. Leaders hire the wrong type of people for a role they have no interest in supporting, with inevitable results. However, are we expecting that these same leaders are going to make A-grade hires in engineering? In my experience, the engineers who complain most about product managers are the ones that would benefit from (good) product management the most.
The writing of this article is a mistake. I don't have anything terribly new to add above and beyond what others have already said, but suffice to say this is a bad article that provides us no insight or meaningful suggestions and demonstrates a lack of experience and understanding throughout the industry.
There is a function many (though not all) software teams need whereby someone understands customer needs, prioritizes them, and translates them into something that can be worked on by developers. We call that role "Product Manager". Do you strictly need an MBA who has some specific certifications to do that? No, of course not. A very strong UX researcher could potentially do it. A very strong engineering lead could potentially do it. But for many products, it requires a significant time investment in understanding the problem space, guiding a UX/UI research/design team iterating through solutions, and documenting it in such a way that a dev team could approach it.
As someone else commented, the article is just "Hiring bad leaders is bad".
There is a function many (though not all) software teams need whereby someone understands customer needs, prioritizes them, and translates them into something that can be worked on by developers. We call that role "Product Manager". Do you strictly need an MBA who has some specific certifications to do that? No, of course not. A very strong UX researcher could potentially do it. A very strong engineering lead could potentially do it. But for many products, it requires a significant time investment in understanding the problem space, guiding a UX/UI research/design team iterating through solutions, and documenting it in such a way that a dev team could approach it.
As someone else commented, the article is just "Hiring bad leaders is bad".
I'm a PM and am always interested to understand how I can get better at my craft and support my team better. I grabbed the comments of this thread and ran it through claude.ai to do some sentiment analysis and identify the key themes of the negative and neutral posts. Here is the response;
----------------------------------------------------
Based on sentiment analysis of the comments:
- Go beyond surface-level feature requests and dig into the root problems customers are facing. Observe real customer workflows and pain points. Identify the jobs-to-be-done and where the product is failing users.
- Collaborate closely with designers and engineers early in the process. Avoid tossing requirements over the wall. Co-design potential solutions and conduct design sprints together.
- Develop enough technical literacy to understand architectural constraints, make feasible suggestions, and earn engineers' respect. Take coding courses, read engineering blogs, attend tech talks.
- Focus on high-level goals and strategy rather than tactical execution. Don't micromanage - empower teams to determine solutions.
- Avoid reactive mode and spending all time in meetings. Block off strategic thinking time and deep work.
- Learn enough about data and analytics to identify leading indicators and qualitative insights. Don't just fixate on vanity metrics.
- Interview users, customers and frontline employees to build empathy and an outside-in perspective. Immerse yourself in the customer experience.
- Prioritize ruthlessly. Challenge teams to focus on true differentiators versus commodity features. Relentlessly cut scope.
- Focus on business impact and outcomes over outputs. Tie roadmap to company OKRs and strategy.
- Simplify and streamline processes that don't clearly add value. Remove unnecessary bureaucracy but maintain just enough process.
- Build relationships and credibility with engineering managers and team leads. Avoid throwing weight around.
- Develop storytelling and communication skills to paint a compelling vision and explain rationale.
The key is focusing obsessively on customers, leaning into strategy over execution, and enabling teams versus controlling them. PMs create the most value through vision, prioritization and strategic clarity.
----------------------------------------------------
Based on sentiment analysis of the comments:
37% have overall positive sentiment towards product managers
28% have overall negative sentiment
35% are neutral
- Go beyond surface-level feature requests and dig into the root problems customers are facing. Observe real customer workflows and pain points. Identify the jobs-to-be-done and where the product is failing users.
- Collaborate closely with designers and engineers early in the process. Avoid tossing requirements over the wall. Co-design potential solutions and conduct design sprints together.
- Develop enough technical literacy to understand architectural constraints, make feasible suggestions, and earn engineers' respect. Take coding courses, read engineering blogs, attend tech talks.
- Focus on high-level goals and strategy rather than tactical execution. Don't micromanage - empower teams to determine solutions.
- Avoid reactive mode and spending all time in meetings. Block off strategic thinking time and deep work.
- Learn enough about data and analytics to identify leading indicators and qualitative insights. Don't just fixate on vanity metrics.
- Interview users, customers and frontline employees to build empathy and an outside-in perspective. Immerse yourself in the customer experience.
- Prioritize ruthlessly. Challenge teams to focus on true differentiators versus commodity features. Relentlessly cut scope.
- Focus on business impact and outcomes over outputs. Tie roadmap to company OKRs and strategy.
- Simplify and streamline processes that don't clearly add value. Remove unnecessary bureaucracy but maintain just enough process.
- Build relationships and credibility with engineering managers and team leads. Avoid throwing weight around.
- Develop storytelling and communication skills to paint a compelling vision and explain rationale.
The key is focusing obsessively on customers, leaning into strategy over execution, and enabling teams versus controlling them. PMs create the most value through vision, prioritization and strategic clarity.
I've been struggling with how to hack someones WhatsApp messages without touching their cell phone for almost a year. I've tried at least 10 different apps and none of them worked. I found remotespywise @gmail com after reading a blog post on how to hack someones WhatsApp messages without touching their cell phone and the reviews were all good so I thought I would give it a try
And the alternative is, "hire good people but not with the PM role"?
It reads like someone had a bad experience with a PM who thought they were Steve Jobs. PMs are just ordinary people, I don't understand this supposition that anyone holding the title is going be an entitled douchbag. An org can have thousands of PMs, each with a superior.
Just a weird article