My current company is full of smart people, and (for a variety of reasons) we don't have product managers. It sucks. What happens is that the things a PM does do not get done. Very few engineers want to maintain relationships with customers, interview users to identify potential features, manage leadership, play politics for resource allocation, and so on. So it doesn't get done. That's what happens there.

At my last company, where I worked for about a year, I had three product managers. Two of them were fired because they were incompetent. One was really, really good (tremendous, in the parlance of this article). Our team still got more done in a year with a fraction of a good PM than my current company has gotten done in over two years without any PMs.

I agree with one thing: there aren't enough good PMs to go around. My belief is the number of people cut out to be a good product manager scales linearly with the size of the population. You need certain personality traits and other qualities that can't be taught. You can mint mediocre PMs in school, but you can't make good ones that way, let alone great ones. The problem we are dealing with is that the software industry did not scale linearly, it exploded exponentially, and it needed 100x the number of people wearing the PM hat than there were actual, bonafide PMs in the world.

Ah, so that's what a product manager is supposed to do. When product managers were introduced at a company I worked at, they did very little of any of that. They certainly weren't speaking to customers. They weren't technical, so they weren't managing our Jira tickets. And "managing leadership" fell mostly on our managers' plates. I think the PMs mostly had meetings, talked to leadership, talked to engineers, wrote documents, and presided over the (now very long) sprint planning meetings.

I can imagine product managers that did your list of things being a lot more valuable.

I'm currently trying desperately to get two different PM's to talk to each other so we can be consistent with permissions sets across two different projects. Both projects use the same set of API's.

One of the PM's is basically incognito, the other has actively been trying to avoid doing any of the work.

But the technical teams will get blamed for this, I know because I've watched these same PM's blame the technical teams for their own failings on other projects.

I'm with the article, fuck Product Managers, grab a senior developer and let him or her spend part of their time interfacing with business while also teaching the younger developers the skills necessary to do it.

The problem isn't that their responsibilities aren't useful, it's that there shouldn't be a role dedicated to their responsibilities, it immediately draws moats around everything and suddenly the need for communication and collaboration jumps through the roof because the people in that role don't understand the technology the way a senior developer would.

There's a segment of the developer population that wants to put their head in the sand, do their job, and clock out. These developers are low value and will never be able to take on the role described above.

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.

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.

In B2C the customer is way clearer and the relationship is everything and it’s quite hard a bad professional hide for long.

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?

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.

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.

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”.

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.

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

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.

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!

So it follows there will be more anecdotes about bad managers than good ones.

With respect, if you've never had a good, or great, manager then I understand it'll be hard to envision a good one.

I say this not to invalidate your anecdote but yo say that managers, like programmers, are not created equal and they cannot just be swapped like burgers at macdonalds.

Over and over, the staff were pounded with "we are an engineering first company." Well, that means the engineering teams were allowed to do whatever the hell they wanted and chase the shiny newest techs. There's 3.5 main products (really 4.5) each made from a different tech stack. There's another eight or so legacy products we have to support due to legacy demands. There's no inter-operability of standardization between products. Basically, there's no knowledge transfer, so the cost of development is through the roof.

Twice this year, I had to explain to 20 year-tenure engineers that don't understand why it's a bad thing that one API is TLS 1.3 only, another is 1.x, and another doesn't even require TLS.

Customers hate us. For my product, they literally wrote the marketing materials first, and let the engineers figure it out. One stage of my product takes Oracle data and puts it into parquet. The guys who did it did it in three different languages, two other DBs inbetween (MySQL AND PG), and was going to introduce Redis before I stopped the insanity. Everything is fragile and sucks.

Thankfully, PE took over two years ago and we now have an ultimatum to make money or else. We are a twenty year old company that has never made money (we've been a cost center). Even if we don't meet it, I feel like the Universe will be better off without the travesties against software design that we created.

APIs using different TLS versions falls into the same category. Unless the TLS version is part of the product (which is the case for e.g. API Gateways, webservers and proxies) PMs will likely not care. They should however care about the difference between no TLS at all and a "somewhat modern TLS", because "no security" is definitely an important gap in the product.

The 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.

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.

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.

It seems to me, especially in the wild and woolly mom-n-pop end of the market, that there might be ample room for a company to sustainably put food on a certain number of employees’ family tables without much left over to characterize as profit.

I read this and thought you worked at my previous employer (household name in IT).

Engineering first company. Oof. This meant that as a PM, I got introduced to two of the products I'd be managing when Engineering and Architects had come up with a grand idea to build a component/subsystem to replace a previous one which had been over-engineered and never gained traction. They hadn't talked to any customers who used it, or that had liked the idea, but not the execution. They were just given a wide latitude to experiment (don't get me wrong, some experimentation and exploration is useful), got a greenlight for some time to prototype it, and did so.

And then, and only then, was I called in as a PM, and told, here's our prototype, here's some vague documentation of what we wanted to solve with this - "Now, Mr PM, can you shoehorn a Product Requirements Document around what we've already built and where we see it going, and can you do the Market Requirements Document to answer the questions we probably should have asked before getting this far?"

And then I would get catch-22s. Express doubt over the needed research and potential for the product and I was told by management that "PMs need to be passionate and fearless advocates for their products"... and then when I do try to eke something out, but lo and behold, our internal 'market', let alone customers are ambivalent about why we are working on a "v2" of this feature, when the market is either accepting the weaknesses of "v1" or have long built out their own solutions and moved on, and as a result we have a stakeholders meeting where we decide to end the experiment, and I'm chastised for "poor product management judgment" for not killing the project far earlier... the project I have no authority to kill, because it's an Engineering first company, and the project whose existence I learned of when it was tossed into my lap as a 90% complete prototype/proof of concept.

And then you have a few hundred (yep) Product Managers in our BU all trying to do their own thing, some empire-building, some truly product-focused... and it's a shit show.

I love being a product manager. I took a similar path as you... although most of my engineering background is SysAdmin/Devops/SRE/infrastructure and then management thereof. I love being a product manager, and thought that this role, at this company, would have untold potential and I could settle in, learn, grow, build from there. But it was everything from a Dilbert cartoon.

When this role is dumped into engineering, engineering management or general management, it weakens the engineering practice. If I need engineers, I need to select for that ability and frankly shield them from people on the outside. If the org requires that my teams handle interaction, now I'm hiring people with mixed skillsets in one org, which inevitably waters down the engineering side.

I'd argue that the position taken above weakens the engineering practice. Understanding requirements (e.g. constraints) is a core element of engineering, engineering management, and general management. Part of the problem plaguing the tech industry is the "dumping" of this responsibility, and others such as "project management" into some other role. What some like to call a "specialization" may also be called an abdication of responsibilities and ultimately accountability.

In my opinion, the essence of engineering is the methodical art and practice of solving problems. A fundamental part of engineering is understanding the problem(s) to be solved, the constraints, as well as the trade space and trade offs of solutions for those problems.

Not all aspects of (engineering) problems are "technical" in nature, and a failure to understand this and cultivate this understanding weakens the engineering practice.

Imagine developing an AAA game with no one in charge of the overall product. Or creating a movie without a producer or a director, expecting the talent to somehow organise itself.

PM isn't an engineering job, it's a vision job - one that needs enough technical knowledge to create a vision that's grounded in reality, while also appealing to customers, while also being able to sell it up and down the org.

That skillset is incredibly rare.

Imagine 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?

The article was all about the consequences of the skill set being incredibly rare.

Good product managers identify the problems to be solved, and prioritize which ones should be solved first.

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.

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!

Why on earth would being able to handle interactions “water down” engineering? They’re two perpendicular skillsets. We’re not in Hollywood, engineers don’t have to be autistic

This is a great testimony. I think that stretching their capacity is a forcing function to stay high level and vision oriented, and avoid having PMs go too deep and start building up useless processes, or over-define features.

A decade+ of low-interest-rate fueled growth in the tech sector has meant a lot of us have succeeded just by showing up.

What’s not great is customers arguing with engineers about which features to implement first or whether their bug report ought to have been backlogged. This is where a strong product role is essential.

For any product of reasonable complexity, taking to users is something a PM should be spending ~1.5 days/wk on. Plus overseeing quantitative user research.

If your engineers are all spending that kind of time on users, that's slowing down the amount of time writing software by a huge amount.

I operate as principle on a project, and I have opinions, but I cannot set the roadmap alone

They may jump in occasionally to tell us another team needs X or the business wants to see more Y so we should re-think what we work on next, but I struggle to see why that couldn’t be handled by our technical team lead.

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.

Development was so much smoother. I didn't have to spend time explaining why we couldn't do this or that. He'd nix bad ideas at higher levels before it even hit us. We were given ample warning on how we approach things ("Custom B will want this, and if box what you're doing now it'll be harder blah blah blah").

Those PMs in the PMO knew their shit, they were realistic, they understood different strategies, they handled managing up and down, and ensuring everyone knew what they had to do.

I wrote a linkedin review for my favorite PM and it's as follows:

When I first met Rajitha, she was in the process of managing a company wide Windows 7 to 10 upgrade. As it turns out I was one of the last holdouts and was badly overdue. She was incessant! I hated it!. Finally, I gave into her demands and as these things go, I was pleasantly surprised how smoothly it went.

Fast forward a few months and Rajitha was tasked to work along side myself and others on several complex tech merger/acquisition projects. Moving parts, moving people, the whole thing was a whirlwind held down by a few important people on the team, including her. My initial resentment was replaced with a new deeply held respect for her capabilities and skillset. She was amazingly diligent and focused, friendly and compassionate.

If you're get a chance to work with Rajitha, count yourself among the lucky few!

Sorry Rajitha, this recommendation is many years overdue. I was cleaning out my filing cabinet and found a stack of old Church & Dwight papers. A print out of "How I learned to stop worrying and love Direct To Consumer". A "Magneto", not "Magento" project cover, and a handwritten note -- left on my desk -- from you to make sure I followed up a task that was in my queue".

Fast-forward to my current company, the PMs here are absolutely shocking. The people they report to have no clue. It seems like every PM at my company has fallen upwards, as a result of newly hired PMs quitting shortly after they join. Engineers here are technically competent, but lack direction. Projects spin up before requirements have been defined, leading to massive losses of time. I’ve considered reaching out to my former company’s PMs to offer a referral, but it’d be a disservice to them.

there aren't enough good software developers to go around. My belief is the number of people cut out to be a good software developer scales linearly with the size of the population. You need certain personality traits and other qualities that can't be taught. You can mint mediocre SWDevs in school, but you can't make good ones that way, let alone great ones.

That's not what a PM does. You're missing leaders.

Customer relations is generally under sales. Resource allocations, politics, that's engineering leadership stuff.

Customer interviews is part of what a PM (or UXer) does. It's never been a critical pain point in any business I've been though. It's part of defining the product, oftentimes companies have a X years backlog of features users asked for and not enough time to build.

I’ve never met a PM that did any of that either ;)

Because the more you do, the more you are responsible for, but what you get doesn't increase. It's a question of profit distribution.

Now program managers, it remains to be seen where their value comes from and I hope it does

Second, bad PMs just create unnecessary work for everyone around them. Everyone believes they just have to do what the PM says, and then suddenly you have a whole eng team contributing nothing.

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

The path to becoming a great PM is longer and arguably harder than becoming a great engineer. Like you say a lot of what makes a great PM comes from years of experience in a variety of roles and companies.

That’s what CX is for.

> interview users to identify potential features

That’s what designers are for.

> manage leadership, play politics for resource allocation

That’s what your lead/people manager is for.

You don’t need a PM. You need an org chart.

A PM will say things like: "I spent 120 hours talking with our users last quarter. They want a macro language added to the product to make their work easier. Our major competitor already has this feature. We have a budget from the executives and 6 months to get it done. We can get the CX person to do some focus groups to figure out how the users expect it to work, the designer to create some interface options for everyone to choose between and then do the UI wireframes, then the leads can work together to plan the coding schedule based on the implementation phases I will give them."

Designers interview people, and potential features may come out of that. They don't put those potential features into a roadmap and allocate resources to them. I'm a designer: if it were up to me, I'd spend 99% of my time improving the UX of the product we have, because that's what I care about most. Somebody has to own the vision for the product with respect to the company's business goals, and individual designers and engineers are not the right people for that. Maybe I ought to have phrased that better originally.

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).

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.

This sounds like a combination of charisma, leadership, and drive, which makes sense as a pretty rare set of qualities for one person to have.

... And reading that, I think I left out that they were super nice, and everybody liked them.

Those are the marketing people. On most places they are stupidly completely focused on sales, but that's not ideal.

Product management is also a task for those people, but singlemindly focusing them on PM is about as bad as doing that for sales.

> manage leadership, play politics for resource allocation

And those are management tasks. It makes no sense at all to give both sets of tasks to the same set of people.

Maybe I just have good experiences with PMs? At my company they're there to figure out what customers want and what the product should deliver, and then with our EMs to balance that with what's technically feasible and what we have capacity to implement. If an EM says "there's no way we can do that on this timeline" the PM works out some alternative plan for the product.

In the good cases I've seen, it's just as you describe, with EMs and PMs working together with high trust to get to a decent level of consensus between them, and then parlaying that consensus into leadership buy in for their roadmap.

In the bad cases, there is some breakdown in trust between the EM, PM, or leadership. Or, worse, between the EM and their team.

But I haven't run into this thing where the PM reigns supreme, above the leadership team.

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 have 20 years IT experience. I'm a PM. I'm looking to do an MBA for knowledge, learning about more formal business understanding, etc., and to help as I advance.

The PMs I know who are similar don't get an MBA and immediately start playing fuckfuck games (to borrow from military parlance). It's those who went high school > college > MBA > managerial role, without a day's experience in the field except maybe a brief internship half way through their undergrad.

“Your personal experiences make up maybe 0.00000001% of what’s happened in the world, but maybe 80% of how you think the world works.” - Morgan Housel

Its the same with dating. If you date toxic people, you start generalising that all men are abusive.

Same with PMs. If you are working within a company that accepts subpar talent, you'll start seeing things based on your benchmark of quality. Until you actually work with a great PM that makes your life easier.

There are good engineers and bad engineers.

This polarisation is IMO an incredible bias.

I disagree. All of those greats that were mentioned succeeded because they kept the customer and the product tantamount to all else. So really they were just fantastic PM's.

And the alternative is, "hire good people but not with the PM role"?

It reads like someone had a bad experience with a PM who thought they were Steve Jobs. PMs are just ordinary people, I don't understand this supposition that anyone holding the title is going be an entitled douchbag. An org can have thousands of PMs, each with a superior.

Just a weird article

I had the opposite understanding about the article. Steve Jobs was an extraordinary leader who through immense will power created good products; an attempt to replace someone like Jobs as the product manager with an ordinary person will result in a mediocre product.

1. Don't hire product managers because they won't be great people.

2. Instead, hire great people, but not one of them, a whole team of them!

Ok....

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.

Here's a list of what they tend to do:

- gather information from users on what is/isn't working for them

- gather information from executives about what needs to be done to keep the company working

- gather information from industry leaders who may or may not be part of the company about where the industry is going

- work with design

- take all 4 previous points and distill them into what actually needs to be built for a needed feature

- work with engineering to figure out what is practical, vs not, for building, and how long approximately it will take

- work with engineers / higher ups to remove features that take time but don't add as much value.

- work with engineers to ensure estimation and team velocity is more or less predictable

I've probably already described a 1 and 1/2 jobs. Now if you take product away, each of the above gets distributed among the engineering team, and not everyone in that team is good at it. And even if they get to a good homeostasis, one person leaves and now there's a non-obvious gap that we're not interviewing for.

I suspect a lot of teams have gotten burned from dysfunctional product orgs that seem disconnected (or disinterested) on the more customer/industry/organization side and instead burn through tons of meetings iterating on mock-ups, micromanaging designers (causing good ones to quit) and tying up engineers in product meetings they do not need to be in.

It's human nature to find the best way to survive so we can't really blame these PMs for doing what they need to keep their job. Suck up to the people that will ultimately give them their paycheck.

The issue isn't the PM or shitty employees that aren't producing actual value, the issue is with the ego of the higher ups that rather keep people that agree with them on all things than have people who will constantly challenge them.

I have seen many CxOs (that aren't founders) who are very good at befriending the founders and thus they are more prone to survive. They are not necessarily doing anything useful to move the needle though, so this gives people the impression that the best thing you can do to survive is just be liked by the higher ups. Telling founders that they are wrong on a day to day basis because you work so closely with users and the engineering team, is not a good way to keep your job. If you are very smart maybe you can navigate this in a way that works, for awhile.

If my point is muddled, I'm saying that if you have a shitty PM it's because of the organization that employs people and keeps people based on the wrong criteria. Good leaders aren't threatened by getting challenged or feel the need to constantly get their egos validated.

Or maybe I'm wrong there too and it's just human nature to want to keep people that you always get along with.

With a good product and design team, I have been part of engineering teams that have 5 engineers than can do the work of 20, without working overtime, consistently deliver, and rarely, have to implement anything twice.

The difference between effective product and not is absolutely night and day. The best analogy is driving a modern car, vs driving a modern car without vehicle stability, anti-skid, power steering, automatic transmission, or AC. Sure you absolutely can drive it, but after a while you will need way more breaks than those who have all the nice features, and won't roll over in bad situations.

When The PM is doing a great job, it should be so obvious for the engineers what problems they need to solve next and understand why they need to solve it.

trivial and part of analytics and bug reporting that anyone can have a look at and it's the same job that the QA team does too which you are in contact with as a programmer anyway

> gather information from executives about what needs to be done to keep the company working

the boss tells you what to implement whether there is a PM in the middle or not

> gather information from industry leaders who may or may not be part of the company about where the industry is going

reading the news? I think everyone does it enough, it's not a hard job

> work with design

programmers are perfectly able to talk to designers, the issue is solely around who gets to make the decision. And I happen to believe that programmers should always be leading which is probably controversial and its own blog post but shortly summarized the reality is that programmers are at the intersection of the actual implementation, the design and all the decisions. They are in the perfect spot to make the call which features to do and which not to do.

> take all 4 previous points and distill them into what actually needs to be built for a needed feature

that's literally the job of programmers, to figure out how to implement something

> work with engineering to figure out what is practical, vs not, for building, and how long approximately it will take

once again, engineering is at the core of this and can do it on their own

> work with engineers to ensure estimation and team velocity is more or less predictable

this usually means that they want steady output on assigned issues and bugs which makes the job of engineers into a soulless daily issue list grind.

> Now if you take product away, each of the above gets distributed among the engineering team

Precisely, it lands there because it should land there at its natural intersection. The issue is that the engineers aren't given enough rights and decision making authority to make the calls so it becomes an awkward dance where you constantly have to ask for permission to do things because if you ever do something that the leadership doesn't like, you do get bad feedback. As Steve Jobs famously said and I'm paraphrasing: Once the engineers who actually make the products stop being at the center and the salespeople and managers take over it all becomes bad. It really doesn't matter how good a manager is, he will never be better than the guy who actually built the thing.

The reality is that a good PM would be advocating for engineers to be able to work on whatever things they want to work on, which is what never happens of course because that wouldn't help them. You can just look around in this thread: The PMs here all wanted to drive product direction, that's why they got into the job. Guess what every engineer went into the job for: They want to drive product direction too and they actually build the product. Who became an electrical engineer or programmer or game developer only to be told by some PM what to build? The PM is often not even really supposed to be his boss and yet it ends up being that way for absurd reasons. For utterly absurd reasons the PMs are given the ability to make product decisions even though they dont build anything and they aren't leadership. I've had PMs that were engaged, cared about making a product that makes sense etc. And yet ultimately the job is mostly around telling the actual implementors what to do while pretending that they aren't the boss of them but really, that's how it is because they talk to the leadership because what else would they be doing, of course half their job is to make sure that leadership does whatever the PM wants and they are generously given an entire job title just to talk to leadership and customers (which every engineer has to do too of course but with less time)

Just saying, you are over trivializing everything which in my mind leads me to think you haven't lead an engineering team or maybe oversaw one or two junior or mid level engineers.

A good PM should _not_ be advocating for the engineers to do whatever. If they are doing this I would be the first in line to recommend either re-adjusting their priorities and having a senior pm oversee them, or kick them out. A good PM is what creates the space for engineers to do their job, and a bad one will not wrangle the chaos into an executable situation.

I think the power of teams is not in individual contribution, but when the team is significantly greater than the sum of its parts.

Some people will often break the boundaries of those roles, though, and that's ok. They have ideas and might even come up with their own job titles. An organization must be smart enough to let that people grow and thrive. That doesn't mean one cannot thrive as a PM, or do great work; it's just that an organization usually cannot invest time in deeply knowing who they're getting onboard and so offer precooked roles.

Eng are capable of being PMs, but they will never think about everything from the PM point of view, because they are primarily engineers not PMs.

Something else I've realized in line with breaking the boundaries of roles is that usually, the most valuable aspects of a person's role are the responsibilities that are not explicitly defined. Hard to explain, but often people provide value in ways that are hard to describe and quantify.

Agree 100%, but this is where I've seen a lot of organizations fail, especially large ones.

I took, naively, a product manager job at one place I worked, thinking it would finally give me formal control over the product that I'd been previously asserting through influence - very successfully - in my client-facing sales engineering role. Of course as soon as I got in the chair I discovered it was a highly-constrained clerical job that I was completely unsuited to. Managing tickets and a backlog; coordinating decisions instead of making them; writing interminable powerpoint reports; the most creative thing was putting together a process for the company to follow in formalizing its product roadmaps. I lasted six months before running away.

The function is quite useful in supplying some visibility into what's getting built and in managing conflicting priorities for a growing product, but one thing it is not is shaping or controlling the evolution of the product in any way. It's a sorting, filtering, and (if you're lucky) a data collection function, producing an auditable decision trail and an impression of maturity in decision making which helps the MBAs higher up sleep a little easier.

My normal month has always consisted of creating anywhere from four to twelve unique proposals (PRDs) for new features for the company to build, with the number created varying based on the size of the company and the amount of process needed as a result. But regardless, it has always looked like: "Our users currently have X problem, and we should build Y to solve it. Y looks like this...". Yes this comes with some coordination and communication challenges, but those are always in service of figuring out what to build next.

I understand not all PM roles are like this, but I do disagree that PM never gets better than "sorting/filtering/decision maturity theatre". I am curious: if you were simply ordering an existing backlog, who was defining the new items to add to the backlog?

The difficulty was that the owners at the top had unshakeable ideas about what the product should be. That's ok, single minded vision can be good and all that. In my very hands-on sales engineering role I'd make things that my prospects were asking for, put them in the product, they'd buy it, and my prototypes and hacks and tools would end up getting refined, hardened, and supported by the implementation team. It worked well because everything I did had big dollars attached to it (so the org itself didn't mind) and the product advanced in a way that the market wanted.

The problems arose when we put in the product management process - the whole committee/requirement/signoff thing the article describes and I mentioned in my earlier comment. That created a formal bureaucratic mechanism for various players to stop all the ideas I had. Before, they'd be fait accomplis necessary for winning a big deal. Now they were just ideas divorced from value from some guy who should've known his place. Back then I was hopeless at understanding how to get a group of people with different agendas to agree on something (I think it's called 'politics').

> if you were simply ordering an existing backlog, who was defining the new items to add to the backlog?

It's over 15 years ago but what I remember is that there were thousands of semi-structured documents which represented things that, with the new product org, got turned into backlog items (stories, epics). This was part of an attempt to move engineering to a more agile way of working while creating a product function to support it. So it's more that we didn't have a backlog as such, then we stood it up and triaged everything we already had into it. All this was happening while the company was trying to learn about agile. I remember day long meetings where we all tried to argue about whether technical tasks belonged on a backlog, and if not how you could write a user story for remediating a piece of technical debt. Basic stuff but none of us had a clue.

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.

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.

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/

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.

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.

> Tremendous people envision alternative realities, fully commit themselves to their work, and move mountains with their willpower.

The last part is so reductive. It's not willpower moving mountains. It's the underlings actually making the vision come to pass. At most the "great person" is aligning the incentives to motivate the actual doers and experts.

My feelings so far are mixed. I've worked in PM-heavy organizations before and I agree that those suck. But at the end of the day there is some work that a PM would do that still needs to be done. In my org that responsibility officially falls into Software Managers and Senior+ Developers.

For example, if you are leading an initiative for your team as a Senior Engineer, you are in charge of doing all the activities that a PM would otherwise do. For other activities, the Manager or Senior Manager of the team is in charge.

Suffice to say that as a developer this sucks. Not only you need to deliver your own work as an IC, but you need to coordinate other people and ensure that things get done. Not only this is extra work, but let's be honest, many developers don't have the skills to be effective PMs. It also makes inter-team collaboration difficult, since now you have to coordinate people that don't share a reporting structure with you.

Often this approach results in lack of ownership, lack of accountability, duplicated efforts or things falling between the cracks, and general disorganization. That being said, it tends to work well for small intra team initiatives involving a few people, since it removes the overhead of a PM and places control in the hands of builders. But for larger initiative, I'm not quite convinced it works.

> Not only you need to deliver your own work as an IC, but you need to coordinate other people and ensure that things get done.

That for me is the definition of a senior/lead engineer

> Not only this is extra work, but let's be honest, many developers don't have the skills to be effective PMs.

To be fair, Many PMs don’t have the skills to be effective PMs

> It also makes inter-team collaboration difficult, since now you have to coordinate people that don't share a reporting structure with you.

As is the case for a PM

I think our core disagreement comes around “is it worth spinning off this part of the job to a dedicated role”. I happen to believe that’s nearly never true for engineers

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...

I view my job primarily as risk management. A great team of engineers and designers will face a huge number of risks to shipping great products, like not having the right skill set to articulate their vision to get others on board, or having lawyers impose requirements or restrictions on what can and cannot be done. My job is to manage that, to help bring out the best in the team so they can get on with the actually important work of building and shipping great products.

I judge success by how redundant I am. My goal is to not be needed, for the team to have the right context, confidence and support to make good decisions without me.

I love working with engineers to level-up their skills so they can do just this; I work with my EM partners to understand the strengths, weaknesses and goals of each engineer, and try and find ways I can help them progress.

In an ideal, utopian world maybe I’m not needed. I can understand that argument. But in most cases, doing truly great things will run up against challenges and risks, and a good PM works in partnership with their team to overcome them and is a net value add.

A good PM creates an environment where engineers like OP thinks the PM is not needed because “PMs do nothing” or whatever. It’s short sighted and frankly insulting

There is a function many (though not all) software teams need whereby someone understands customer needs, prioritizes them, and translates them into something that can be worked on by developers. We call that role "Product Manager". Do you strictly need an MBA who has some specific certifications to do that? No, of course not. A very strong UX researcher could potentially do it. A very strong engineering lead could potentially do it. But for many products, it requires a significant time investment in understanding the problem space, guiding a UX/UI research/design team iterating through solutions, and documenting it in such a way that a dev team could approach it.

As someone else commented, the article is just "Hiring bad leaders is bad".

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.

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.

This is different from the "Product Manager" at other companies which typically "owns" a product's direction and has authority over the people building it. That mixes project management with people management, politics, and worst of all, ego.

I never worked with an EPM at Apple that caused interpersonal problems. They all just wanted to fix bugs, figure out what we could and couldn't do in a specific timeframe, and release products on schedule. IMO, this is one aspect of Apple's organizational process that other companies should emulate, but I've never encountered it anywhere else. Maybe this kind of thing can only work at large companies that can afford to hire people for such a well-defined role.

Every company relies on the quality of its people. Every company puts people into positions of responsibility. Any company would suffer if people abuse or cannot handle their responsibility. So what? Is this some kind of insight? No.

Incompetence is a problem regardless of role, and it’s more of a problem with more powerful roles. The author gives no reason why “product manager” should be his special target.

The author seems to think the solution is… teamwork? Really?

That’s it. Problem solved? No.

This article is part of a genre that extolls the amazing power of the group without discussing or acknowledging all the excellent reasons why hierarchies are so immensely popular in industry compared to self-organizing hives.

Most articles on teamwork assume the happy path. Speaking as a person with skills, experience, and strong opinions— I know what it means to collaborate with difficult people. I am one. Any company that consistently thrives with an egalitarian culture must either be tiny or it must develop a sophisticated and sober culture of conflict management. Ironically, only with strong leadership from the top can that be done.