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.
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.
A bigger population just hasn't been trained properly. We have no controls for that, so people get lucky with disparate learning being just enough for their first job, then that turns into experience towards the next job.
Then they find themselves among high performers and can't keep up, really through no fault of their own.
Some high performers are just natural and born with it, which is unfair to let that affect how anyone judges others' performance, but it still happens too (esp. if the high performer is doing the judgment).
What I generally see when people categorize their workers into high/low performance is from a bigger issue of poor stewardship over the industry and training its talent.
This means I don't actually have to improve, I can instead just spam job applications and get lucky just because technology is such a large industry.
> A bigger population just hasn't been trained properly. We have no controls for that, so people get lucky with disparate learning being just enough for their first job, then that turns into experience towards the next job.
I agree, but I am also hesitant to advocate for controls in the form of certification (degrees, licenses, etc) because it just adds a layer that provides a strong positive signal for a while until it’s just inundated by grifters yet again, so now we’re back to square one.
We see this take the form of degree mills and accelerated trade schools initially, which ends up creating more problems, more barriers, and ceases to benefit the companies looking to hire. Everything can and will be gamified, and I am also hesitant to tie people to former employers so heavily as that creates an unhealthy power imbalance.
Then how can we control for talent? I don’t know the answer to this question or if it’s even the right question to ask, but I’m fairly confident that we cannot solve this using 20th century nor modern hiring and screening processes.
> 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.
It's a fairly harsh take, as a whole, but there's parts of this that absolutely ring true. Once you get that "product org" in a company, it tends to progress the way the author describes, with committees and OKRs and review cycles and planning and a lot of bureaucracy.
I took, naively, a product manager job at one place I worked, thinking it would finally give me formal control over the product that I'd been previously asserting through influence - very successfully - in my client-facing sales engineering role. Of course as soon as I got in the chair I discovered it was a highly-constrained clerical job that I was completely unsuited to. Managing tickets and a backlog; coordinating decisions instead of making them; writing interminable powerpoint reports; the most creative thing was putting together a process for the company to follow in formalizing its product roadmaps. I lasted six months before running away.
The function is quite useful in supplying some visibility into what's getting built and in managing conflicting priorities for a growing product, but one thing it is not is shaping or controlling the evolution of the product in any way. It's a sorting, filtering, and (if you're lucky) a data collection function, producing an auditable decision trail and an impression of maturity in decision making which helps the MBAs higher up sleep a little easier.
I 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
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.
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?
Is that not a straight up engineering job? A good chunk of "engineer school" is practicing "customer has an issue, design a solution" type problems, in-between all the math.
Customers are rarely able to express their underlying issue. They usually communicate what they think the solution is.
A good product person is able to drill down to the fundamental problem the customer really has and articulate that to engineers.
Also, good product people should be evaluating the customers problem in terms of the whole market.
After all, engineering is a limited resource. So you need to solve the problems that exist for your target market, not just a single customer.
Of course, I’ve seen good engineers who can do this, but it takes time and effort to sift through all of the customers issues and work out which ones to solve. So product managers are focused on this to free up the good engineers to design solutions to those problems.
>Customers are rarely able to express their underlying issue. They usually communicate what they think the solution is.
In my experience the vast majority of PMs do exactly this. Half of my job since I became a staff+ engineer almost a decade ago is taking “solutions” from product managers and trying to figure out what they really want.
Good Product people don't just build exactly what the customer described as their problem. They understand that sometimes there's a better way to solve it. In "engineering school", you can't tell your professor "I understand what you're actually trying to achieve, so I built X instead of Y because I think it'll be better for you".
Product figures out what to build, and Engineering figures out how.
Sure you can. I’ve literally had classes that worked exactly like that. I had classes where I had to interview and observe actual customers using our product.
What you’re describing is a huge part of engineering. Engineers have been doing this long before Product Managers existed. When I started, software engineers used to just talk directly to customers, domain experts, business analysts, and business leaders.
At “product led companies” the engineers just end up trying to figure out what the product manager actually wants because it’s not really possible in most cases to separate the what from the how.
Having worked with both systems, I don’t think the way it works now is better.
A lot of traditional engineering (civil, mechanical, etc) are non-competitive endeavors. For example, if you are supposed to make a bridge, you just design what you think a good bridge to be.
In the modern consumer application, you have to understand business concepts like differentiation. If your product is very good, but it’s strictly worse than another product in every dimension, you don’t get any credit for second place. You actually get close to zero sales because no consumer chooses your product over the alternative, in contrast to a “bad” product that does at least something very well in a niche.
Clearly there’s a difference between building a bridge and getting customers to use your free app, but the vast majority of Engineers aren’t working in big infrastructure projects. Even the ones who do are competing with everyone else who bids on the project.
And in software there are plenty of cases where the 2nd or 3rd place product gets tons of sales even if it’s strictly worse in every category. There are so many things that impact market success that are completely out of the hands of product or engineering.
This doesn’t sound like any university CS degree I know of, apart from maybe a single class actually called “software engineering”, which in many cases isn’t even required
And even if it was, no, engineer personalities are horrible at designing solutions that actually meet customers’ and the business’s needs
The engineering classes I took were full of stories and problems centered around solving erroneous customer reports. A good example is the ice cream story [0], where a customer reports their car malfunctioning when they buy the wrong kind of ice cream, which was used as an introduction to root causing techniques. That specific story is apocryphal and the manufacturer varies, but there's an entire mythology of such stories being used to introduce topics / provide "realistic" problems / do design projects for students.
This sort of stuff is a not-insignificant portion of my job as well, since PMs rarely have the technical skills to know what's feasible as a solution anyway in my experience.
My experience was B2B. I was certainly expecting a lot more of the problem identification and solution generation work that you described.
The difficulty was that the owners at the top had unshakeable ideas about what the product should be. That's ok, single minded vision can be good and all that. In my very hands-on sales engineering role I'd make things that my prospects were asking for, put them in the product, they'd buy it, and my prototypes and hacks and tools would end up getting refined, hardened, and supported by the implementation team. It worked well because everything I did had big dollars attached to it (so the org itself didn't mind) and the product advanced in a way that the market wanted.
The problems arose when we put in the product management process - the whole committee/requirement/signoff thing the article describes and I mentioned in my earlier comment. That created a formal bureaucratic mechanism for various players to stop all the ideas I had. Before, they'd be fait accomplis necessary for winning a big deal. Now they were just ideas divorced from value from some guy who should've known his place. Back then I was hopeless at understanding how to get a group of people with different agendas to agree on something (I think it's called 'politics').
> if you were simply ordering an existing backlog, who was defining the new items to add to the backlog?
It's over 15 years ago but what I remember is that there were thousands of semi-structured documents which represented things that, with the new product org, got turned into backlog items (stories, epics). This was part of an attempt to move engineering to a more agile way of working while creating a product function to support it. So it's more that we didn't have a backlog as such, then we stood it up and triaged everything we already had into it. All this was happening while the company was trying to learn about agile. I remember day long meetings where we all tried to argue about whether technical tasks belonged on a backlog, and if not how you could write a user story for remediating a piece of technical debt. Basic stuff but none of us had a clue.
>The problems arose when we put in the product management process - the whole committee/requirement/signoff thing the article describes and I mentioned in my earlier comment. That created a formal bureaucratic mechanism for various players to stop all the ideas I had. Before, they'd be fait accomplis necessary for winning a big deal. Now they were just ideas divorced from value from some guy who should've known his place.
precisely, the introduction of a PM means that the people who actually implement the product are put below pure talkers. You suddenly go from being able to influence the product daily to everything being up for a vote and every vote being overriden by the PM. The PM gets to decide which issues are important enough to be included even though he really doesn't know better 99.9% of the time. 99.9% of the time he didn't talk to customers about it, he just has his own opinion and was put into this artificial leadership position that ruins the fun of the job for everyone else. Oh sure he talked to leadership but that ends up being about how to achieve his own dreams and goals, certainly not to help make the ideas of engineers a reality. I've literally never seen a PM that goes and asks what ideas of the engineers we can help make reality. Just let that sink in for a moment: Isn't that what a product is? Ideas of engineers? I mean it really is. The whole agile movement is one of the strangest gaslighting ventures that human psychology has ever produced. We are told that there is no boss while actively being micro managed issue by issue, hour by hour almost, while literally being asked every single day in the standup when X will be finished.
I am living the reality described by the article. The PM role has too much power and too little accountability if things go south. The usual scrape goats are sales, then engineering and support.
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.
> 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.
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.
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 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").
> 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.
And ironically it seem like the things you'd positively attribute here to a product manager used to be/are actually part of the scope of what was traditionally a "project manager" or "program manager."
For example, look at the scope and definition of a "program manager" from Microsoft or the US DoD in the 1980s, 1990s+, as well as literature describing the role of a program manager and the discipline from that time.
Why’s that ironic? There didn’t used to be frontend / backend / full stack devs either. As software engineering has matured and grown in scale, more subdivision of responsibilities is a natural outcome of that. We’re not all just directly writing code on mainframes and our customers aren’t just < 1k of users who directly call us on the phone if something goes wrong anymore, it’s millions of people using services 24x7
now. MS wasn’t making real-time collaboration systems and cloud sync in the 80s and 90s. They were making a stand-alone offline machine that barely could install device drivers and didn’t know what the internet was. Completely different products, and much simpler.
What subdivision of responsibilities? Clients and servers were divided for as long as clients and servers existed. Full stack is aggregation of responsibilities. DevOps too. Dedicated QA is rare now.
Most companies with product managers have fewer customers and less complex products than 1990s Microsoft.
Yep, a common pitfall is to not understand how product managers are supposed to do, and thus they just do project management, which often has neutral or negative value.
Sometimes you need a formal project. We’re kitting out a new office over the next couple of years, it’s a major programme of multiple projects, all which interact. At the end of it though we have a building fit for purposes following the plans currently set. I’m sure those plans will adjust a little, but the end date is January 2025, or July, or something - I’m sure the date will slip.
You can’t build a £20m facility with a series of sprints.
Well, the Empire State Building was famously built as a series of sprints...
You need a formal design. This doesn't mean you need a formal project. Some amount of planning ahead very obviously helps, but how much is debatable, and when you have people whose sole specialization is "planning ahead", you are certainly past the point where it's too much.
Anyway, the most valuable people are the ones "planning behind", looking for what was left broken and could be done better from now on. Project management defines those people out of existence.
Think of the "formal project" is the API by which executing the design can be understood by all stakeholders.
It is a high level abstraction that allows all parties to understand what they need to do and when they need to do it. For large projects it is simply essential - you need your external vendors to plan their availability, months or sometimes years in ahead, so that they can commit to the timeline.
If you're lucky enough to work on large software projects where there are no managers or other stakeholders asking "and how long will this take, exactly?" then maybe the design is enough.
But pretending planning ahead on large projects that is something that will just happen by osmosis or people "just doing it" simply won't work. Good project managers who do what they're supposed to are worth their weight in gold (just like good product managers).
> If you're lucky enough to work on large software projects where there are no managers or other stakeholders asking "and how long will this take, exactly?" then maybe the design is enough.
How well can your project managers answer how long will this take? Because on my experience, 10000% delays are all but routine (ok, on construction it's usually bounded to something around 1000%). And how much value do people that can give you an estimate between 1% and 10000% of the target?
> But pretending planning ahead on large projects that is something that will just happen by osmosis
I'm telling you that planning ahead has a small value, following up with the plan has a high negative value, and the thing with a high positive value that is reexamining the plan is fought against by the practitioners.
If they are good project managers, they plan for non-routine delays and account for them in the project schedule. Before people are allowed to commit to schedule, the project managers make sure that these people have properly scoped and estimated their part of the work, by asking pointed questions, using their domain expertise and general experience to figure out if they're being bullshitted or not.
If things start to slip, they find out where and why and apply what pressure they can to get them on track. If they cannot get them on track, they then liaise with everyone downstream to make them aware of the slippage, adjust the entire schedule, and get everyone reorganised.
It's not just putting things in the calendar and forgetting about them - it's a constant, ongoing herding of cats to get them all going the same way.
It sounds like you just might not have been lucky enough to work with really great project managers!
The vast majority of my colleagues would say "that person is a devops" instead of "that person does devops", which I don't get at all. I've assumed it's some deeply rooted misunderstanding of language (my colleagues are eastern european) that has taken hold across the entire local industry.
Last time I saw one of these types of articles on here it quickly became apparent that a lot of companies don't know the difference and call their project managers by the wrong name.
This adds to the confusion since Project Management Professional is a certification for a Project Manager that specifically uses that acronym and not all project managers have the certification.
For what it's worth, I enjoyed that joke. I work in education and the number of redundant acronyms and initialisms (if that's a word) is astounding.
BIT meeting on my calendar. Is it behavioral intervention team or something about the bachelor of information technology or Business Information technology or bachelor of industrial technology or are we talking about income taxes or what?
A lot of teams with poor business operations seem to treat project, product, and program management as a generic blob of “help us be organized please” duties instead of specific jobs with specific operational missions.
What is the difference then, between a project manager, product manager, a project owner and a product owner? Always thought they're approximately the same thing. Isn't any product you're working on a project too?
The main difference is between a product and a project. The gist is that projects are short term specific plans while products are a bit more open-ended ideas with continual feedback. Here’s a decent overview: https://martinfowler.com/articles/products-over-projects.htm...
Product Manager: They are essentially the voice of the customer and upper management. They work on the product roadmap and determine the requirements for the product based on the needs that are determined by conversations with the stakeholders as well as other market research. In addition to this they also work on things like product pricing, release strategy, etc.
Project Manager: They ensure that all the tasks for a project get done on time. They make the gantt charts, work with teams to break it down into sections, keep track of budgets, manage risks, report on progress to stakeholders, etc.
I've never worked with a Product Owner since I understand it is mostly a software related position and that is not my area. From what I understand, they are an intermediary that sits between PdM and PjM.
> in charge of planing, execution and governance of a project. They don’t define any of the goals or vision.
This sounds like if you were trying to hire a race-car driver instead hired two people, and put one of them in charge of steering to the left and the other in charge of steering to the right.
Project managers co-ordinate the teams and stakeholders associated with a project. It only applies to bigger companies. In smaller projects senior engineers and engineering managers do the same job.
There's sometimes also program managers who organize relevant projects across the company (for example with GDPR compliance a program manager might coordinate between legal and various products, identify risks and report progress to C-level, and each product will have a project kick off to get it into compliance (depending on the effort, the person overlooking this project and working with program might be a dedicated project manager, engineering manager, some engineer etc).
Most companies don’t understand what a product manager does, and they are busy eliminating project management roles in favor of an “agile” workflow, so they just repurpose the project managers to be product managers because it’s only two letters different. With predictable results.
Sounds like he fired a type of project manager - one who controlled the team. A project manager can manager the team by supporting them and unblocking them while doing non-implementation type work such as managing and reporting the project's budget, managing and reporting progress and delivery aims.
Google currently has program managers (and technical program managers). I could not tell you the difference between them and product or project managers.
It changes between companies. At my company the Product Owner is the one who maintains the relationship with customers. Product Managers are there for prioritizing the feature requests. We also have Project Managers for inter-project dependency tracking and Engineering Managers for resource allocation and work output.
I think that’s the challenging part. A product manager is supposed to stuff holes in your team that no one else currently does. Do you have a strong TL with a good product sense? Then the PM should probably spend their time talking to customers, and not interfere with the engineering team so much.
Do you have a good UX team, but the engineering team is just a bit too big to be comfortable? Then the PM should work with the team to streamline communications and processes.
The hard part about this is that on the one hand, you need a PM that is experienced enough that they can set up processes and be disciplined enough to make sure they are followed. On the other hand, you need a PM that is able to embrace the chaos on aspects of the teams organization where it is beneficial for the team. Oh, and also they should be a domain expert, if possible. Know SQL. Know how to talk to management. Etc.
I think if you have a good one, it is a strong force multiplier for the team. If you have a bad one, it is a force subtractor.
And it is extremely difficult to tell beforehand (or even while they are actually working in that team!) which kind of PM you have. It’s one of those roles that, if it’s done perfectly, people won’t be sure whether you have done anything at all.
But I agree with the premise that there are probably too many bad ones in circulation right now.
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.
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.
> My experience with product managers is that they wedge themselves between the business and the technical teams and then wield political power while doing very little.
There's a large number of companies where the company is the one wedging the PMs there.
My view is that a PMs job should include (but not be limited to) diplomacy, negotiation and facilitation. But if your heart isn't in that (and it can be easy to become disheartened), then it easily becomes "politics", and the worst parts of politics, at that.
I wonder if part of the gap here is about whether a company is B2B or B2C. In my experience at a largely B2B company, the product managers are people that aren't necessarily technical, but have experience in the relevant domain and meet with customers to find out what they need and coordinate launches etc., with them.
I don't know if the same role makes as much sense at a B2C company, so maybe people are B2Bs see their value and people at B2C companies don't as much?
I've seen shops hire product managers for INTERNAL customer facing apps, and then have the PMs basically not talk to those customers. They did instead talk extensively to product & tech management as well as the c-suite.
So tech people (even IC non-leads) end up on weekly calls with various internal stakeholders that the PM can't make (literally this is your job dude) and take the brunt of all the feedback/relationship management/etc with the trickier ones.
The worst was when he said he would take the weekly calls with Asia users but wanted to pre-meet with me first and ask I ride along with the weekly user call for a while. So we would pre-meet and then he would ghost on the user call so I end up having two calls instead of one.
Just cargo cult CTOs reading too many books and not actually looking at the evidence in front of their eyes.
Same experience, but I have one hypothesis: in B2C the “client” after some point become some abstract entity where people ship code/product to. A great PM can talk with those masses and extract exactly what needs to be done. This is a very hard skill.
In B2C the customer is way clearer and the relationship is everything and it’s quite hard a bad professional hide for long.
My experience with B2B PMs is that exactly one that I've worked with was amazing and the rest were just an awful intermediary that added a day of latency to any communication with our contact at customers and often managed to mangle things too.
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.
I agree. Have the product team facilitate communications between customers and engineers and guide efforts towards development that has the biggest returns. Sadly I don’t really ever see it functioning that way anymore.
> Talking to users has always been on my list of things required for engineers.
For any product of reasonable complexity, taking to users is something a PM should be spending ~1.5 days/wk on. Plus overseeing quantitative user research.
If your engineers are all spending that kind of time on users, that's slowing down the amount of time writing software by a huge amount.
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
If all you want is someone to do team-level project management toil, a line manager can do that (or hire them a part time assistant if they don't want to and you don't want to invest in better automation). This is not a whole career-level job.
I get the feeling you don't work on massively complex projects.
We have loads of project managers where I work and I thank my stars we have every one of them. The coordination and planning required is ferocious for the work we need to deliver. It is not trivial and it would quickly fall apart without them.
Some of what you described in the comment I replied to fits the description of complicated company-spanning project management - a valuable role I have typically seen referred to as "program management" - but some of it, the team level dealing-with-task-backlogs type stuff, are things that managers and team members can just do in the course of their work.
But you're right that my comment focused only on the latter thing and ignored the former one.
But setting that aside, there is certainly a personality thing at play here. If I worked where you work, I would probably be more skeptical of the value of all the time being put into project management, and if you worked at my favorite companies that I've worked at, you would probably feel like it's a poorly managed mess (I've had lots of coworkers who felt that way!).
To some extent different folks just like different strokes, and that's one of the things that makes it really hard to do things that require lots of people to pull in the same direction.
There is certainly a distinction between teams just dealing with their task backlog and project management. I wouldn't waste a project manager on that.
Program management is a level above project management as you say, coordinating multiple projects. But there is definitely a space for complex single projects (not programs) that still require detailed planning and coordination.
It's not really about personal preference though, unless this issue is a show stopper for you in terms of where you work. I've worked in both informal and formal settings. I personally dislike heavyweight project management processes but they are sometimes required!
Yeah I was thinking last night that my comments here were a lot more strident about this than I am in real life. I agree with your whole comment, except I think the middle ground between team-level management and program management is more often better served by tooling, architecture, requirements, or team structure changes rather than project management.
(I get it, sometimes the need for a lot of planning is imposed from the top, like if you sign a contract with an immovable delivery date, but I think most organizations should do whatever they can to avoid doing that, in order to enable them to structure projects flexibly and have small mostly-autonomous teams.)
I think the personality thing is important both in terms of contentment with your work (and thus which organizations and projects you choose) and in terms of how you analyze the relative value of things when evaluating trade-offs between the different things an organization can invest its time and resources on.
Yep! I think, somewhat humorously for how this thread started - which was entirely mea culpa! - our perspectives on this are pretty closely aligned.
One thing I think is that a lot (though not all!) of the requirements imposed in heavily-regulated industries are actively counter-productive, because they more effectively introduce friction on positive changes than risky ones. But it's basically impossible to strike the exact right balance between mitigating tail risks, which is critical, vs. introducing counter-productive friction. So I have sympathy, I just also find it very frustrating to work in such environments.
Yeah, we aren't too far apart! It's why I like HN, you can actually have a civilised conversation :)
Friction certainly makes it harder to introduce positive change. I don't think it makes it easier to make riskier ones though, but you often can't do everything you'd like to get done.
Just to clarify, I didn't mean regulatory friction makes it easier to do things that are risky. I think regulation is pretty much entirely successful at making that harder. What I meant is that, in my view, regulations that reduce the chance of tail risks by let's say X% often seem to increase the friction on making improvements by more like say 2X%. Of course this isn't scientific or anything, but it's my intuition, that the trade-off doesn't seem to be 1:1 when you take on some friction to reduce the likelihood of some tail risk.
Eh, in my current role (engineer) we have a PM but they’re not all that useful. In theory, they do what you describe, but because they don’t have a technical background they struggle to identify blockers & engineers drive most prioritisation sessions.
They may jump in occasionally to tell us another team needs X or the business wants to see more Y so we should re-think what we work on next, but I struggle to see why that couldn’t be handled by our technical team lead.
> 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.
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.
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.
Project managers usually don't need to know as much as product managers, or be as thoughtful as them to be a great value add. Project managers have a larger range of "acceptable" performance to be able to add value, so their job certainly is easier.
Perhaps it was inelegantly put by the original commenter, but I think the gist is that the product managers who lack some of the important product management skills around vision, ability to be customer facing, and effective and articulate communications tend to work more like project managers—effective acting as tactical managers within a product as opposed to strategic ones for the product.
We can define and name the roles all sorts of things (project manager, product owner, product manager, product marketing manager), but what it boils to is for any complex product there is a need for the management of the product at a holistic level and a need for management of a product at a granular level.
I wasn’t writing a treatise on every occupation and was being a little jocular.
What I’ve witnessed over a 20 year career is that weak product people devolve to mediocre project managers. It’s easier to be a shitty project manager.
Good project managers are gold. I worked with one who stood out a decade ago - his leadership at execution was such that a $350M, 20 month implementation, with collaboration with construction, tech, and external suppliers completed 45 minutes ahead of the original schedule. He’s since retired and passed away, but an inspirational leader I was privileged to get to know. Ponder that - how many project managers are acknowledged as leaders?
> his leadership at execution was such that a $350M, 20 month implementation, with collaboration with construction, tech, and external suppliers completed 45 minutes ahead of the original schedule
This made me smile. I'm assuming you mean 45 days or something. Not that any number 'ahead of schedule' is inherently a bad thing (within reason), but my mind went to "Are there really companies out there tracking 2 year projects and counting the minutes?" (and sadly, there probably are).
It's a little tongue in cheek. There were completion incentives around certain tasks, especially on the construction and physical side, being completed on a date. Date was defined as 4PM on the date, and there was a financial benefit to be early in many cases. The last physical task required to be completed and submitted was done at 3:15, thus "45 minutes early".
That said, some major elements were tracked to the minute. I wish I could share more, it's a great story!
> When this role is dumped into engineering, engineering management or general management, it weakens the engineering practice. If I need engineers, I need to select for that ability and frankly shield them from people on the outside. If the org requires that my teams handle interaction, now I'm hiring people with mixed skillsets in one org, which inevitably waters down the engineering side.
I'd argue that the position taken above weakens the engineering practice. Understanding requirements (e.g. constraints) is a core element of engineering, engineering management, and general management. Part of the problem plaguing the tech industry is the "dumping" of this responsibility, and others such as "project management" into some other role. What some like to call a "specialization" may also be called an abdication of responsibilities and ultimately accountability.
In my opinion, the essence of engineering is the methodical art and practice of solving problems. A fundamental part of engineering is understanding the problem(s) to be solved, the constraints, as well as the trade space and trade offs of solutions for those problems.
Not all aspects of (engineering) problems are "technical" in nature, and a failure to understand this and cultivate this understanding weakens the engineering practice.
> I'd argue that the position taken above weakens the engineering practice. Understanding requirements (e.g. constraints) is a core element of engineering, engineering management, and general management.
Determination, evaluation, and articulation of requirements is the sweet spot of the product manager role. Understanding those requirements is certainly necessary for an engineer to build to the requirements.
An engineer's understanding of requirements entails determination, evaluation, and articulation of those requirements. Calling oneself an engineer doesn't preclude their ability to do these things, and force them to call themselves a "product manager" for doing so. And quite often, especially at more senior levels, an engineer must do these things.
Once upon a time, this too was a formalized practice in engineering that people called "Systems Engineering":
I don’t know about as a percent of total hires, because staff+ engineers tend to stick around a bit longer. But in my current bigco it’s a bit north of 10% and I’ve seen it go as high as 20%.
It does, but it's still not something engineers do well.
Imagine developing an AAA game with no one in charge of the overall product. Or creating a movie without a producer or a director, expecting the talent to somehow organise itself.
PM isn't an engineering job, it's a vision job - one that needs enough technical knowledge to create a vision that's grounded in reality, while also appealing to customers, while also being able to sell it up and down the org.
Separating product from engineering, engineering management, and general management does not mean 1 person is in charge. Integrating them does not mean no one is.
The article was all about the consequences of the skill set being incredibly rare.
That was well put. Imagine that. Still we train our product managers to follow checklists, write endless documents about personas, have discussions about methodology and such things only loosely connected to the work that goes into making the actual product.
Imagine if a director was a bureaucrat. One who followed checklists and made policy documents, and did not have the slightest clue about the actual craft of setting lights, working the camera, and acting.
What's our profession's equivalent of a film director? One with deep knowledge about data structures, who cared about getting it right, together with professionals?
Hardly. Scrum master is more like a production assistant. Make sure everyone knows when and where they are supposed to be. Communicate any issues with the plan
Good engineers work to deeply understand the problem given to them. They understand the different possible solutions, and implement the best one they can, given their constraints.
Good product managers identify the problems to be solved, and prioritize which ones should be solved first.
> 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
PMs at most companies DO NOT play politics for resource management, the stakeholders are frequently just other departments within the company so there isn’t a lot of maintaining client relationships. TPMs with sales people are generally the ones that maintain relationships with clients. PMs do very little besides put out a high level requirement document that then truly gets fleshed out by the engineering team and the EMs.
Every thing you just said rings true. I went from 20 years engineering into engineering management, and took my first PM role last year. I took the role at a twenty year-old software company that's never had good product management, and the place is horrible.
Over and over, the staff were pounded with "we are an engineering first company." Well, that means the engineering teams were allowed to do whatever the hell they wanted and chase the shiny newest techs. There's 3.5 main products (really 4.5) each made from a different tech stack. There's another eight or so legacy products we have to support due to legacy demands. There's no inter-operability of standardization between products. Basically, there's no knowledge transfer, so the cost of development is through the roof.
Twice this year, I had to explain to 20 year-tenure engineers that don't understand why it's a bad thing that one API is TLS 1.3 only, another is 1.x, and another doesn't even require TLS.
Customers hate us. For my product, they literally wrote the marketing materials first, and let the engineers figure it out. One stage of my product takes Oracle data and puts it into parquet. The guys who did it did it in three different languages, two other DBs inbetween (MySQL AND PG), and was going to introduce Redis before I stopped the insanity. Everything is fragile and sucks.
Thankfully, PE took over two years ago and we now have an ultimatum to make money or else. We are a twenty year old company that has never made money (we've been a cost center).
Even if we don't meet it, I feel like the Universe will be better off without the travesties against software design that we created.
I do believe that the traditional PM role/background should be considered obsolete, especially in software companies. Well-rounded engineers should be in these roles these days.
> In my experience, the vast majority of PMs could not describe the difference between TLS 1.3 and 1.x.
Does the vast majority of PMs need to tell the difference between TLS 1.3 and 1.x?
I mean, is that a relevant aspect of the vast majority of products?
If not, why should a PM bother about irrelevant details?
One of the cardinal sins of proponents of this "engineers should rule everything" mentality is failing to tell apart the critical factors from the irrelevant details, and conflate not caring about obscure implementation details with incompetence. Except the cheekiest little fallacy in software development circles is that the purpose of all software projects is not correctness or code coverage or uptime or resilience. The purpose of each and every single software project is to serve their users' interests. That's the critical part of a project, and the thing that PMs focus on for the right reasons. Naturally, PMs prioritize work with the biggest impact. Does TLS trivia fit this requirement? No.
Generally it is quite important especially for SaaS. Old TLS will cause SOC2 cert, PCI cert failures and similar. It is the kind of thing that can derail a major deal as often the 'whale' clients are the ones that really care about security certs while smaller companies and startups don't.
Non-technical PMs tend to gloss over things like that as an engineering-driven feature. Clients don't ask for TLS 1.3 (at least until it's often too late) because they generally aren't considering TLS trivia until it comes time for their next audit.
> Generally it is quite important especially for SaaS.
You see, I don't think that's true at all. If it was, certainly you'd have clients complain loudly enough for the PMs to notice.
But that doesn't seem to even register a concern, both from the client and from the PM point of view.
Convenience is a nice-to-have, and fixing problems that don't exist registers even lower in the priority queue.
> Non-technical PMs tend to gloss over things like that (...)
See, this is where I think we disagree at a very basic level.
There is no such thing as a technical and non-technical Product Manager, because a product isn't technical. A product is something that meets the needs and expectations of its customers. A Product Manager's responsibility is to know their product and manage it to meet its clients' needs, and in the process help guide the development effort to maximize its returns on investment. Whether it's to paint a button red instead of blue, or to tell if they need to upgrade TLS, a PM's job is to read the room and deliver what meets the needs.
> If not, why should a PM bother about irrelevant details?
Because engineering failed to consider these details. Now I'm the one that has to point out how amateur we look when in some areas we don't require TLS and others we're so strict, we only have 1.3. Engineers (management or rank and file) who can't understand why this is a problem is exactly the reason you need technical PMs.
> Because engineering failed to consider these details.
I don't think you got the point. The point is that no one cares, or think it's important enough and much less critical to justify wasting time with it. Product Managers are there to create value, and spending time on things no one notices is not how you create value.
A good PM doesn't have to know the differences, but should understand that mixing encryption protocols is going to break things. Ideally an eng lead would be flagging these issues.
This certainly sounds like your company is having a gap. But the gap sounds to me more like the lack of technical leadership (a strong lead, principal engineer, etc) than a PM. 10 out of 10 PMs I worked with (and it had been more) wouldn't commend on software architecture and internals and wouldn't prevent the needless complexity and unmaintainability aspects. They can at most point out that feature development and bugfixes are too slow, and then its up to the engineering team to improve on this. But also for 10 out of 10 PMs feature development will always be too slow, since customers are asking for things being done yesterday, so this alone isn't a great indicator that engineering is broken.
APIs using different TLS versions falls into the same category. Unless the TLS version is part of the product (which is the case for e.g. API Gateways, webservers and proxies) PMs will likely not care. They should however care about the difference between no TLS at all and a "somewhat modern TLS", because "no security" is definitely an important gap in the product.
A lack of engineering leadership is certainly true. As is often told, the VP of engineering enjoyed creating PRs more than actually leading. There has never been an architect.
The point is though, product never challenged on approaches, and you’re right. They never came from technical backgrounds. Product managers were promoted from the BA ranks. They never raised technical questions like that - “Is it a bad thing if the customer has to connect this way for this API and another way for another API?” If the idea is that engineering asks those questions, I’d counter with that’s venturing squarely into product’s realm.
I don't claim greatness at modern product design/theory, but I'd expect "what version(s) of TLS are supported?" to be primarily an engineering responsibility (say 80-90%) versus a product concern (say 10-20%).
If TLS version support was materially affecting your client’s ability to integrate with your products’ APIs then the Product Manager should have picked this up and worked with the development team on a way to remove this friction.
I can think of a bunch of different ways of solving this that would take a few days to build out.
I don’t know if it applies to the situation the GP described, but profit != revenue.
It seems to me, especially in the wild and woolly mom-n-pop end of the market, that there might be ample room for a company to sustainably put food on a certain number of employees’ family tables without much left over to characterize as profit.
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.
well just remember that engineers do this to have portfolio pieces on their resume. they need validation from other people that they worked on a software stack, and to be able to do live interview assignments about that software stack.
this actually just another symptom of a really bad interviewing process where nobody can tell that you're a competent engineer unless you pigeon-hole yourself to one stack that might not always have jobs for it, or for very long. there is also pressure to work on the coolest software stacks, because maybe you will be a scarce resource for a few years and get a major premium in compensation on the fastest growing companies. the other symptom is that companies aren't doing training, they're allergic to it, so they only want engineers that have years of potentially verifiable experience working on the exact stack they have, so that engineer could "hit the ground running" despite needing to keep the job opening up for 6 months to find that person.
> I took the role at a twenty year-old software company that's never had good product management, and the place is horrible.
> Over and over, the staff were pounded with "we are an engineering first company." Well, that means the engineering teams were allowed to do whatever the hell they wanted and chase the shiny newest techs. There's 3.5 main products (really 4.5) each made from a different tech stack. There's another eight or so legacy products we have to support due to legacy demands. There's no inter-operability of standardization between products. Basically, there's no knowledge transfer, so the cost of development is through the roof.
I read this and thought you worked at my previous employer (household name in IT).
Engineering first company. Oof. This meant that as a PM, I got introduced to two of the products I'd be managing when Engineering and Architects had come up with a grand idea to build a component/subsystem to replace a previous one which had been over-engineered and never gained traction. They hadn't talked to any customers who used it, or that had liked the idea, but not the execution. They were just given a wide latitude to experiment (don't get me wrong, some experimentation and exploration is useful), got a greenlight for some time to prototype it, and did so.
And then, and only then, was I called in as a PM, and told, here's our prototype, here's some vague documentation of what we wanted to solve with this - "Now, Mr PM, can you shoehorn a Product Requirements Document around what we've already built and where we see it going, and can you do the Market Requirements Document to answer the questions we probably should have asked before getting this far?"
And then I would get catch-22s. Express doubt over the needed research and potential for the product and I was told by management that "PMs need to be passionate and fearless advocates for their products"... and then when I do try to eke something out, but lo and behold, our internal 'market', let alone customers are ambivalent about why we are working on a "v2" of this feature, when the market is either accepting the weaknesses of "v1" or have long built out their own solutions and moved on, and as a result we have a stakeholders meeting where we decide to end the experiment, and I'm chastised for "poor product management judgment" for not killing the project far earlier... the project I have no authority to kill, because it's an Engineering first company, and the project whose existence I learned of when it was tossed into my lap as a 90% complete prototype/proof of concept.
And then you have a few hundred (yep) Product Managers in our BU all trying to do their own thing, some empire-building, some truly product-focused... and it's a shit show.
I love being a product manager. I took a similar path as you... although most of my engineering background is SysAdmin/Devops/SRE/infrastructure and then management thereof. I love being a product manager, and thought that this role, at this company, would have untold potential and I could settle in, learn, grow, build from there. But it was everything from a Dilbert cartoon.
You can stil be engineering focused (whatever that means) and have strong leadership. The issue is that a person who lacks significant stake in the company (i.e. most) is not going to want to be a strong leader - you're just risking yourself as personally accountable for any failures vs. limited rewards.
> Very few engineers want to maintain relationships with customers, interview users to identify potential features, manage leadership, play politics for resource allocation, and so on.
I’ve never met a PM that did any of that either ;)
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.
It’s about responsibility, the PM is responsible for the success of a product. To achieve this he collaborates with all the parties you mention, but in the end the PM has the responsibility. Key in this is bringing together knowledge of the market, the competitors, the customer problems, the value of a solution to these customers, determining a roadmap that will lead towards a successful product, coordinate launch, service, support, and continuous monitoring of the state of the product (does it have the right features, what is the competition doing, what does sales need to effectively sell the product, etc).
Having one product owner is fine. The problem is that it should be a role someone moves into from one of the disciplines involved. Design, engineering, domain expert etc…
Now we have Product Manager orgs with Associate PMs, junior PMs, senior PMs, group PMs etc…
A junior PM almost by definition can’t be a product owner. They don’t have the seniority to make decisions, so what you end up with is a situation where senior PMs are handing down solutions to junior PMs who are coming up with even more detailed solutions to engineers. I’ve seen it time and again.
Product Owner and Product Manager is not the same, especially in a larger organizations. Product Managers usually dont manage sprint backlogs, as its too fine grained. I often see sprint backlog that contain 20+ stories that add up to 1 customer facing capability/feature.
Designers interview people, and potential features may come out of that. They don't put those potential features into a roadmap and allocate resources to them. I'm a designer: if it were up to me, I'd spend 99% of my time improving the UX of the product we have, because that's what I care about most. Somebody has to own the vision for the product with respect to the company's business goals, and individual designers and engineers are not the right people for that. Maybe I ought to have phrased that better originally.
> individual designers and engineers are not the right people for that
That kind of depends. The product-minded ones (who are naturally interested in the "producty" kind of work) are excellent people for that. So you may find that in some companies the people doing product work are either engineers or designers. I've often done that from the engineering side, and I've seen it done really excellently by UX designers too. In other companies you may have dedicated people.
In my experience, whether it works well or not is less a function of how the roles are divided and more a function of whether the individuals doing product work are good at product work (which is difficult to find, even when they are dedicated product specialists). I think I would probably argue that due to the nature of the job being a lot about connecting different functions of the business and synthesising into a coherent whole, product people tend (on average) to better at their job when they do also have experience with at least some of the other roles they are interacting with (although this isn't necessary to do the job well).
A product manager works at a higher level than those roles. They aren't implementers - they collect information, identify needs, create plans, and get approvals. And then direct the roles you mentioned to do the work needed.
A PM will say things like: "I spent 120 hours talking with our users last quarter. They want a macro language added to the product to make their work easier. Our major competitor already has this feature. We have a budget from the executives and 6 months to get it done. We can get the CX person to do some focus groups to figure out how the users expect it to work, the designer to create some interface options for everyone to choose between and then do the UI wireframes, then the leads can work together to plan the coding schedule based on the implementation phases I will give them."
A project manager will do most of that without the unearned self-importance, minus the talking to customers part which should either be done by product marketing or design, depending on the specific business insight you seek.
yeah +1, I used to wear the product manager hat in an engineering role, while working with bad product managers, and so I thought the role was a grift at best. Also dealing with a herd of b2b clients sucked while trying to focus on doing the things we argued about / committed to doing. Then a good PM got hired, he actually understands what's going on / makes the effort to learn, and the life of "Engineering" roles got so much better. It may be significant in this case that product works with engineering in a kind of liason role and doesn't "dictate" much.
Now program managers, it remains to be seen where their value comes from and I hope it does
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.
I've legit seen PM's just move their own deadlines. Their decision, no attempt at justification, and I've seen it put everyone behind because they're waiting on the PM. I've legit seen a PM deliver a set of requirements 3 days before a deadline and blame the technical team for non-delivery (multiple times!).
> 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
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.
>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.
Want to corroborate, been through several companies and several PMs. The excellent ones are rare, and have disproportionate impact in the team's performance.
I can relate to this. At my previous company, the first PM our team had was absolutely amazing. She had an engineering background but transitioned to management ten or so years ago. At some point, she was promoted and the replacement PM, while good, was not as good.
Fast-forward to my current company, the PMs here are absolutely shocking. The people they report to have no clue. It seems like every PM at my company has fallen upwards, as a result of newly hired PMs quitting shortly after they join. Engineers here are technically competent, but lack direction. Projects spin up before requirements have been defined, leading to massive losses of time. I’ve considered reaching out to my former company’s PMs to offer a referral, but it’d be a disservice to them.
The path to becoming a great PM is longer and arguably harder than becoming a great engineer. Like you say a lot of what makes a great PM comes from years of experience in a variety of roles and companies.
> Very few engineers want to maintain relationships with customers, interview users to identify potential features, manage leadership, play politics for resource allocation, and so on.
Because the more you do, the more you are responsible for, but what you get doesn't increase. It's a question of profit distribution.
And that's how it should work. The article is poorly written, but it does suggest more ownership from roles such as "area leads" which is close to Apple, I guess. With Jobs being the Uber Lead.
When I was at Apple (during the interregnum between Jobs’ reigns) we had people called product managers, but yeah they were mostly about getting the product to market and interacting with the market.
We had project managers who nominally controlled product design decisions. We had test managers in a separate testing directorate (I was one of those).
My experience was that the three managers worked together to define the product, with the product manager trying to represent the market, the project manager representing engineering, and test manager asking pointed questions.
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.
Don't hate the player, hate the game… PMs are just doing exactly what leadership has asked them to do.
The real problem is unrealistic roadmaps filled with top-down strategic initiatives which are often made up by leadership with very little rigor—all in the pursuit of growth at any cost. The bad PM is an emergent property of that system.
Alot of PMs want the job for the wrong reasons or are generally misguided. They want control, believe they are a visionary, use it for stepping stone to be a 'founder' one day, etc. Also, there's a trend of meh junior software developers clamoring to become PMs. I think they found out the recruiting recipe from FAANG where if you have a CS degree and a few years of engineering experience, you'll be recruited into a PM role where you won't have to code or look at a terminal again.
- Why is a company equated with one product?
- Without a "product manager", or, since I prefer scrum terminology, "product owner", who determines the direction of the product development? Who decides what the most important thing to work next is, and where to focus company resources? Who is responsible for making sure that the product is valuable, and that whatever developers work at any given moment serves to maximize its value?
- Without a single "product manager"/"product owner", who decides which of the multiple competing requests to the team takes the first priority?
- With the attitude of "hire everyday great people; each one needs to be great at something; you then put them together in a team", how do make sure that individuals you put on a team work toward a single goal, as a team?
I was ready to hate this article based on the title - I presumed it was a typical "PMs are dumb, all your company needs is smart engineers who rule the world" piece. But it wasn't that, and the author nails the problem pretty much perfectly.
But: The author hand-waves the solution into oblivion:
"There’s an alternative model that works. You hire everyday great people. Each one needs to be great at something, obsessed by their craft, and driven by quality. You then put them together in a team, without individual responsibilities, ensuring that there’s minimal overlap in areas of greatness. And you pay them to have fun doing what they love doing, in exchange for putting their time and skills at the service of your company."
I mean, come on. That sounds lovely but can anyone point to a successful company larger than 100 people where that actually works in practice? (HOW could it work in practice?)
Valve seems to do (or at least, have done) something very similar. Their employee handbook[0] used to be a staple on HN but I haven’t seen it flying around much lately. I wonder if it’s working out of them.
Pinning this on product is IMO a mistake. Most companies don't understand the discipline of performance management; they don't care to learn beyond asking people "hey how did you do OKRs?"; and they substitute organizational design for performance management. This can show up in many ways, including substantially delegating the entire fate of the business to product management.
Also, I've found it a lot easier to reason about organizational issues if you don't fixate so much on "great people." More and more people enter the workforce with the idea of competence as a "ladder" being firmly ingrained in their heads. It doesn't work that way; people succeed as a function of who they are and the environment they're in. Your "smart person" is often totally useless somewhere else (see, for example: the huge numbers of FAANG-ish employees that struggle to do anything in smaller companies, and vice-versa.)
I found this entire article to read like it comes from the heyday of "only associate with people as _great_ as you want to be", which I think (a) was terribly reasoned and (b) hasn't really worked out that great, especially for the people who followed this advice.
Yeesh, I am sorry this person has had such a bleak experience. By the end I took away that their core issues were with people that had: an excess of process, a lack of passion for craft, and a generally narrow outlook.
These are not the attributes I would associate with success or appreciation in any role.
I've been thinking about this as well, but from a different angle: the product manager role just feels too much weight for a single human being to shoulder. When my last company went through the exercise of writing down roles & and responsibilities, the PM's responsibilities ended up being something akin to "general contractor", or someone that does everything that's left over after responsibilities are split up across different team members. It's great when you find that outlier person who can handle this responsibility, but when you can't, the older model of having a team consisting of a business analyst, architect, engineering manager or project manager seems to work (although not in a very satisfying way).
I am not sure this person has ever worked in a place without PMs (or people who do "the PM stuff") because nothing they are talking about is "about" PMs. PMs are, essentially, the people who sit at the center of: customer desires, engineering resources, and internal priorities. They can also do more of course - they could manage the project, manage the team, etc. But they do not have to! You can have this authors' weird great-man-esq "high performers" who will happily rely on their PM to go to all the client meetings they are too busy being great to attend.
Currently I work for a big tech company that mostly doesn't employ PM roles, so I can give a first hand take on this.
My feelings so far are mixed. I've worked in PM-heavy organizations before and I agree that those suck. But at the end of the day there is some work that a PM would do that still needs to be done. In my org that responsibility officially falls into Software Managers and Senior+ Developers.
For example, if you are leading an initiative for your team as a Senior Engineer, you are in charge of doing all the activities that a PM would otherwise do. For other activities, the Manager or Senior Manager of the team is in charge.
Suffice to say that as a developer this sucks. Not only you need to deliver your own work as an IC, but you need to coordinate other people and ensure that things get done. Not only this is extra work, but let's be honest, many developers don't have the skills to be effective PMs. It also makes inter-team collaboration difficult, since now you have to coordinate people that don't share a reporting structure with you.
Often this approach results in lack of ownership, lack of accountability, duplicated efforts or things falling between the cracks, and general disorganization. That being said, it tends to work well for small intra team initiatives involving a few people, since it removes the overhead of a PM and places control in the hands of builders. But for larger initiative, I'm not quite convinced it works.
> 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
I kind of agree with the initial precept. I have seen useless PMs more than I can count, and organizations turned into government bureaucracies on the altar of cargo cultish "best practice" processes. Retro-engineering okrs from a pre-existing list of features, looking at data only for vanity purposes (how good are we).
I think it goes one step too far and throws the baby, the bath tub, and the whole house with the bathwater.
> Do you know what else they had in common? None of them were motivated by OKRs, KPIs, data, or other people’s opinion.
This is not true for Bezos for example. He was famously driving the company through data, metrics and process, and there's countless examples of "Jeff meetings" where he changed his mind after reading the data presented by others.
All those examples are tools, that you can, and often shouldn't use. It makes no sense to have a heavy process when you're small, in direct touch with the customer, and are fully driven by an idea. Similarly, it makes no sense keeping on wet-fingering it and single-person driving once you have a set of established customers and want to increase your penetration.
Same is true for all aspects of a company, from engineering to sales to marketing. As you grow you get more people working, and you need a minimum of coordination and standardization to avoid going in antagonistic positions all over. And same goes with seems between these functions. Let me tell you that I prefer having a good PM to handle these needs and that coordination rather than having to deal with synchronizing their needs as an engineer.
I went in there hoping I would have a good resource to share about the topic, but it's too sour and mono-directed into some weirdly "aw common just be smart about it" to be credible. Ironically, the conclusion of the article (no structure, just smart people everywhere) contradicts one of its central argument (everything doesn't apply everywhere).
This article mischaracterizes the roles of PM's and engineers in most companies.
It sets up a strawman of "delegating control to a single person", and assuming that person is either an engineer or a PM. Everywhere I've worked, the product teams/leaders and engineering teams/leaders were peers. Engineering didn't report to product, and product didn't report to engineering. Rather, both reported directly to the CEO, often as separate CTO and CPO heads, or they both reported to an executive VP or director or similar.
Because the reality is, you need both. Engineers are great at building but they're not spending time with customers or UX research to know what the market and users need. The main job of a PM is to understand what the market and users need by spending a lot of time with customers and researchers, and to marry that with the business priorities coming from executives. And then a PM and eng lead negotiate back and forth to figure out what can be built that meets everyone's needs.
The idea that a product manager role is a mistake makes as much sense as saying an engineering lead role is a mistake, or a sales lead is a mistake, or a marketing manager is a mistake. A successful business needs all parts.
(Occasionally you're building a product that's by developers for developers, where the engineers do have an accurate understanding of users/market, and a PM isn't necessary. But that's exceedingly rare.)
Here's my solution: get (or be) a strong tech lead that can write tickets, negotiate features, and steer technical direction. They can optionally run the team as well, or that can have a separate person, who is still technical, in the team who keeps the trains running on time with meetings etc. The product person is slightly more distant; not in every meeting, and the tech lead makes sure work is synced with the product requirements, which are documented not in tickets, but at a higher level in written+diagram form.
That way you don't have "product" people who are really just status reporting for the team, or "product" people who are really just writing bad tickets that need rewriting. You have actual product people who focus on where the product should be going.
You also don't have a "delivery manager" role. The team needs to be steered into doing this by a decent lead who can do the 3% admin required to keep on top of this sort of thing.
What you are describing sounds like a Technical Product Manager, not a tech lead. The minute you have them “run a team”, you are combining both roles into one.
Writing a tickets is usually not owned by engineering. Some engineering managers may do this work, but it’s usually owned by Product while Engineering helps refine and turn tickets into actionable work. Engineering also doesn't negotiate features. Engineerings job is to help product determine LOE and help Product prioritize requirements for a future release. Again, strong engineering leads can do this work, but I believe Product Owner should hold these responsibilities.
> I believe Product Owner should hold these responsibilities
That's inarguable, as you haven't said why, but I'm saying the structure I described works well. My rationale is: product people don't generally write great tickets, and they also aren't in a position to negotiate features based on technical constraints.
I do agree with the red-flag symptoms like KPI and other “measurements”, and I’ll go as far as to say it’s extremely difficult to find a great PM and the field is riddled with mediocre ones.
In my several decades of software engineering work, good product managers were almost non-existent.
Today I’m working with one who has a strong competitive streak, is quite smart, and deeply understands our users and competition.
I’ve been making sure to give her stellar feedback during reviews and peer feedback, as I know how rare this combination is.
Edit: Reading through the responses, perhaps I should reconsider. The expectation of the role and responsibilities are misunderstood and misaligned to what businesses and engineering teams actually need.
That is to say, my team PM’s a success despite the role and not because of it.
Confusing article. “We should get rid of the PM role” but also “We still need people dedicated to do PM things… but don’t call them PMs, they’re just everyday great people.” I feel like the author had a bad experience working with a PM (the MBA comment is telling) and now wants to throw the baby out with the bath water. Business scale creates + requires role specialization. Sure, there are shitty PMs, and it’s a hard job, but I’d be super disappointed to lose my team’s PM.
Definitely sounds like a bad PM experience, especially with the repeated insistence about handing control of the company over to the PM.
Maybe I just have good experiences with PMs? At my company they're there to figure out what customers want and what the product should deliver, and then with our EMs to balance that with what's technically feasible and what we have capacity to implement. If an EM says "there's no way we can do that on this timeline" the PM works out some alternative plan for the product.
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.
Handing the company over to PMs is a very common problem I’ve seen at smaller startups.
It’s generally not that they are above the leadership team, but that that the leadership team have abdicated responsibility for product development to the head of product.
I think what I described is system where PMs have huge influence on what gets built. But also a system where engineering and strategic leadership also do. Personally that seems like the the balance to me. I think all three things - tactical product decisions, execution decisions, and strategic decisions - are important and separate.
An extremely common organisational leadership failure mode is “[role/thing] is useless, get rid of it… Ooops, we actually needed that. Bring it back, but call it something else so that we don’t have to admit our mistake.”
The author has, apparently, decided to skip the intermediate step and just rename things for no reason.
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.
Yeah, and then they go on to say that all of the great sages weren't PM's, just great people.
I disagree. All of those greats that were mentioned succeeded because they kept the customer and the product tantamount to all else. So really they were just fantastic PM's.
I 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.
It also says that you just build teams where everyone is amazing (good luck pulling off that piece of recruiting magic) and then says “… give them good problems to solve…”
Who exactly does the author think should decide what problems the team should prioritize? That is the primary responsibility of the PM role. Seems like the author has indeed just had a bad experience with a PM who failed at that.
I never understood black and white thinking such as OP.
“Your personal experiences make up maybe 0.00000001% of what’s happened in the world, but maybe 80% of how you think the world works.” - Morgan Housel
Its the same with dating. If you date toxic people, you start generalising that all men are abusive.
Same with PMs. If you are working within a company that accepts subpar talent, you'll start seeing things based on your benchmark of quality. Until you actually work with a great PM that makes your life easier.
Good things to watch out for, but also watch out for project or program running the show. For example, project sees it as a piece of work to churn, and program is trying to execute a multitude of projects.
Someone has got to care about the user and the business.
It can be much worse with a project manager who doesnt care about the user, doesnt care about the business and is just trying to complete tasks per sprint without any focus. It is even worse when the project or program manager has no technical background and doesnt understand what it takes to build something.
In each role, product, project, program, and all the other lead roles (technical), it takes people who really care.
369 comments
[ 4.1 ms ] story [ 135 ms ] threadAnd 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
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.
Then they find themselves among high performers and can't keep up, really through no fault of their own.
Some high performers are just natural and born with it, which is unfair to let that affect how anyone judges others' performance, but it still happens too (esp. if the high performer is doing the judgment).
What I generally see when people categorize their workers into high/low performance is from a bigger issue of poor stewardship over the industry and training its talent.
This means I don't actually have to improve, I can instead just spam job applications and get lucky just because technology is such a large industry.
I agree, but I am also hesitant to advocate for controls in the form of certification (degrees, licenses, etc) because it just adds a layer that provides a strong positive signal for a while until it’s just inundated by grifters yet again, so now we’re back to square one.
We see this take the form of degree mills and accelerated trade schools initially, which ends up creating more problems, more barriers, and ceases to benefit the companies looking to hire. Everything can and will be gamified, and I am also hesitant to tie people to former employers so heavily as that creates an unhealthy power imbalance.
Then how can we control for talent? I don’t know the answer to this question or if it’s even the right question to ask, but I’m fairly confident that we cannot solve this using 20th century nor modern hiring and screening processes.
nowadays there's entirely too much of this externalizing responsibility and making excuses for people.
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....
I had the opposite understanding about the article. Steve Jobs was an extraordinary leader who through immense will power created good products; an attempt to replace someone like Jobs as the product manager with an ordinary person will result in a mediocre product.
I took, naively, a product manager job at one place I worked, thinking it would finally give me formal control over the product that I'd been previously asserting through influence - very successfully - in my client-facing sales engineering role. Of course as soon as I got in the chair I discovered it was a highly-constrained clerical job that I was completely unsuited to. Managing tickets and a backlog; coordinating decisions instead of making them; writing interminable powerpoint reports; the most creative thing was putting together a process for the company to follow in formalizing its product roadmaps. I lasted six months before running away.
The function is quite useful in supplying some visibility into what's getting built and in managing conflicting priorities for a growing product, but one thing it is not is shaping or controlling the evolution of the product in any way. It's a sorting, filtering, and (if you're lucky) a data collection function, producing an auditable decision trail and an impression of maturity in decision making which helps the MBAs higher up sleep a little easier.
I agree 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.
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?
A good product person is able to drill down to the fundamental problem the customer really has and articulate that to engineers.
Also, good product people should be evaluating the customers problem in terms of the whole market.
After all, engineering is a limited resource. So you need to solve the problems that exist for your target market, not just a single customer.
Of course, I’ve seen good engineers who can do this, but it takes time and effort to sift through all of the customers issues and work out which ones to solve. So product managers are focused on this to free up the good engineers to design solutions to those problems.
In my experience the vast majority of PMs do exactly this. Half of my job since I became a staff+ engineer almost a decade ago is taking “solutions” from product managers and trying to figure out what they really want.
Product figures out what to build, and Engineering figures out how.
What you’re describing is a huge part of engineering. Engineers have been doing this long before Product Managers existed. When I started, software engineers used to just talk directly to customers, domain experts, business analysts, and business leaders.
At “product led companies” the engineers just end up trying to figure out what the product manager actually wants because it’s not really possible in most cases to separate the what from the how.
Having worked with both systems, I don’t think the way it works now is better.
In the modern consumer application, you have to understand business concepts like differentiation. If your product is very good, but it’s strictly worse than another product in every dimension, you don’t get any credit for second place. You actually get close to zero sales because no consumer chooses your product over the alternative, in contrast to a “bad” product that does at least something very well in a niche.
And in software there are plenty of cases where the 2nd or 3rd place product gets tons of sales even if it’s strictly worse in every category. There are so many things that impact market success that are completely out of the hands of product or engineering.
And even if it was, no, engineer personalities are horrible at designing solutions that actually meet customers’ and the business’s needs
This sort of stuff is a not-insignificant portion of my job as well, since PMs rarely have the technical skills to know what's feasible as a solution anyway in my experience.
[0] https://www.snopes.com/fact-check/cone-of-silence/
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.
precisely, the introduction of a PM means that the people who actually implement the product are put below pure talkers. You suddenly go from being able to influence the product daily to everything being up for a vote and every vote being overriden by the PM. The PM gets to decide which issues are important enough to be included even though he really doesn't know better 99.9% of the time. 99.9% of the time he didn't talk to customers about it, he just has his own opinion and was put into this artificial leadership position that ruins the fun of the job for everyone else. Oh sure he talked to leadership but that ends up being about how to achieve his own dreams and goals, certainly not to help make the ideas of engineers a reality. I've literally never seen a PM that goes and asks what ideas of the engineers we can help make reality. Just let that sink in for a moment: Isn't that what a product is? Ideas of engineers? I mean it really is. The whole agile movement is one of the strangest gaslighting ventures that human psychology has ever produced. We are told that there is no boss while actively being micro managed issue by issue, hour by hour almost, while literally being asked every single day in the standup when X will be finished.
> 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 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.
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".
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").
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.
For example, look at the scope and definition of a "program manager" from Microsoft or the US DoD in the 1980s, 1990s+, as well as literature describing the role of a program manager and the discipline from that time.
Most companies with product managers have fewer customers and less complex products than 1990s Microsoft.
In my experience, as soon as you decide your projects will be formal and managed, you are already doomed to that negative value.
You can’t build a £20m facility with a series of sprints.
You need a formal design. This doesn't mean you need a formal project. Some amount of planning ahead very obviously helps, but how much is debatable, and when you have people whose sole specialization is "planning ahead", you are certainly past the point where it's too much.
Anyway, the most valuable people are the ones "planning behind", looking for what was left broken and could be done better from now on. Project management defines those people out of existence.
It is a high level abstraction that allows all parties to understand what they need to do and when they need to do it. For large projects it is simply essential - you need your external vendors to plan their availability, months or sometimes years in ahead, so that they can commit to the timeline.
If you're lucky enough to work on large software projects where there are no managers or other stakeholders asking "and how long will this take, exactly?" then maybe the design is enough.
But pretending planning ahead on large projects that is something that will just happen by osmosis or people "just doing it" simply won't work. Good project managers who do what they're supposed to are worth their weight in gold (just like good product managers).
How well can your project managers answer how long will this take? Because on my experience, 10000% delays are all but routine (ok, on construction it's usually bounded to something around 1000%). And how much value do people that can give you an estimate between 1% and 10000% of the target?
> But pretending planning ahead on large projects that is something that will just happen by osmosis
I'm telling you that planning ahead has a small value, following up with the plan has a high negative value, and the thing with a high positive value that is reexamining the plan is fought against by the practitioners.
If things start to slip, they find out where and why and apply what pressure they can to get them on track. If they cannot get them on track, they then liaise with everyone downstream to make them aware of the slippage, adjust the entire schedule, and get everyone reorganised.
It's not just putting things in the calendar and forgetting about them - it's a constant, ongoing herding of cats to get them all going the same way.
It sounds like you just might not have been lucky enough to work with really great project managers!
The wiki for “programmer” has “software developer, a software engineer, a programmer or a coder” as interchangeable terms in the first sentence.
[1] https://en.m.wikipedia.org/wiki/Programmer
BIT meeting on my calendar. Is it behavioral intervention team or something about the bachelor of information technology or Business Information technology or bachelor of industrial technology or are we talking about income taxes or what?
The split between project manager and product owner seems clearest.
A project manager is running the team. Who does what and when? How do we plan the work?
A product owner is kind of like the representative stakeholder. What should this do? How important is launching now Vs fixing these bugs?
How Vs what.
Good people in these roles are incredible. I've been fortunate to work with some.
Project Manager: They ensure that all the tasks for a project get done on time. They make the gantt charts, work with teams to break it down into sections, keep track of budgets, manage risks, report on progress to stakeholders, etc.
I've never worked with a Product Owner since I understand it is mostly a software related position and that is not my area. From what I understand, they are an intermediary that sits between PdM and PjM.
What is a product but a large project anyways?
A project manager is in charge of planing, execution and governance of a project. They don’t define any of the goals or vision.
Saying product is a large project is a big over simplification. If we go that route anything could be called a “large project”.
Yes. That's precisely the point. What's the difference between "X manager" and a "project manager" when the X itself is obviously a project?
This sounds like if you were trying to hire a race-car driver instead hired two people, and put one of them in charge of steering to the left and the other in charge of steering to the right.
A project has a defined start and end. You know when it’s done, and you should know that before it even starts.
A product is ongoing. It reacts to business changes.
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.
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.
There's a large number of companies where the company is the one wedging the PMs there.
My view is that a PMs job should include (but not be limited to) diplomacy, negotiation and facilitation. But if your heart isn't in that (and it can be easy to become disheartened), then it easily becomes "politics", and the worst parts of politics, at that.
I don't know if the same role makes as much sense at a B2C company, so maybe people are B2Bs see their value and people at B2C companies don't as much?
So tech people (even IC non-leads) end up on weekly calls with various internal stakeholders that the PM can't make (literally this is your job dude) and take the brunt of all the feedback/relationship management/etc with the trickier ones.
The worst was when he said he would take the weekly calls with Asia users but wanted to pre-meet with me first and ask I ride along with the weekly user call for a while. So we would pre-meet and then he would ghost on the user call so I end up having two calls instead of one.
Just cargo cult CTOs reading too many books and not actually looking at the evidence in front of their eyes.
In B2C the customer is way clearer and the relationship is everything and it’s quite hard a bad professional hide for long.
TA’s will devour the BA’s because tech folks can learn business easier than the other way around.
Still, BA’s can learn the details and get more fluent in working with them.
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.
I operate as principle on a project, and I have opinions, but I cannot set the roadmap alone
We have loads of project managers where I work and I thank my stars we have every one of them. The coordination and planning required is ferocious for the work we need to deliver. It is not trivial and it would quickly fall apart without them.
But you're right that my comment focused only on the latter thing and ignored the former one.
But setting that aside, there is certainly a personality thing at play here. If I worked where you work, I would probably be more skeptical of the value of all the time being put into project management, and if you worked at my favorite companies that I've worked at, you would probably feel like it's a poorly managed mess (I've had lots of coworkers who felt that way!).
To some extent different folks just like different strokes, and that's one of the things that makes it really hard to do things that require lots of people to pull in the same direction.
Program management is a level above project management as you say, coordinating multiple projects. But there is definitely a space for complex single projects (not programs) that still require detailed planning and coordination.
It's not really about personal preference though, unless this issue is a show stopper for you in terms of where you work. I've worked in both informal and formal settings. I personally dislike heavyweight project management processes but they are sometimes required!
(I get it, sometimes the need for a lot of planning is imposed from the top, like if you sign a contract with an immovable delivery date, but I think most organizations should do whatever they can to avoid doing that, in order to enable them to structure projects flexibly and have small mostly-autonomous teams.)
I think the personality thing is important both in terms of contentment with your work (and thus which organizations and projects you choose) and in terms of how you analyze the relative value of things when evaluating trade-offs between the different things an organization can invest its time and resources on.
I agree that it's good if it's possible to avoid all that and still deliver what you need to!
Also agree that many people simply can't stand working in really heavyweight environments. While I dont love it, I can live with it.
One thing I think is that a lot (though not all!) of the requirements imposed in heavily-regulated industries are actively counter-productive, because they more effectively introduce friction on positive changes than risky ones. But it's basically impossible to strike the exact right balance between mitigating tail risks, which is critical, vs. introducing counter-productive friction. So I have sympathy, I just also find it very frustrating to work in such environments.
Friction certainly makes it harder to introduce positive change. I don't think it makes it easier to make riskier ones though, but you often can't do everything you'd like to get done.
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.
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.
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.
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.
We can define and name the roles all sorts of things (project manager, product owner, product manager, product marketing manager), but what it boils to is for any complex product there is a need for the management of the product at a holistic level and a need for management of a product at a granular level.
What I’ve witnessed over a 20 year career is that weak product people devolve to mediocre project managers. It’s easier to be a shitty project manager.
Good project managers are gold. I worked with one who stood out a decade ago - his leadership at execution was such that a $350M, 20 month implementation, with collaboration with construction, tech, and external suppliers completed 45 minutes ahead of the original schedule. He’s since retired and passed away, but an inspirational leader I was privileged to get to know. Ponder that - how many project managers are acknowledged as leaders?
This made me smile. I'm assuming you mean 45 days or something. Not that any number 'ahead of schedule' is inherently a bad thing (within reason), but my mind went to "Are there really companies out there tracking 2 year projects and counting the minutes?" (and sadly, there probably are).
That said, some major elements were tracked to the minute. I wish I could share more, it's a great story!
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.
Determination, evaluation, and articulation of requirements is the sweet spot of the product manager role. Understanding those requirements is certainly necessary for an engineer to build to the requirements.
Once upon a time, this too was a formalized practice in engineering that people called "Systems Engineering":
https://en.wikipedia.org/wiki/Systems_engineering
https://www.nasa.gov/reference/2-0-fundamentals-of-systems-e...
Writing good code is a very separate skill set from that kind of problem-space work, and software engineers are mostly hired for the former.
Imagine developing an AAA game with no one in charge of the overall product. Or creating a movie without a producer or a director, expecting the talent to somehow organise itself.
PM isn't an engineering job, it's a vision job - one that needs enough technical knowledge to create a vision that's grounded in reality, while also appealing to customers, while also being able to sell it up and down the org.
That skillset is incredibly rare.
The article was all about the consequences of the skill set being incredibly rare.
Imagine if a director was a bureaucrat. One who followed checklists and made policy documents, and did not have the slightest clue about the actual craft of setting lights, working the camera, and acting.
What's our profession's equivalent of a film director? One with deep knowledge about data structures, who cared about getting it right, together with professionals?
Scrum master.
Good product managers identify the problems to be solved, and prioritize which ones should be solved first.
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
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.
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.
The problems you describe are legit but unless you have extremely technical product managers, hiring more PMs will only make the problem worse.
Does the vast majority of PMs need to tell the difference between TLS 1.3 and 1.x?
I mean, is that a relevant aspect of the vast majority of products?
If not, why should a PM bother about irrelevant details?
One of the cardinal sins of proponents of this "engineers should rule everything" mentality is failing to tell apart the critical factors from the irrelevant details, and conflate not caring about obscure implementation details with incompetence. Except the cheekiest little fallacy in software development circles is that the purpose of all software projects is not correctness or code coverage or uptime or resilience. The purpose of each and every single software project is to serve their users' interests. That's the critical part of a project, and the thing that PMs focus on for the right reasons. Naturally, PMs prioritize work with the biggest impact. Does TLS trivia fit this requirement? No.
Non-technical PMs tend to gloss over things like that as an engineering-driven feature. Clients don't ask for TLS 1.3 (at least until it's often too late) because they generally aren't considering TLS trivia until it comes time for their next audit.
You see, I don't think that's true at all. If it was, certainly you'd have clients complain loudly enough for the PMs to notice.
But that doesn't seem to even register a concern, both from the client and from the PM point of view.
Convenience is a nice-to-have, and fixing problems that don't exist registers even lower in the priority queue.
> Non-technical PMs tend to gloss over things like that (...)
See, this is where I think we disagree at a very basic level.
There is no such thing as a technical and non-technical Product Manager, because a product isn't technical. A product is something that meets the needs and expectations of its customers. A Product Manager's responsibility is to know their product and manage it to meet its clients' needs, and in the process help guide the development effort to maximize its returns on investment. Whether it's to paint a button red instead of blue, or to tell if they need to upgrade TLS, a PM's job is to read the room and deliver what meets the needs.
Because engineering failed to consider these details. Now I'm the one that has to point out how amateur we look when in some areas we don't require TLS and others we're so strict, we only have 1.3. Engineers (management or rank and file) who can't understand why this is a problem is exactly the reason you need technical PMs.
I don't think you got the point. The point is that no one cares, or think it's important enough and much less critical to justify wasting time with it. Product Managers are there to create value, and spending time on things no one notices is not how you create value.
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 point is though, product never challenged on approaches, and you’re right. They never came from technical backgrounds. Product managers were promoted from the BA ranks. They never raised technical questions like that - “Is it a bad thing if the customer has to connect this way for this API and another way for another API?” If the idea is that engineering asks those questions, I’d counter with that’s venturing squarely into product’s realm.
- Someone to understand the customer's desires and shut down unnecessary work.
- Drive the team to deliver features that the customers/business actually needs.
- drive tech decisions to prevent future inoperability with other products
- roadshow and maintain a team's reputation across the org
- etc
I can think of a bunch of different ways of solving this that would take a few days to build out.
It seems to me, especially in the wild and woolly mom-n-pop end of the market, that there might be ample room for a company to sustainably put food on a certain number of employees’ family tables without much left over to characterize as profit.
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.
I’ve never met a PM that did any of that either ;)
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.
Also, what engineer doesn’t understand the product deeply from both a technical and business perspective? Maybe a contract dev, or a new hire.
Reforge provides good training for product managers. This article provides a good overview of a role of a PM: https://www.reforge.com/previews/product/what-does-a-product...
Now we have Product Manager orgs with Associate PMs, junior PMs, senior PMs, group PMs etc…
A junior PM almost by definition can’t be a product owner. They don’t have the seniority to make decisions, so what you end up with is a situation where senior PMs are handing down solutions to junior PMs who are coming up with even more detailed solutions to engineers. I’ve seen it time and again.
I mean product owner as in the person responsible for the product.
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.
That kind of depends. The product-minded ones (who are naturally interested in the "producty" kind of work) are excellent people for that. So you may find that in some companies the people doing product work are either engineers or designers. I've often done that from the engineering side, and I've seen it done really excellently by UX designers too. In other companies you may have dedicated people.
In my experience, whether it works well or not is less a function of how the roles are divided and more a function of whether the individuals doing product work are good at product work (which is difficult to find, even when they are dedicated product specialists). I think I would probably argue that due to the nature of the job being a lot about connecting different functions of the business and synthesising into a coherent whole, product people tend (on average) to better at their job when they do also have experience with at least some of the other roles they are interacting with (although this isn't necessary to do the job well).
A 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."
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.
It sounds so ridiculous, and yet ... it happened.
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
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.
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.
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.
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.
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.
The closest they had was Steve Jobs and Product MARKETING Managers, which are quite different than Product Managers.
We had project managers who nominally controlled product design decisions. We had test managers in a separate testing directorate (I was one of those).
My experience was that the three managers worked together to define the product, with the product manager trying to represent the market, the project manager representing engineering, and test manager asking pointed questions.
"People are hired based on whether they’d represent no treat"
I think author means "threat".
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.
Agree 100%, but this is where I've seen a lot of organizations fail, especially large ones.
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.
The real problem is unrealistic roadmaps filled with top-down strategic initiatives which are often made up by leadership with very little rigor—all in the pursuit of growth at any cost. The bad PM is an emergent property of that system.
But: The author hand-waves the solution into oblivion:
"There’s an alternative model that works. You hire everyday great people. Each one needs to be great at something, obsessed by their craft, and driven by quality. You then put them together in a team, without individual responsibilities, ensuring that there’s minimal overlap in areas of greatness. And you pay them to have fun doing what they love doing, in exchange for putting their time and skills at the service of your company."
I mean, come on. That sounds lovely but can anyone point to a successful company larger than 100 people where that actually works in practice? (HOW could it work in practice?)
Valve seems to do (or at least, have done) something very similar. Their employee handbook[0] used to be a staple on HN but I haven’t seen it flying around much lately. I wonder if it’s working out of them.
[0] https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployee...
Also, I've found it a lot easier to reason about organizational issues if you don't fixate so much on "great people." More and more people enter the workforce with the idea of competence as a "ladder" being firmly ingrained in their heads. It doesn't work that way; people succeed as a function of who they are and the environment they're in. Your "smart person" is often totally useless somewhere else (see, for example: the huge numbers of FAANG-ish employees that struggle to do anything in smaller companies, and vice-versa.)
I found this entire article to read like it comes from the heyday of "only associate with people as _great_ as you want to be", which I think (a) was terribly reasoned and (b) hasn't really worked out that great, especially for the people who followed this advice.
These are not the attributes I would associate with success or appreciation in any role.
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
I think it goes one step too far and throws the baby, the bath tub, and the whole house with the bathwater.
> Do you know what else they had in common? None of them were motivated by OKRs, KPIs, data, or other people’s opinion.
This is not true for Bezos for example. He was famously driving the company through data, metrics and process, and there's countless examples of "Jeff meetings" where he changed his mind after reading the data presented by others.
All those examples are tools, that you can, and often shouldn't use. It makes no sense to have a heavy process when you're small, in direct touch with the customer, and are fully driven by an idea. Similarly, it makes no sense keeping on wet-fingering it and single-person driving once you have a set of established customers and want to increase your penetration.
Same is true for all aspects of a company, from engineering to sales to marketing. As you grow you get more people working, and you need a minimum of coordination and standardization to avoid going in antagonistic positions all over. And same goes with seems between these functions. Let me tell you that I prefer having a good PM to handle these needs and that coordination rather than having to deal with synchronizing their needs as an engineer.
I went in there hoping I would have a good resource to share about the topic, but it's too sour and mono-directed into some weirdly "aw common just be smart about it" to be credible. Ironically, the conclusion of the article (no structure, just smart people everywhere) contradicts one of its central argument (everything doesn't apply everywhere).
It sets up a strawman of "delegating control to a single person", and assuming that person is either an engineer or a PM. Everywhere I've worked, the product teams/leaders and engineering teams/leaders were peers. Engineering didn't report to product, and product didn't report to engineering. Rather, both reported directly to the CEO, often as separate CTO and CPO heads, or they both reported to an executive VP or director or similar.
Because the reality is, you need both. Engineers are great at building but they're not spending time with customers or UX research to know what the market and users need. The main job of a PM is to understand what the market and users need by spending a lot of time with customers and researchers, and to marry that with the business priorities coming from executives. And then a PM and eng lead negotiate back and forth to figure out what can be built that meets everyone's needs.
The idea that a product manager role is a mistake makes as much sense as saying an engineering lead role is a mistake, or a sales lead is a mistake, or a marketing manager is a mistake. A successful business needs all parts.
(Occasionally you're building a product that's by developers for developers, where the engineers do have an accurate understanding of users/market, and a PM isn't necessary. But that's exceedingly rare.)
That way you don't have "product" people who are really just status reporting for the team, or "product" people who are really just writing bad tickets that need rewriting. You have actual product people who focus on where the product should be going.
You also don't have a "delivery manager" role. The team needs to be steered into doing this by a decent lead who can do the 3% admin required to keep on top of this sort of thing.
That's inarguable, as you haven't said why, but I'm saying the structure I described works well. My rationale is: product people don't generally write great tickets, and they also aren't in a position to negotiate features based on technical constraints.
I do agree with the red-flag symptoms like KPI and other “measurements”, and I’ll go as far as to say it’s extremely difficult to find a great PM and the field is riddled with mediocre ones.
In my several decades of software engineering work, good product managers were almost non-existent.
Today I’m working with one who has a strong competitive streak, is quite smart, and deeply understands our users and competition.
I’ve been making sure to give her stellar feedback during reviews and peer feedback, as I know how rare this combination is.
Edit: Reading through the responses, perhaps I should reconsider. The expectation of the role and responsibilities are misunderstood and misaligned to what businesses and engineering teams actually need.
That is to say, my team PM’s a success despite the role and not because of it.
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.
It’s generally not that they are above the leadership team, but that that the leadership team have abdicated responsibility for product development to the head of product.
I think it works pretty well. We ship a lot of great stuff.
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 disagree. All of those greats that were mentioned succeeded because they kept the customer and the product tantamount to all else. So really they were just fantastic PM's.
I 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.
Someone has got to care about the user and the business.
It can be much worse with a project manager who doesnt care about the user, doesnt care about the business and is just trying to complete tasks per sprint without any focus. It is even worse when the project or program manager has no technical background and doesnt understand what it takes to build something.
In each role, product, project, program, and all the other lead roles (technical), it takes people who really care.