> 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.
> 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.
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 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.
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.
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.
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.
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.
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.
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.
> 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.
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'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 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.
> 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
> 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.
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.
> 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.
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
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.
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.
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.
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").
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".
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 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.
>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.
> 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.
> 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 ;)
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.
> 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.
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
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.
> 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
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.
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."
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.
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.
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.
Want to corroborate, been through several companies and several PMs. The excellent ones are rare, and have disproportionate impact in the team's performance.
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.
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.
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.
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'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.
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 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.
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.
What a weird article. A whole lot of words to say, "hiring low performers will hurt your company"?
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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 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.
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.
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. 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
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.
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.
> 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
Readit News
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.
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.
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.
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.
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.
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.
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.
The problems you describe are legit but unless you have extremely technical product managers, hiring more PMs will only make the problem worse.
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 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.
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.
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.
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
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.
A decade+ of low-interest-rate fueled growth in the tech sector has meant a lot of us have succeeded just by showing up.
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.
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.
Deleted Comment
I operate as principle on a project, and I have opinions, but I cannot set the roadmap alone
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.
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").
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".
Deleted Comment
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.
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.
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.
I’ve never met a PM that did any of that either ;)
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.
Now program managers, it remains to be seen where their value comes from and I hope it does
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.
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
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.
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.
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."
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.
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.
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.
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.
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.
The author has, apparently, decided to skip the intermediate step and just rename things for no reason.
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.
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.
“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.
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.
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
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.
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....
Dead Comment
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.
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
Agree 100%, but this is where I've seen a lot of organizations fail, especially large ones.
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.
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?
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.
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.
Deleted Comment
> Tremendous people envision alternative realities, fully commit themselves to their work, and move mountains with their willpower.
The last part is so reductive. It's not willpower moving mountains. It's the underlings actually making the vision come to pass. At most the "great person" is aligning the incentives to motivate the actual doers and experts.
My feelings so far are mixed. I've worked in PM-heavy organizations before and I agree that those suck. But at the end of the day there is some work that a PM would do that still needs to be done. In my org that responsibility officially falls into Software Managers and Senior+ Developers.
For example, if you are leading an initiative for your team as a Senior Engineer, you are in charge of doing all the activities that a PM would otherwise do. For other activities, the Manager or Senior Manager of the team is in charge.
Suffice to say that as a developer this sucks. Not only you need to deliver your own work as an IC, but you need to coordinate other people and ensure that things get done. Not only this is extra work, but let's be honest, many developers don't have the skills to be effective PMs. It also makes inter-team collaboration difficult, since now you have to coordinate people that don't share a reporting structure with you.
Often this approach results in lack of ownership, lack of accountability, duplicated efforts or things falling between the cracks, and general disorganization. That being said, it tends to work well for small intra team initiatives involving a few people, since it removes the overhead of a PM and places control in the hands of builders. But for larger initiative, I'm not quite convinced it works.
> 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