More product, fewer product managers | Hacker News Reader

More product, fewer product managers

kitemaker.co

418 pointsSigKill9305 comments

I've spent some time interacting with product managers as an engineering manager, or head of a functional area. I've also been "acting" PM for an internal product at a medium size tech company.

I think product management entails some of the most important things a company does. But it's really hard work, and many less capable PMs gravitate away from it and more towards either "driving" (i.e. micromanaging) the engineering team or just playing politics. In an organization with separate Engineering and Product functions / org charts this is really hard to deal with. You can complain up the chain of command, but bandwidth in that direction is (for natural reasons) very limited. As an EM the end result is often that these PMs make life miserable for your best engineers, and they leave.

My current view is that the best approach is to embed product management in the form of a "mini-CEO" (i.e. PM) in each team, and if they're not technically competent pairing them with a "mini-CTO". Much less room for politics, and much more for teamwork.

“Politics”

35 years in the semi industry. I must be stupid. I really don’t see politics. I see people trying to argue for their option and get support. But I’ve never seen this politics that people complain about. I’m so lucky I guess.

Is politics just someone making a better argument that is the wrong technical decision? What is “politics”?

Or am I just not at a high enough level (senior principal)?

Politics is what happens when you have limited resources and you need to decide where to allocate them. Politics are everywhere humans are.

Yes to this. Too many people complain about politics as if it is some “outside” force and not simply implicit in the way that human beings organize diversified interests. Since each of us can only embody our own world view, politics is inevitable.

I understand that what people typically mean is people who are “too political” where the pushing for interests stops being in service of some goal and starts to become its own point. But in trying to avoid the appearance of that, too many people fail to engage in any politics and in doing so actually cause more harm than good to what is important to them by missing the important point that it’s incumbent to speak up for things you need and believe in because people who allocate resources may have insufficient knowledge or insufficient time to dedicate to knowing your work that intimately.

Politics would be less of a shit show if people had intro textbook level knowledge about political science and/or didn’t approach it like a sport.

> I understand that what people typically mean is people who are “too political” where the pushing for interests stops being in service of some goal and starts to become its own point.

It typically doesn’t stop being in service of some goal, but rather becomes entirely self-serving.

That’s the good side of politics, and I agree: it is everywhere humans are trying to accomplish things together.

But when I say gravitate away from hard work towards playing politics it refers to something else of course. Getting others to do your work while still claiming credit is one example.

It’s not the good side of politics, it’s how it’s defined in textbooks.

I don’t think those textbooks attempt to define the concept in this context. Like it or not, “corporate politics” is a well established term.

Consider whether the stuff you’re thinking about is “politics” or merely “stupidity” or “malice” (or some combination of these). I see no need to mix up the words.

This is the grown-up answer that this thread is clearly lacking

But why then is it used as a pejorative? What you described is "engineering".

That's not at all what engineering is. Engineering is the application of science (including mathematics) to solve technical problems and/or optimize processes.

An engineer also has to eat lunch in order to function, but engineering is not the same thing as professional food critiquing.

---

To answer your question, it's pejorative because politics is about allocating resources one way or another, towards and away from particular social groups. It's inherently going to be making some of the people unhappy, 100% of the time. Real life politics also tends to not be done smartly and honestly at all times and in all places, and this can make some people upset as well.

Most people associate all of that together, and most people don't take an academic (or particularly analytical) approach to the subject.

Politics is a when a company like Caterpillar spends a year trying to acquire GPU's for their autonomous vehicle teams, because they have 20 security and project managers that want to assert themselves in every conversation to get promoted, to get to senior leadership positions, while the company looses out to Chinese competitors they were ahead of.

Politics is also when middle managers and 2 engineers conspire to steal a coworkers work to get promoted and move up the silicon valley startup ladder, so that the company has to come back a year later to bring back the original engineer, because none of these people were capable.

If you haven't seen politics you might have been either blessed or didn't want to see it, but for every 1 company I worked with that was efficient I worked with 4 that were not.

Good examples! :)

Politics happens whenever there are more than 2 people :). OP above must be really lucky to have not seen politics at all or one of those beneficiaries of politics who are like "Politics ... wut? nah"

It's possible you've never worked with politically minded people but I doubt it. It can be as small as an engineer broadcasting how hard a problem is before solving it. If they do that, they get the kudos for doing it. If they don't, it just gets done unnoticed.

Most people who dislike political people are failing to place the blame on the right actor. Sounds like this engineer has recognized how to get rewarded at their job and has adjusted their behavior to fit. The actual root problem is that this reward system fails to recognize the quiet everyday progress required to make something great.

In other words, in areas of limited resources where politics are innate, the squeaky wheel gets the grease.

The semiconductor industry actually does something. In web development it’s 100% political. Around 2018 it became easy enough to do web development at FAANG companies that there’s really no such thing as merit because even the worst employee is as valuable as the best.

You’ve worked for 35 years and you’ve never seen anyone act out of self-interest to the detriment of the project / company? Either you’re incredibly lucky or you’re blind. ;)

I'll take Blind for $1000 Alex. The self-interested people I saw were weeded out unless they made decisions that led to stock increase. In which case their self-interest was aligned with the correct decision. I don't call either one politics.

I think of politics as useless bickering that doesn't advance the project. Usually it is self-correcting for the reason above. I've seen a lot of bad decisions drive company's stock into the shitter, but I think of that as simply the "wrong" decision.

Shit, I think I -AM- blind. Hmm....

Politics in this type of context is fighting to the death over a single pie versus working together to bake a second pie. Some of this is necessary but when you only do this a company will not grow except through luck.

I'll give you one from personal experience, and it was in an academic setting.

My boss, whom I will call Boss W (who spent a lot of time maneuvering people around) had first worked for my previous boss, Boss F. Boss W, I think, spent more time playing chess than anything else. First he worked out a situation where he was peer to Boss F, then, with another coup, managed to get Boss F working for him.. Still not satisfied, he managed to change to whom the department reported to from Uberboss J to Uberboss C.

Uberboss C, who was peer to another administrative type, Administrator W, was eager to prove the value to the change. And so I was tasked with developing a product rather similar to something that Administrator W had at his previous job. The product itself was politics, in that it presented to a group of stakeholders about a thousand to three thousand items to decide the disposition of. But this was futile, really, because we had about six hundred thousand items to have reviewed, so we would never actually get anywhere with presenting this to the stakeholders. But they wanted it and so ...

And so I was told that this was going to be an Agile thing, and I had until the start of the semester to have it done, and they needed to see a fully-featured prototype (a contradiction) right away. Although promised, I never got to meet with the internal stakeholders who would present this product to the external stakeholders who would do the disposition.

That's quite a tight deadline, but it gets interrupted because to prove value to someone else, I get sent on a week-long conference doing something utterly unrelated. They just wanted to prove to the guy running Dept B that they were going to have someone in the mix for his technology.

Despite this and catching a tremendous cold, I managed to have something developed by the start of the semester, because it was so very very urgent.

And then it was not shown to the internal stakeholders for seven months. All o that hustle! So Agile much wow.

I don't believe in Product Managers or Project Owners as a net good towards building a better product or a better company.

The most successful teams I have been in had no dedicated product role, instead, all decisions were made by the developers.

My current view is best to remove all type of non technical people or even mildly technical people from the developers' way and let them build in peace.

In that scenario, who is driving product requirements?

For example, in an area with strict financial/regulatory compliance laws, are you expecting every engineer to be an expert in those laws? And have contacts at the government agencies implementing those policies?

Engineers should ideally be working directly with in-house counsel or external specialists under these circumstances.

This isn't just applicable to some niche organisations working within e.g. finance (though there's likely to be a higher regulatory burden there), engineers need a basic understanding of something like GDPR to do their job because it impacts every organisation handling personal information in any form.

In extremely regulated environments you would typically have someone with legal background to boil down the requirements into their absolute essence and give them to the dev team.

So you DO have a product manager. You might not call them that, but that’s exactly what they’re doing.

That's not a product manager. That's a domain expert. You might have to check some regulatory checkboxes:

- financial

- medical

- data protection

and you might need different experts' opinion for that. Do you suggest that they are all product managers?

Good product managers I've worked with are better than me at navigating the domain and compliance worlds as tourists as they are tourists in the engineering side as well. David Ricardo was right, comparative advantage is a good thing.

If I consult a solicitor about data protection regulation and they tell me what I need to build to satisfy the requirements of soft opt-in under PECR, that does not make them a product manager!

No, but it's something a good product manager does for you, and with the economy of comparative and potentially absolute advantages. This let's you focus on the craft of delivery without encumberance of spending research into compliance.

I don't consider the engineering having a deep understanding of the domain and compliance to be a "encumberance". The more engineers get into the domain themselves, the more they can make deep decisions about how to build the most effective solutions.

> This let's you focus on the craft of delivery

I don't give a rat's ass about the craft of delivery! What a reductionist thing to think of engineers as "delivery machines". Me and my team mates are not a factory that simply takes input from a task master and produces code to their bidding.

I care only about one thing: solving the problem! That encompasses learning, understanding and, finally: delivery. To do that, I need to speak to stakeholders MYSELF, I need to see how they are using the product MYSELF, and any regulation I am gonna implement, I need to understand in depth. I don't need somebody to summarize findings for me, I can make my own damn conclusions.

Sure, I will ask the domain experts of their opinion, but me and my teams will decide what to build, when, and how, and do we will do it together, based on all our shared learnings, not based on what a PM told us.

> I care only about one thing: solving the problem!

Who prioritises the problems?

The developer teams, of course. They are solving the problems, so why should they not prioritize them? They just need to have other parts of the org heard, but if you are solving it, you get to choose how to do it, in what order and with what priority.

If that's not to somebody's liking, they are welcome to prioritize and solve the problems themselves.

What area of insights does the development team need to be able to prioritize for better utilization of their product?

---

> If that's not to somebody's liking, they are welcome to prioritize and solve the problems themselves.

Ah, I see. There is a concept known as a separation of concerns that prevents this on most teams.

There is a good saying for complex service delivery that most developers operate with in application development and support. If you want to go fast, go alone. If you want to go far, go together. That "together" brings more skillsets that most small engineering teams have on staff, and is typically not beneficial for them to focus on gaining.

> if you are solving it, you get to choose how to do it, in what order and with what priority

In times of plenty, this works, and I think it can have high velocity. Especially with very small teams that all have high levels of direct investment in the result.

There are also times of famine, however, and the work that keeps the lights on is often not work that even invested software developers want to prioritize. When making money is on the line, there's always somebody who's there to make you eat your vegetables. Who, in your conception of the problem, is that?

> and the work that keeps the lights on is often not work that even invested software developers want to prioritize.

What kind of work is that? And why are the developers willingly not wanting to prioritize it, if the alternative of not doing it is becoming jobless? Do we need some kind of PM figure to say things like: "If we don't make this feature for the client, we are doomed, so start coding. Chop chop!". And do we need to keep that guy on the payroll for simply relaying a message?

> Do we need some kind of PM figure to say things like: "If we don't make this feature for the client, we are doomed, so start coding. Chop chop!".

Yes, and yes! I believe you're starting to see. Good management has value. Even if that is to deflect invalid criticism for devs.

Right - like, you'd think it's obvious that of course you'd just do the right thing. But developers are expensive and market research, talking to customers, planning for the future, etc. becomes rivalrous to building things. And that stuff is generally much less interesting, so without compulsions to solve those problems, they frequently then don't get solved.

"But if you don't do these things, the company fails!" Yeah, and look at all those small, engineering-heavy companies that do exactly that! And further--eventually, as you scale you reinvent division of labor because as much as we like to kid ourselves, software developers are not, universally, better at doing everyone else's job. (If you find yourself in a position where you are better at doing everyone else's job, you should probably find a new company to work at.)

> They are solving the problems, so why should they not prioritize them?

> If that's not to somebody's liking, they are welcome to prioritize and solve the problems themselves.

There's two types of problems that developers solve. Problems that they, themselves created (oh no, I wrote a bug), and problems that are given to them.

The second type (traditionally, the "business problems") are being prioritized and solved by the people who care about them. Namely, the CEO and the exco. Those guys set overall strategy, culture etc. and then the delegate the implementation and some of the detail to people with more expertise.

Developers do not run the business. They are delegated to to solve specific problems in the context of running the business. Not all of the business' problems will be solved by developers, but all of the business' problems should be solved in a coherent and harmonious way that accounts for the context of all the other problems in the domain (market, regulatory, finance & tax etc.)

For a specific product, the place where this context is managed is usually by someone wearing a hat with "Product Manager" written on it.

Until you inevitably have a question and they need to get in touch with the expert again

Middle men only improve transfer of knowledge between people under very specific circumstance. Usually they just make things worse

Let children play Chinese whispers, I don't need that in my life

If the PM does that, the developer has no idea what part of the requirements is important, and won't be able to deal with it when the requirements unavoidably break each other or reality. The developer has to be there too.

I work in one of those environments and we do have those people (lawyers). The next question is how should we prioritize solving for potential legal risk vs reliability risk vs new feature work. You’d expect it’s black and white, I promise you it’s not. The PM has to figure that out.

> In that scenario, who is driving product requirements?

The developer teams, who else? You build it, you need to know what you are building, right? I find it fascinating that the dev community that gobbled so easily "You build it, you run it", doesn't question why we are not being trusted with knowing and determining what to be built in the first place.

> For example, in an area with strict financial/regulatory compliance laws...

How often do you have a Product Manager who is an expert in regulatory/compliance laws and has contacts with government agencies?

Usually the Product Manager is Josh, who just finished uni, and a two weeks product manager course. They will have to ask experts, and then translate that to the devs. It's much more efficient to let the devs ask the experts, which will let the devs themselves become well versed in the domain over time.

I happen to work in a highly regulated industry, and we have an in house law expert, and an in house medical compliance team.

None of these roles are embedded in the development teams though, they are simply asked for advice rather than manage the engineers (which would be insane).

That is how it should be.

Every time I’ve worked on financial aid, HR, or financials, the PM has been an expert in those areas. I couldn’t do my job otherwise (or, I have to fill their shoes).

I work in the medical field which is fairly heavily regulated as well. My teams have been able to do our job without having a dedicated medical compliance expert as their PM.

We just have a medical compliance team and ask them for input, but they most certainly don't tell us what to build nor drive the product direction.

In short, I question the need of a PM, not the need for domain experts (law,financials,etc).

If you've had good results without a PM you probably had someone who was doing that work, but under a different job title. Or the results weren't as good as you thought.

Good PMs are often engineers or ex-engineers themselves. But a good PM will do a much better job than just sticking a bunch of engineers in a room and asking them to manage the product. A lot of developers really hate tasks like:

- Designing UIs

- Thinking through complex workflows to simplify them (unless they're developer workflows)

- Writing documentation

- Often also, identifying and fixing small quality issues like bad error messages

- Figuring out what the customer's actually need vs what they say they need

Some devs are naturally talented and capable of doing all the above, plus banging out the code too. That's great, maybe they don't need a PM or more likely maybe they will become one themselves in future. But left to their own devices a lot of dev teams will rapidly lose the plot and start producing features nobody cares about, or doing endless refactorings, or produce something that's too hard to use.

I kinda like doing those things

Why does the domain expert have to be the PM versus someone the engineers consult directly?

Why shouldn't engineers consult with a PM? Isn't that a key part of the role - to break down external requirements into engineering needs?

Yes!

But imagine if the developers themselves could break down the external requirements into engineering needs!

Or are developers grug brains that need a bigger, superior brain to simplify scary real world into simple, safe engineering needs? Or developer grug so busy, must write code, no time look at feedback form, no time think client request, need simplified instructions, must slap keyboard, clack, clack?

Context: https://grugbrain.dev/

Breaking down requirements and being the domain expert are not the same role. Engineers can break down requirements perfectly well given they have context of the code and systems and possibilities. A even bigger advantage is that there are multiple developers on team which means they can review each other's work. Just like a lone dev tends to go off the rails eventually so does a lone PM and almost all PMs are lone if they're the sole domain expert.

> The developer teams, who else? You build it, you need to know what you are building, right? I find it fascinating that the dev community that gobbled so easily "You build it, you run it", doesn't question why we are not being trusted with knowing and determining what to be built in the first place.

Absolutely this. And the engineering teams should have visibility of customer support and other functions to understand common pain points, causes of churn and opportunities for additional revenue-generating functionality. That doesn't mean answering run-of-the-mill questions or doing refunds all day, but it does mean talking to prospects, looking at escalated problems and keeping an eye on the wider industry.

This. Most of the developer teams are nothing but feature factories. There will be a point where what developers want to build and what the product needs will diverge. It is very hard to strike a balance IMO.

This tension is why it's a good idea to align everyone's incentives.

Bonus the product team on reliability (as well as velocity), and the ops/sre team on feature velocity (as well as reliability), and it'll balance itself out.

Who is bonusing who?

I think some people simply can't get rid of the idea that there has to be some external paternalistic figure that looks over developers' shoulder and guides the poor hapless saps and their incentives. Do they give candy to the good boys/girls and coal to the bad ones? You might be thinking of Santa.

The developers and sre's incentives are the same as everybody else in the company: have a great, easy to sell, popular and reliable product. Management types insisting to compartmentalize incentives is them trying to have an excuse for their own existence.

We should all drag ourselves kicking and screaming to the reality that we can do much more with much less management layers. Even big companies, which are bloated beyond saving, are waking up to that fact. PMs are the first to go, just look at what Meta, a notoriously inefficient company is doing to their non technical PMs.

Think for a second why nobody has had the idea of letting an engineer be a 'Marketing Project Manager' of the marketing team and be calling the shots what campaigns to run, what marketing materials to produce, and make marketers estimate with poker cards how many of their leads will turn to a sale. Sounds stupid, right? Yet this is exactly what you want us to accept the other way around. Not gonna happen.

There is no excuse to have non engineers embedded in and actually calling the shots on behalf of an engineering team with the patronizing though that the engineers can't decide for themselves what to build and how to prioritize it.

> The developers and sre's incentives are the same as everybody else in the company: have a great, easy to sell, popular and reliable product.

The hard part is how do you design a compensation package for a developer or sre worker bee, to incentivize these? How do you make their bonus depend on something as nebulous and hard to measure as "greatness" or "popular"?

For most employees, the candy/coal model works. You're not going to find low-level individual contributors who work because they just want to make a great product.

I might verging on socialism here, but I think the best way to motivate employees is ownership of the company and direct profit sharing.

Unfortunately, only the first part is practiced in my organization (company shares), but I am actively fighting for the second.

That’s what dividends should be doing, right? Or do you want the holy grail of percentage of gross revenue which is so outrageous to everyone only payment processors charge it because they can?

I'm going to part with the accepted dogma to say that I don't think that equity ownership motivates workers towards doing a good job, at least at large companies. If you are engineer number 54,291 moving a protobuf from one layer in the stack to another, nothing you do is going to move the needle on the stock price, either positive or negative. You could write the best, most efficient code, fully unit tested and crash-free, but if Morgan Stanley downgrades the company's stock because of some bad earnings call, it's going to go down.

I have equity as part of my comp package, and I know there is zero link between how good a job I do and which way the Wall Street Wind blows today. So to me it's just like cash but with extra steps.

Maybe it's different in the startup world, I don't know. The only startup I was part of, everyone's equity went to zero when the business failed, regardless of how well anyone did their job, so I'm not much of a believer.

> The developers and sre's incentives are the same as everybody else in the company: have a great, easy to sell, popular and reliable product.

Being on a team where everyone has a high level of personal ownership and accountability like that is truly wonderful, and I agree, it works great.

You just have to find (or build) a company that explicitly filters out the 99% of people who only want a job for the paycheck and don't care about the customers, the software, or the product.

It seems like you're arguing that the dev teams should spend some of their time managing the product. In other words, it's a 'hat' to be worn occasionally by some team members.

Nothing wrong with that, except what typically happens at larger scales is that some people enjoy wearing the hat more than others, then the team realises that it's better if those people spend most of their time doing product management, and then they tweak their job titles ever so slighty....

> How often do you have a Product Manager who is an expert in regulatory/compliance laws and has contacts with government agencies?

In my (highly regulated) industry, always? They'd be bad at their jobs if they didn't have this.

Edit actually, I walk that last bit back slightly. They don't need to be experts in those things, but they need to know enough about the broad landscape to understand what tradeoffs need to be made and set direction. Similar to a CEO not needing to be an expert in product, marketing, engineering, finance etc. to be effective, but they do need to have enough knowledge to know how to balance competing requirements across these things.

Sounds like you haven’t had a good PM or a job that supports having one.

Saying it’s often some new grad is like saying there’s no point having an on shore dev team because the devs are often fresh out of university. If you continually hire terribly you’re going to have a bad result.

A PM should become the subject matter expert in the product they are developing. They should be able to field questions on most every part of it, and be able to build a roadmap of features. Communicate with all teams associated with it. Having the programmers plan all features is a recipe for disaster if your product isn’t designed for developers. It’s like saying you don’t need a qa team because the developers tested it.

>It’s like saying you don’t need a qa team because the developers tested it.

Strangely enough, that's happening at a few companies (run by Amazon refugees IIRC) where they think that making devs do QA and removing QA/QE roles will speed delivery. I'm in one of those companies now, and I'm waiting for the #FAFO loop to happen.

That really depends on what does QA entail at these companies. If it's just increasing test coverage and adding integration tests then yes, devs should be doing it.

If it's just clicking UIs all day long then obviously a QA should do it. Or have an UAT environment where a few more enthusiastic customers are willing to test and report bugs.

It's more than that. In an org with an architecture of silo'd teams that all work on their own independent federated services, you'll need people to test out all of the variations on content, timing and error handling for the software as a whole. Depending on automated testing to handle all of that, in a live environment, is a fool's errand no matter how much it makes the development cycle seem to go faster.

I can most certainly and confidently tell you that a dedicated QA team that only does testing is a total waste of money! A sre/platform team building fuzzy testing tools and mandating better testing practices is money much better spent.

The developers MUST care for the quality, not outsource it to some external team. The desire of large corps to spend huge amount of $$$ to create artificial roles to water down ownership can never cease to astonish me.

If your devs can't think of handling nulls or corner cases, you got a skill problem, and you should ASAP upskill the devs, not outsource thinking to another tea.

Making quality somebody else's problem is the exact opposite of ownership! You want agile? Damn leave the devs alone, stop building walls around them and the product they are building!

>The developers MUST care for the quality, not outsource it to some external team. The desire of large corps to spend huge amount of $$$ to create artificial roles to water down ownership can never cease to astonish me.

As a former quality-focused dev, I can tell you that the industry beats it out of you with a club. There is always somebody above you who cares only about their own career ambitions and has more leverage than you do. This leads to a horde of devs who just do what they're told and not much else.

Businesses are all about risk management. The safest way to de-risk a business is to water down ownership, at the cost of injuring quality-focused devs. You're only a cog. You need to only be a cog to them. They must to be able to replace you with another cog when you leave for greener pastures.

  > I can tell you that the industry beats it out of you with a club.

yep, i can say i've seen this over and over; more than anything incentives are for the next okr or whatever to be completed so they can move on to the next one asap.

i've seen pr's sent out for review that literally didn't work or crashed immediately on use... as if the expectation is qa will report whatever needs fixing but thats fine cause its "in qa now" so development is "done".

That’s just Goodhart’s law.

"When a measure becomes a target, it ceases to be a good measure".

I don't disagree with you, I've seen the same (a lot) but you can still go to another company that prioritizes quality a little more.

Definitely can take a while to find one though, that much is true.

> advocating for better <topic of choice> is money much better spent

That seems like a very Bay Area mindset - advocacy is more lauded than doing something.

Fair enough!

I used "advocating" loosely here. I hate the "advocate a lot, build nothing" mindset myself, and I am not a fan of the Bay Area and its practices (to put it mildly), so I edited my post.

What I mean is devs making tools for devs, resulting in better overall quality.

Sorry, that was a bit to snarky. While I don’t agree with not having dedicated QA, I completely agree with devs being responsible for the quality of their area and adjacent areas.

In my experience good test engineering teams can focus on having a more global view of systems while not being biased by implementation details.

You are so right on the QA thing and so wrong on the PM thing. If you have a PM that just came out of uni, your company has no idea what they are doing. Good PM's are really really good at communicating at multiple abstraction levels within multiple levels of the organizational hierarchy. Why? Because they have to build consensus and coalitions to get the things ( money, people, buy-in, details, information ) required to build really good software and build all the ancillary things to sell and support that software. I think what you are calling a PM is what I call a jr. project manager.

> How often do you have a Product Manager who is an expert in regulatory/compliance laws and has contacts with government agencies?

> Usually the Product Manager is Josh, who just finished uni, and a two weeks product manager course. They will have to ask experts, and then translate that to the devs. It's much more efficient to let the devs ask the experts, which will let the devs themselves become well versed in the domain over time.

I have definitely seen this happen, but as a very senior engineer, now PM, I can tell you this is a management/hiring failure much more so than anything else. I have long advocated that PMs /must/ be technical to be successful and, maybe more importantly, useful.

If you’re in an industry that is compliance encumbered, you should absolutely expect that your PMs are experts or at least professionally competent in the compliance standards you need to meet, or at minimum intellectually and contextually capable of getting there rapidly.

Hiring someone just out of college to be a PM is a huge red flag that your organization doesn’t understand the role of a PM, and that your upper level management is likely incompetent also. Without significant prior experience in some related facet to the product, it is not possible to be successful as a PM, and I wouldn’t expect a new grad to be able to do much more than push papers. PMs should always be former practitioners, if possible, but at least technically competent at minimum.

I agree with your comment and upvoted it, though this part:

> I have definitely seen this happen, but as a very senior engineer, now PM, I can tell you this is a management/hiring failure much more so than anything else

Makes me wonder if you're saying that these cases are the exception. In my career they have sadly been the rule. Not 100% literally, i.e. my PMs have never been 22 years old, but they were, 99% of the time, grossly incompetent.

And yes they were a management / hiring failure, absolutely, but it seemed that nobody cared... :(

Devs generally don't want to talk to the experts, they want to build. Talking means more meetings, which takes away from building. Ironic, as without knowing what to build, they can build nothing.

Ah, yes, avoid meetings with experts so you have to wait until a non expert who talked to the experts tells you what to build! Pesky, asocial developers, avoiding talk at any cost!

It's a well established fact developers love building things so much and hate wasting their time with useless meetings! The hero PM saves the developers so much thinking by being brave and talking with the scary outsiders.

The PM's selfless bravery gives the developers the time and space so they can focus on the really important part of building. The really important part of building is, of course, being in a 2 hour meeting where the PM is repeating (badly) what the experts said, and making you play card games where you pick some numbers, very much unlike a nursing home for the old playing bingo.

I love your take! You totally treats engineers as responsible adults who have multiple skills and abilities besides coding, and not at all like autistic children that would flip out as soon as somebody touches their crayons.

The assertiveness of your replies implies to me that you never worked in big companies

> It's a fact developers love building things so much and not wasting their time with useless meetings!

Correct. Most engineers dislike meetings, so much that they complain that they don't get enough focus time in the day and are constantly interrupted.

> like autistic children that would flip out as soon as somebody touches their crayons

No one said this, you're arguing against a strawman. But even still, how many devs do you know that willingly want to talk to customers?

How often do you have a Product Manager who is an expert in regulatory/compliance laws and has contacts with government agencies?

Maybe not an expert, but literally every project I've been involved with where those things are relevant, the PM knew more than most of us, knew who to talk to, and was responsible to make sure we did the right thing. It is pretty much what half the role was about. They were often pretty senior people with long experience working in a relevant field.

The PMs I’ve worked with have had many decades of experience in the area of their product and knew much more than our dev team about the business domain

I agree with the point you’re making. I wonder if there’s a disconnect here based on the size and complexity of some of the businesses different commenters are working in.

Probably. My employer has >5000 employees, ~2500 of whom are in the CTO org. We serve an international market, so there’s simply no way for a team of engineers to deeply understand all the regulations that impact their area.

I think a major complaint surfaced about the PM role is: Its rare for even your PM to be an expert in that area. Ideally, they should be. Realistically, there's one guy in another branch of the company with a totally unrelated title that everyone eventually figures out is The Guy on this product domain; and the PM's role becomes "interface with Jim".

I don't generally find myself in the Anti-PM camp; but I think one of the valid criticisms of the role is that high quality hiring for it is so extremely difficult that maybe its existence is an indication of a structural problem. As the article says; if the ratio of PMs to Teams should be less than 1:1, maybe the correct lens to view this role through is more of a higher-level product lead, or a separate product branch who act more like free agents that attach themselves to teams temporarily, splitting time, where needed.

I will say, I've worked in two roles where this was the case; one a very large public tech company everyone reading this would recognize, and another a 30 person startup; giving PMs higher cross-team authority felt, to me, like a really good decision. One small positive byproduct I actively observed: when speaking with our PM, who was shared with four or five other teams, he was constantly aware of all the other work they were doing, and would actively make recommendations about how our little feature could plug-in with their little feature to increase the quality of the overall product. One small negative he communicated: because the company had no entry-level PM roles, which is where he started before they refactored the org chart, its non-obvious how you backfill these roles or create an entryway for new talent to breach the industry. Their current solution to this is "well, we can't really promote internally unless an EM or Engineer wants to switch domains" which they genuinely did try to support.

What was the product being built.

What type of product was that successful team working on? I believe this can work wonderfully if the developers are close enough to the user, eg: building a tool for devs like github.

But if the product and the users are alien to the developers then this is a recipe for poor UX and value (eg: building an accounting product)

The best PMs I’ve worked with were HIGHLY technical, either in the same areas as the developers or in adjacent areas, like product design, or the domain of the product

PM for retail company did long stints in merchandising at Costco

PM for spreadsheet company was a former banking analyst

Most companies hire under qualified generalist PMs who have to learn everything about their market from scratch; it’s very challenging and prone to outright failure.

Hire fewer PMs, and make sure they bring a key skill to the table. Let Microsoft and Google train the juniors.

Pffft, they train the juniors? Hahaha, that’s funny.

https://careers.microsoft.com/v2/global/en/students

https://www.google.com/about/careers/applications/students/

Sounds good in theory, but what if your company decides to reduce investments in the spreadsheet product and instead transfer the product team into a much faster growing product segment, e.g. SAP integrations?

Then the perfectly qualified PMs start from square one again.

IMHO it's an essential skill for a PM to familiarize him/herself with a new domain in short time. It also offers cross-pollination / the chance to do things different. Imagine Steve Jobs coming from a pure IT background instead of liberal arts / calligraphy -> Apple wouldn't have been so different any more.

> Sounds good in theory, but what if your company decides to reduce investments in the spreadsheet product and instead transfer the product team into a much faster growing product segment, e.g. SAP integrations?

> Then the perfectly qualified PMs start from square one again.

Exactly the same point holds for programmers: what if (say, by becoming acquired) a company has to switch from being a, say, a Deno/Vue.js shop to becoming a Java shop? Exactly.

So the answer is: don't do such radical changes in the product portfolio and way of doing work if you don't want the employees to more or less to start from square one again.

Note: "were HIGHLY technical".

They had the ability to learn technical things once, then they can do it again. (In a short time? Not so easy to find out until after you've hired them, in any case?)

The time constraint matters. A lot.

1000% this

Spotify, if you’re reading this, hire someone who listens to podcasts for your podcast feed in app.

I feel Spotify doesn't do anything they don't want to do. Most changes (especially) in the Podcast function are baaaaad. I switched from Podcast Addict to Spotify (already had it for music), and I ended up to stop updating the app, because I dislike more and more every update.

The insult to that is also "no changelog". I hate the generic "we try to make it better, but ain't telling you what". So at this point it's a gamble whether I want to update or not, so I don't.

Also for Spotify, perhaps it's time to allow a pool of 1000 (?) volunteers from each language to help you rewrite titles, names, etc. in the local languages. I'm happy for the latin alphabet, but do make a "local language" field and then let the users see THAT instead of the common if they choose to.

And someone who has ever used (including caring whether it be off, not just on) to work on shuffle and Smart Shuffle.

I spent at least the first half of my career working with non-technical PMs and thought they were useless. I then joined a company where the PM was a former C++ game dev who was on several credits of some of the biggest games of the 2000's. He was an absolute joy to work with. He understood issues that we faced, he warned us of pitfalls to certain approaches, he greased pathways for us in upper management. I consulted with him when I was trying to decide whether to take a PM role.

I don't feel that an organization like that is the best way to run a company. It may be a superior way to the reality of most companies today, but that reality makes achieving an environment like that extraordinarily difficult.

Here's the reality I've seen: PMs and EMs share a very similar domain of responsibility. The "20% work" of both jobs is different; but 80% of it isn't; its communication and defense from the rest of the business, and organizing the work the engineers need to actually do. Who actually does it, in your org, the PM or EM, depends on who has more political capital between the two, which is something of a function of their skill level, experience, and ability to market themselves. Great EMs look like PMs. Bad PMs do all the bad things bad EMs do, like micromanage.

Phrase that paragraph another way: in most orgs, in my experience, the PM role fills a need which arises when the team makes a sub-optimal EM hire, and vice-versa.

That's my reality; but the obvious problem with that reality is, if you look at the scientific, hypothetical definition of what a PM should do, its not that. There's tons of more product-focused "we want to build the best thing" kind of work that feels, to me, rare for even Fantastic PMs to actually get to do because they're compensating for an EM that isn't pulling their weight. Vice-versa, if you have a Bad PM it might not even occur to them that this "we want to build the best thing" class of work is a fundamental part of the role; ZIRP document factories that could basically be replaced with an LLM trained on all the meetings they've attended.

The additional lingering problem is that, part of that 80% work, "defense against the rest of the business", depends significantly on the rest of the business stepping back and creating an environment where this "unit" (the EM, PM, and engineers) can be autonomous; and I've also nearly-never worked anywhere where this was the case, even leadership that says "its y'alls call, you've got authority in this domain" inevitably catch wind of some decision they dislike, for reasons rarely more substantiated then "it feels wrong", and even a small number of torpedoes like that can seriously, seriously harm an entire team's feeling that they're allowed to go on of the offensive, rather than playing defense 24/7.

Point being: The single best characteristic of upper leadership, its not close, there's zero argument of this in my mind, its not technical ability, business experience, good talking skills, domain experience, whatever: Its Hiring. Being able to identify strong talent, keeping a pulse on the performance of that talent, ground-truth, all the time, and being willing to let people go if mistakes are made. But, what I've just described is extremely difficult to execute effectively, because every actor in this game is self-interested and will actively misrepresent the performance of themselves and their unit; politics is the hardest game in the book.

I don't understand, how do you handle prioritization decisions: if you have a 100+ customers that all want something, how do you create understanding of all needs, how do you distill that to an integrated roadmap, and how do you align the roadmap prioritization decisions across 20+ teams?

How do you organize updating of documentation, training materials, enablement of support, pricing decision, updating of price lists, enablement of sales, presales, and customer success teams? How do you manage the input towards analysts like Gartner, that have a big impact on the decision process of your customers?

How do you evaluate the offering of the competition compared to your offering, how do you determine where you should be in 1,3,5 years to have a competing product in the market?

Most PMs are mostly concerned about what should be built to create a valuable product for customers, that provides healthy stream of revenue for the company. Most developers are concerned about how it should be built. That is a completely different responsibility.

By knowing the customers business and needs better than the customer, and be able to convince them that the best product possibly conceivable is not a Frankenstein’s monster put together from “100 ideas gathered from the costumers, prioritised by a PM”, but an opinionated tool created by opinionated people.

Of course you need the right developers for this, not code monkeys or offshore outsourced companies with a time zone and cultural barrier to overcome…

> I don't understand, how do you handle prioritization decisions: if you have a 100+ customers that all want something, how do you create understanding of all needs, how do you distill that to an integrated roadmap, and how do you align the roadmap prioritization decisions across 20+ teams?

That does seem to require at least a PHD in prioritization or a totally real role like a Product Manager indeed! A naive approach would be to make a spreadsheet with the names of the clients, their current and potential monetary value, group the issues by the corresponding teams and themes, and let the teams ask additional clarification questions to the clients so they can prioritize. But yes, I can see your point, a PM guy called Josh with an bachelor of arts degree indeed seems more qualified to do it than a bunch of software engineers, and make the better decisions. I dunno what I was thinking.

> How do you organize updating of documentation, training materials, enablement of support

A naive approach would be to have a frequently updated knowledge base. However, I understand that Josh and his arts degree make him the best at producing/updating of documentation, training materials, and enablement of support, so probably...Josh?

> updating of price lists, enablement of sales, presales, and customer success teams?

Sales + developers + finance sitting together? Shared company view of the important client metrics? Nah, Josh will do it.

> How do you manage the input towards analysts like Gartner, that have a big impact on the decision process of your customers?

Marketing departments? But I have the sneaking suspicion Jake (or was it Josh) is a better candidate.

> How do you evaluate the offering of the competition compared to your offering, how do you determine where you should be in 1,3,5 years to have a competing product in the market?

By analyzing competition, thinking forward and having a vision. Are developers supposed to only think on the benefits of mysql vs postgres?

> Most PMs are mostly concerned about what should be built to create a valuable product for customers, that provides healthy stream of revenue for the company. Most developers are concerned about how it should be built. That is a completely different responsibility.

Let me float a crazy idea out there, I hope it doesn't sound too far out, I am just trying to dream out loud. Because I believe that if we dream big, then everything is possible.

Hear me out... How about, maybe having developers concerned BOTH about what should be built and how? I know this is too radical, and we would probably need first to have that notion reconciled with mainstream physics, mathematics, and fluid dynamics, but it's just a crazy thought I've been having.

Just imagine a universe where engineers not only execute instructions from people with suits, but actively decide what to build themselves. Of course, that's science fiction and can't possibly be achieved, but just imagine!

P.S Sorry for the patronizing tone. I just think the industry got it really wrong as a whole, and that we can build far better things and far easier if we treat engineers as adults who know what they are doing. The existence of a PM (or PO) role for me is the opposite of treating devs like adults.

Almost every PM I've worked with had an engineering degree and/or previously worked as an engineer. This "Josh" sounds like a strawman or you've had bad luck with PMs in the past.

It also sounds like you have a PM on your team, but they actually have the title of SWE or Eng. Mgr. They probably spend > 50% of their time on the above listed responsibilities rather than engineering. Hopefully they don't get docked in their performance reviews for essentially performing the duties of a PM rather than those of an engineer.

I am very much for any SWE or Eng. Mgr taking responsibility and spending as much of their time as they see fit on anything they see fit to build a great product. Not only that, but I will encourage them to continue doing so and give them a great review score and potentially a salary bump!

> Performing the duties of a PM rather than those of an engineer.

The duties of an engineer are to know what to build, prioritize it against their other work, and build it, alon with the other engineer in their team. If you consider the "knowing what to build/prioritize" as PM work, so be it. I consider it engineering work.

most PM's will have worked < 5 years (typically 1-2) before moving onto the PM track.

There's a world of difference between a senior developer and what these guys are, and you want your senior developers making these calls.

PM is not a junior type of job for someone called josh. In my experience it’s a full time job, requiring experience in the customer problem domain, and engineering experience.

> By analyzing competition, thinking forward and having a vision. Are developers supposed to only think on the benefits of mysql vs postgres?

No but they are vastly different expertises. And in the time that engineers make decisions on databases, architecture etc, the PM can already do discovery work. Surely you can find engineers that also enjoy this, and are good at it, but someone has to wear to do it.

You time and time again portray the PM role as a junior thing. But it is quite hard to keep everyone focussed on “is this really the quickest way we can deliver value”? You don’t need a degree for it, but you need a certain level of confidence and seniority in most teams.

Saying that having a PM is like treating devs as kids is the same as stating that having a marketing department is the opposite of treating sales like adults. Shouldn’t they be allowed to find their own leads?

I can definitely see how this is appealing for small technically oriented teams that want to move fast. It is likely however that your team will reach an inflection point and at some point having a *good* PM would be a net positive to the company.

The worst products I have ever seen were when the developers acted like product managers. What you end up with are a bunch of really cool stuff that no one wants to pay for and only a few people find utility in.

Could you elaborate on what you mean by that? Is it the standard scope creep / premature generalization pattern, or something else?

If I had to guess, it's a lack of adequate market research.

It's because engineers will build what engineers want rather than what the customer wants. Engineers are more likely to appreciate highly technical details that average customers don't even understand, let alone want to pay for. There is also likely a disconnect between what it should be able to do versus how easy it is to use.

Engineers are likely to solve problems that the customer doesn't care about. If you know engineers that say things like "the customer is an idiot" then you understand what I'm talking about. Even if the customer really is an idiot that is the person who needs to use the product.

> It's because engineers will build what engineers want rather than what the customer wants.

I’m not sure you can generalize like this. Do the engineers have RSUs or financial incentives where they do better if the firm does better? I’d argue they’d care more then. Also, a lot of engineers intentionally chose to work in market segments they’re passionate about. I’ve been at the same company for over 13 years. I could likely make more elsewhere but I find the domain I work in quite rewarding and interesting.

> have RSUs or financial incentives where they do better if the firm does better?

They have a larger emotional incentive to work on cool things that they enjoy, as opposed to the relatively small change in company price if their individual product succeeds or fails.

Not the OP, but I think my comment here [1] might be a good example of what the OP means

1] https://news.ycombinator.com/item?id=25975417

"most successful teams"

For what definition of success, and at what point in the product lifecycle?

I've been on teams as you describe. They were great - as long as nobody had to deliver a working product and you were just running out runway until the next gig. They were also great when the product was already built and we were just KTLO and deliver some new features once in a while. But I haven't seen such teams deliver a product from initial idea to PMF and sustainability.

What kinds of products were those teams building?

That may only work if the target group of your product are developers, then it's not a suprise they have a clear understanding what's valuable to them.

If your product targets customers outside of the IT department, it's a whole different picture.

This mindset is also part of the reason why some products are atrociously bad. Developers build products with the latest tech, whizzes, bells and whistles and totally miss the 'actual' requirements and/or how their users use it. When bugs/issues are raised, dev complains that users aren't using the product the 'correct' way.

At the end of the day, whether you should have a Product Manager or not AND the number of PMs you should have will depend on various factors such as the product itself, team size, size of the company, type of company (B2B, B2C, etc). But saying that PMs are NEVER needed and Developers should just build is wrong. Someone has to wear the hat of a 'Product' person. Whether it's a separate person or the developer is dependent on the factors earlier listed.

My comment here [1] and the discussions for that post is a good example of this mindset of PMs are NEVER needed.

1) https://news.ycombinator.com/item?id=25975417

I wish I could upvote this more. I feel like the people who say that all you need is engineers have worked either exclusively at devtools type startups, or they've only worked at unsuccessful startups but have convinced themselves that the reasons why had nothing to do with lack of people with PM skills.

If you work in pretty much any kind of B2B SaaS and don't have PMs (or someone doing the PM work - if you've got engineers who were formerly PMs who spend half their time managing the roadmap, you can't really claim you're only employing engineers), you're probably doomed.

If you don't have product, who is talking to customers on your team?

A good PM might not be that technically knowledgeable at all.

If they're at least very detail-oriented and can effectively lead sprint planning or whatever the equivalent is at your org, much chaos and indecision can be avoided.

They get bonus points if they're good at shielding dev teams from office politics and committing everyone to a firm schedule free of sloppy requirements or loose due dates.

Engineers don't want to talk to the customer, so who will do so to know what to build? In startups, when building MVPs, YC and others will stress that the founders be talking to their customers, but this should not stop just because the company becomes larger.

> Engineers don't want to talk to the customer, so who will do so to know what to build?

Product Managers as they have become today (from my experience over the last decade+ in 7 companies) are far too involved in technical decisions (on which they most often have no clue about) and far too little involved in talking to real customers.

In the olden days (the 90s for me) we had people whose job was to track the pulse of customers to see what they needed and provide that feedback in an organized form to engineering leadership. At least in the companies I was in, their title was not PM (can't remember their exact title).

That was very useful, it gave engineering leadership a clear view on what customers like and what they hate and what they want in the next release. And it was not interference, as these people had zero say in engineering decisions.

Today the average PM is just meddling in technical decisions they are not qualified to have an opinion on and most of them don't really spend enough time with customers, their product direction is all based on their personal (largely uninformed) opinion.

Maybe there are still companies that do the PM role right, but I haven't met any.

I took a PM role at a company that was "engineering first" company for decades. This is code for engineering with no accountability, and a culture where engineers do nothing but pat themselves on the back.

My product is utter crap. As an example, 2/3 of the code moves data from Oracle to JSON to MySQL back to JSON to PostGres to parquet that just reconstructs the schema of the original Oracle tables. It is fragile as fuck and the "architect's" proposed solution when I joined was to throw Redis in the mix. Customers hate it because it's always breaking down and has massive requirements.

I went to war with him, pointing out how absolutely asinine the whole thing is. Turns out, he was already on an RIF chopping block along with several other engineers that contributed to this mess. I just pushed it over the edge. When he left, I discovered one of them basically came in in the morning, logged in to customer sites, launched four screen sessions at each customer and tailed -f logs all day, manually restarting when their own shit code went down.

This is what happens when you get out of developer's way and let them build in peace.

Not sure that's going to work if one is building a Finance, HR,.. software. You need domain experts to draw up requirements, prioritise etc.

Similarly, if one is building a consumer app where back-end, infra are 'solved problem' but user experience needs to be differentiated, only engg team would not cut it (designers would be needed).

The state of almost every single open source competitor to commercial software (in terms of UI, usability, effectiveness, and market share) suggests that maybe letting experts at programming software design all other aspects of software is not a panacea.

Ah yes, comparing a well funded company to two enthusiastic nerds coding in their free time, that's a fair take.

You are comparing paid labor to unpaid labor, not a company with PMs vs a company without PMs.

There is no panacea to hiring and retaining good engineers, all I am arguing is that the money spent on a PM is much better spent as Christmas bonus to the engineering teams.

However, if you believe that what takes building great products is an unqualified semi technical person with a made up role and title who doesn't do any work themselves but passing messages back and forth and strutting around like a peacock calling all the shots, be my guest.

Why would experts at programming software necessarily be experts at designing it?

(By “designing” I mean like, designing it in the large, what does it do, not UI design or something. Though of course the same goes for pixel pushing.)

This matches my experience. As a staff engineer I also did a lot of PO work and the fact that I was also an engineer on the team helped me ask customers the right questions. As an EM, I coordinate our Product processes but engineers on the team play a huge role and decisions are always collaborative. On teams I've been on with a dedicated PO/PM, the PO just ends up trying to micromanage the engineering team and pull people into a lot of useless meetings. Don't get me wrong, there are good PO/PM folks out there, but the vast majority I've worked with don't fall into the "good" category.

A mini cto is an architect in this position

This article and many people attempting to analyze this topic (and many others) are missing a key element: "incentives"!

Many developers are more passionate about technology itself – coding, solving complex technical problems, and creating efficient solutions. Their formal rewards (like promotions, bonuses, and recognition) are often tied to technical achievements. If a developer spends 40 hours on customer research, this effort might not be as formally recognized or rewarded as much as a technical achievement like developing a new authentication solution that benefits the entire team.

Shifting this dynamic is not just about encouraging developers to spend more time on product management. It requires a systemic change in how organizations value and reward.

Changing the incentive structure to be more user-centric and less technically focused would significantly impact middle and upper management roles. A shift would challenge the very foundations of their roles and responsibilities, potentially leading to a loss of control and influence.

It's likely that such changes would face subtle yet strong resistance from middle and upper management. These individuals often have significant political power within an organization and a vested interest.

Thanks for the comment. And I completely agree. Incentives shapes so much of how people work. I tried to capture that in the 3rd bullet, but your comment is more on-point :)

This isn't that hard. Just have your developers train people with your software. In every craft you learn the moment the rubber hits the road. A film director can watch the film in the editing room a thousand times, but the one first time watching it with a real audience will teach them more than those 1000 hours together. A carpenter can work away on a piece of furniture merrily all week long and be happy with themselves, but the moment of truth comes when the furniture is placed into the customers room. The same is true for software. If you want your software engineers to care about users they have to get first hand feedback what works and what sucks, preferably with their own eyes.

Every software engineer worth their salt has a certain degree of pride about doing things well. If this only ever is about the code, the commit history or other abstract concepts, but never about how well it can be used by the actual people it was made for, then how would they even start caring?

I can attest to that. I had worked on a product for a couple of years and received feedback from our support team, but never seen how the product was used in real life. One time, we had a specific bug that the customers were complaining about, and no matter how they described it, we couldn't figure out what the problem was. That was until I went to one of the customer sites and saw how the users were interacting with the product.

When they tried to demonstrate the bug, it was immediately clear to me what the issue was. That was the first time I really grasped the difference in how we approach software products. It also helped me see how the product could improve their job by watching how the process was in real life. Gave me a lot of ideas on how to make their job easier by using the product.

Writing GUI applications, there's nothing as valuable as standing behind a user who tries to do something for the first time with my application.

Just seeing the moments of hesitation, how the mouse is moved while searching in menus, etc gives me a lot of information.

Watching what and how they do after a month is as valuable. User interfaces have two sides in this regard: initial experience and boring repetition experience. You can optimize for the former, the latter or both.

Good point. My experience is also that most users don't learn many of the neat features I have built in to speed up their work.

Even if I show them a couple of times, it is often quickly forgotten.

> That was the first time I really grasped the difference in how we approach software products.

For me as well. I've started my "career" this way, building something very specific for a client (family member) whilst being on prem and having constant and direct feedback, so that's how it was done I thought.

Almost twenty years later, having worked different roles with teams in office and remotely, I have to remind myself, and others around me, that we are building something to be used by real people with real problems and my/your software must not be one of them.

“Incentives” if you do this you better make it pay so I never have to leave. If I have to leave to get a payrise then I am getting on the Omega Star team and slowing down their ISO timestamp roll out to get GraphQL on my CV, so I can hit levels.io and get that extra $100k TC. /s but Poes law applies.

I don't think your company is worse off if you get rid of those people by giving them a taste of the real world.

No but "those people" is all people, to some extent. All people have life outside of work, like to make more money, see how unaffordable a house is and say "OK I need to earn $200k a year to raise a family the way I want". While they won't be so brazen, there is some effect of "doing thing thing that leads to the carrot". So the company needs to change that carrot - but it is hard because the whole industry has the carrots.

So what you are saying is you have to live with people who demand not dealing with the result of their work, because the rest of the industry is allowing for such behaviour?

Never before have I heard such a good argument for formalizing the job. If architects or civil engineers were to do the same we had building collapsing left and right.

Heh it's funny that your takeaway is "managers hate this". I know a lot of developers who would hate such a thing, thinking the only thing developers should do is write code.

Barely relevant to the article, but this new trend of AI art as the main image of blog articles drives me absolutely crazy - if you don't have a clear main image in mind when you wrote the article, don't waste my bandwidth downloading a computers pipe dream.

I'm all for AI art, it's an incredibly valuable tool - but if your using an AI piece as the only image on the page, it should be for a damn good reason, not just space filler. Especially when you can't even curate the image generated well enough to have every person in the image have the correct number of fingers.

That’s a fair take.

Agreed, the issue isn't AI, it’s poor taste. Nobody wants to see what looks like an uncanny valley picture of all large ethnic groups smiling weirdly in a circle at each other. This bizarre soulless corpo art trend started well before AI generation rocketed in popularity.

It's not just AI art. Memes and unrelated stock image have also been used. It might be due to some SEO belief.

God I hate memes on medium pages.

Me too, especially when the underlying root cause is siloed communication arising from founder burnout or sheer disinterest not the supply of product management thinking. It's as if you needed the subtractive design thinking of the two Bobs in office space and what you got instead was aimless growth of product like cancer.

"Medium" itself is generally a good heuristic for trash that isn't worth the time reading.

Truly. I have it blocked in my kagi search together with pinterest, w3schools and other similar things like that. Can’t say I miss it.

Even before this, the trend of hero image which takes up most of the space above the fold, has been insufferable. This is just a continuation of that, which hasn't gone away either.

Here's an article on selinux, bit first an image of a leaf.

The most sad part is imagining the prompt that he used, and how hard he tried to add black, whites, women... respecting the politically correct numbers.

I spent less than 5 seconds in the prompt. Dall-e is quite politically correct, I guess :)

There's no need to do this, because DALL-E already automatically injects those things into your prompts behind the scenes.

What would be so sad about it?

Wokeism is sad.

https://www.reddit.com/r/ChatGPT/comments/1717jqk/chatgpt_da...

Yeah DALLE-3 has this in the system prompt.

> Diversify depictions of ALL images with people to include DESCENT and GENDER for EACH person using direct terms. Adjust only human descriptions.

> EXPLICITLY specify these attributes, not abstractly reference them. The attributes should be specified in a minimal way and should directly describe their physical form.

> Your choices should be grounded in reality. For example, all of a given OCCUPATION should not be the same gender or race. Additionally, focus on creating diverse, inclusive, and exploratory scenes via the properties you choose during rewrites. Make choices that may be insightful or unique sometimes.

> Use "various" or "diverse" ONLY IF the description refers to groups of more than 3 people. Do not change the number of people requested in the original description.

> Don't alter memes, fictional character origins, or unseen people. Maintain the original prompt's intent and prioritize quality.

> Do not create any imagery that would be offensive.

> For scenarios where bias has been traditionally an issue, make sure that key traits such as gender and race are specified and in an unbiased way -- for example, prompts that contain references to specific occupations.

>Don't alter memes, fictional character origins, or unseen people.

I wonder what not telling it to avoid altering unseen people does.

That is quite interesting. Maybe they're trying to keep it from manifesting additional people - if the user requests a scene where logically more people are present than visible (maybe it's first-person, or the view from the front row of a theater) and ChatGPT crafts a prompt which describes the physical characteristics of the unseen people, Dall-e will probably include them in the image it generates.

I often do have a clear image in my mind for an article. I can not draw it and I don't have the budget to hire someone to do it.

The image is meant to convey a feeling. It is meant to make an abstract concept from the article a little more tangible.

In the past, I'd search for images on the net that I could use to accomplish that. Now I can craft them with DALL-E, and they are usually much better.

This image should complement the article. Just like the text of the article is meant to convey some information, feeling, or concept, the image should do a bit of that as well.

I don't know the exact word for the style, but this article is pretty egregious for the overly stylised "AI art". This just looks cheap, obviously "AI", and is pretty distracting for me. I don't know if that was the intention or not, but it's a detractor for me.

It looks like an ad for a shitty mobile game.

Quality of writing and quality of imagery varies a lot. It’s hard to do.

Is it any worse than a photo model’s pipe dream about what they are shooting? People on stock photos rarely know anything about the profession or the situation they represent besides basic ideas like looking smart, busy or chatty. They just have to look good at the same time.

Blog articles you could take seriously didn’t use to have stock photos. It may not be worse, but that doesn’t mean it’s not bad.

I don’t mind AI art except that it’s so often cringe. Half of the time I wonder if it’s meant tongue-in-cheek, or if the author really feels it’s an authentic fit to the article.

> the correct number of fingers

I like how one of the tablets seems to devolve into a paper notepad at the bottom, and how the notebook display on the right seems to be transparent and twisted.

I think my brain automatically blocks out stock photos, because I didn't even notice this post had an image.

But there's something funny about this. The blog template requires an image bucket, so mindlessly fill it with something, right? Too hard, so find a bland stock photo. Too hard, so purposefully generate a bland stock photo. Uninspired tasteless AI garbage is going to overtake everything in short order.

The problem with most PMs is that they are not doing boots-on-the-ground work. A good PM should be constantly bridging the gap between engineering and the user.

1. Map the product or idea being built to those who will use it. Present it, get users feelings on it, if it is viable and needed. Throughout development, gather continuous feedback by demoing, shadowing, and adapting to new feedback. Plan and execute a launch, watch for snags, provide support and solutions to users.

2. Communicate gathered feedback to engineering, and do so with an understanding of where the project is engineering-wise, where it is going, what needs to change. Give engineering the "why. Convey the priority of everything the project needs vs what it has and what is being worked on.

Repeat this feedback loop.

But most of them seem to think they can operate entirely in document-land and just crank out roadmap docs and keep stakeholder alignment via endless check-ins and nagging. They are doing a "project manager" job instead.

Having been a PM (now developer) the problem I faced was half the time I was having to provide documentation, communications and evidence for my managers. Which is of course fine but when you have HIPPO syndrome (HIghest Paid Person in the Office) who likes to make product decisions then you have to spend most of your time covering your back and managing up

PMs get a lot of stick, sometimes justified, but they're just having to play office politics in order to get stuff done

Yep. And then you leave and the engineers start complaining they have to play office politics to get things done. :)

PM->Dev is not the typical trajectory, although it's one I'm considering.

How do you feel about the transition?

A great way to solve for this in B2B, is to hire a customer and train them as PM. They will hit the ground running much faster to bridge the gap.

Just so I understand, the best way to hire a product manager in B2B is to poach the employees of your customers?

A more charitable interpretation is poaching ONE such employee out of all your customers. It's not a criminal act, IMHO.

Managers of any company that think they can't afford to lose a single employee are doing something wrong and should google "key man risk"

My org tried this, but being in financial services no one thought through this problem - our customers are much better paid than any PM we could hire.

That is to say, the only customer we could convert to a PM was one who was fundamentally bad enough at his existing client side job that he was OK capping his income at 25-50% of his potential.

Doesn't it go in the other direction too? Any PM you can hire can probably make more in finance?

Well yes but that's why I think "we'll just hire a typical user as a PM" isn't really a solution.

It also doesn't give them any training in how to PM.

They should just be someone technical enough with enough people skills and familiarity with user use cases to bridge the gap.

My experience (FAANG) has been the opposite. PMs want to dream up features and put together a roadmap and then they think their work is done. A great PM is both creating a vision or plan and guiding the execution and iteration. The plan is the 20%.

I'm a PM (I now exclusively look for the 'technical' qualifier before any role I consider) -- I could not agree more with what you wrote. The last paragraph particularly.

Lately, I've been responsible for mentoring other PM's. Sure there's the widely shared roadmap, but also -- I can't tell you how many documents and sheets are created that are literally never seen again by anyone other than me, and I get the feeling were created to demonstrate that they are working. It's a habit I try to break.

The reason I advocate for technical product management so strongly is I've (over)simplified the problem in my head to be that some PM's are stuck at that high level of abstraction because they're unable to communicate with their teams on the detailed technical matters on a daily basis. So they end up in a weird grey area of project/product management.

> documents and sheets are created

That sounds terrible and predictable. Data managed by a PM should be managed and presented in the same product dashboard used by everyone else.

When they can't use git and find project tracking software too complex to understand, this is what regularly happens. Either this or charts and tables in Miro/Figma boards.

This is too cynical IMO. Documents are actually the correct tool for some kinds of thought and communication. Issues are different, Miro/Figma boards are different.

> Issues are different, Miro/Figma boards are different.

In practice over the last year, I've seen product managers make Gantt charts in Miro as the source of truth for a project and run backend engineering retros in Figma. These were done redundantly with our issue tracking system; my cross-functional team had to create issues in our tracker based on the Miro and Figma boards to actually manage our own work, then duplicate the updates on those boards to communicate them up to product.

> they're unable to communicate with their teams on the detailed technical matters on a daily basis

Yeah, I've had PMs who've ground backlog grooming sessions to a halt so engineers can explain in detail what each one is, or shared incorrect information about a bug fix or new feature to a technical writer for release notes because they were so confidently incorrect.

The PMs with enough aptitude to understand and explain what the engineers are doing, even if they're not actively participating in implementation because they're applying that knowledge to broader strategic/roadmap decisions and cross-team coordination, are the best to work with.

That’s what happens when you hire a full time person to do what should amount to 8 hours a week. They go looking for ways to show value, and often that just causes everyone else to have more work too.

Usually it’s places where the projects are plenty small enough for the normal manager to handle it but they’re lazy and want the TPM/PM to be their secretary.

> But most of them seem to think they can operate entirely in document-land and just crank out roadmap docs and keep stakeholder alignment via endless check-ins and nagging. They are doing a "project manager" job instead.

They are not managing product, they are managing stakeholders

Mainly internal stakeholders, I take it. Isn't all that entirely big-company politics?

Whereas a PM in a small company can devote more attention to the product, customers, market, metrics.

What's a good question to ask to find out which sort of animal you're dealing with?

>But most of them seem to think they can operate entirely in document-land and just crank out roadmap docs and keep stakeholder alignment via endless check-ins and nagging. They are doing a "project manager" job instead.

Ok, maybe I came to the wrong place to say what I'm gonna say because I guess that a sizable part of the demographics here works in hot, meaningful projects, but as a corp worker for the last 8+ years, it has been my experience that a lot of companies have products that are used either internally by their own employees or by another corporate client that still pays for them out of inertia or because there is just too much custom business logic that now it's too costly to replace them.

In both of these cases we're talking about uncompetitive products that are probably going to remain so before being discontinued. And in both of these cases companies will try nonetheless to create a SCRUM-like arrangement with PMs and POs and behave like they are building a revolutionary product, urgent taks and pressure for results included.

It has also been my experience that in this kind of environment normally PMs and POs will be fully invested in doing politics to try to climb up the corporate ladder without much concern about what makes a good or usable product. They will steer the project in whatever direction makes them look good to the administration or the client at the cost of creating a fragmented product that many times looks like it's doing a random walk in terms of functionality and improvements.

I'm not old enough to know how things were built in the 60's/70's/80's(no SCRUM/PM's/PO's I guess) but the catastrophist discourse that there's a deep slowdown in productivity compared to the previous decades and that today we're mostly relying on things we already did in the past maps pretty well with my perception.

>but the catastrophist discourse that there's a deep slowdown in productivity compared to the previous decades and that today we're mostly relying on things we already did in the past maps pretty well with my perception.

Mine too. Any ideas why productivity has slowed down so much? Is this a software online observation, or more of a wider pattern

With software I guess part of the problem is that there's a lot of diminishing returns, with it being much easier to just crank out some initial prototype that does a lot, then it is to adjust some spaghetti mess that users deeply rely on. But that should only really affect individual projects, not necessarily the industry as a whole

>Mine too. Any ideas why productivity has slowed down so much? Is this a software online observation, or more of a wider pattern

It's a wider pattern in fact:

"The productivity paradox, also referred to as the Solow paradox, could refer either to the slowdown in productivity growth in the United States in the 1970s and 1980s despite rapid development in the field of information technology (IT) over the same period, or to the slowdown in productivity growth in the United States and developed countries from the 2000s to 2020s; sometimes the newer slowdown is referred to as the productivity slowdown, the productivity puzzle, or the productivity paradox 2.0."

https://en.wikipedia.org/wiki/Productivity_paradox

this compares apples to vitamins in a way -- what is possible and what is expected have changed so much in thirty years for office and information work, that reducing it to a pair of numbers seems ridiculous

> Mine too. Any ideas why productivity has slowed down so much?

It's not exactly a new idea:

> The term "software crisis" was coined by some attendees at the first NATO Software Engineering Conference in 1968 at Garmisch, Germany. [1]

As you can see, people have had the perception that it's harder to crank out software than before for a long time now. The reality is that we're collectively vastly better at it than we used to be, and that what we're trying to do gets harder and harder. No one is paying for the kind of productivity software dev had in the 2000's, and no one will be paying us 20 years from now for doing what we do now. Except if maintaining older software that yields value - in which case, well, maintaining and expanding a brownfield is always harder than greenfield.

[1]: https://en.wikipedia.org/wiki/Software_crisis

My team was product managed by a gutless PM who essentially made senior devs & tech leads do all the legwork.

Requirements gathering, mean user upset about a bug, weekly status call, need to break some bad news re: priorities? - send a senior dev or tech lead. Skipped most of the agile ceremonies too, busy guy. Never wrote or edited a JIRA ticket, that was for tech org to manage. He PMd 2 other tech teams the same way.

Tech leads/senior devs knew our PM was bad news from his first week but he outlived all of us until finally getting hit with a RIF after 4 years.

Management worshipping at the throne of agile become really enthralled with these guys and can derail an org for years. In theory a PMs stakeholders are the users, but in practice it is buffing the egos of the senior management that hired them. Can become a self reinforcing closed loop between senior management / agile consultants / PMs.

> Management worshipping at the throne of agile become really enthralled with these guys and can derail an org for years. In theory a PMs stakeholders are the users, but in practice it is buffing the egos of the senior management that hired them. Can become a self reinforcing closed loop between senior management / agile consultants / PMs.

Beautifully put!

This was the way in almost every place I've worked. If you did a good job at managing upward and schmoozing and stroking the senior management's ego, and had those smooth "ivy leaguer" mannerisms, then it didn't even matter if you did your job. You were the Golden Boy and destined for greatness. But if you were too busy actually doing your job and didn't properly pet your management chain, you were setting yourself up to be the scapegoat.

This is exactly the problem. If you do your job as a PM, you get pushed out because doing your job means you'll be ruffling feathers in senior management. So to stick around, you schmooze instead of doing your job because doing your job properly invariably pisses off management at some point

> He PMd 2 other tech teams the same way.

I'm with you that all of this is bad PM work, but this seems to be the root cause. I've been at a startup like this where there weren't enough PMs to start and then a couple left, which just led to the rest being stretched across more teams.

You just can't do much of anything useful in this situation - your existence consists of preparing for and attending stakeholder meetings. I guess some people thrive on the pseudo-glorified existence of "managing" a bunch of different teams, but I found it to be as miserable as you seem to have found it from the eng side. I was there to spend time with customers and designers and engineers, and after a few months of doing none of those things, I quit without a job lined up.

Once you get to that point, it can become even worse because you end up in this doom loop of management realizing that the core PM work is getting delegated to eng, thinking that this means they don't need as many PMs and then delegating more work to eng.

> Once you get to that point, it can become even worse because you end up in this doom loop of management realizing that the core PM work is getting delegated to eng, thinking that this means they don't need as many PMs and then delegating more work to eng.

At least that is better than eng doing the PM work and the PM getting all the credit for it.

Exactly. "Oh no, the team doing all the work and covering for the other team is going to get the incremental resource increases".

Yes. If a team is incapable of either doing their job or in advocating for needing more resources to do their job, then they do not get to have more resources. Particularly when another team is covering for this gap, typically, engineering.

It never goes the other way right? How many times are PMs picking up JIRA tickets, handling bug fixes, joining on-call rotas, etc type tasks that engineering does?

If non-engineering roles/orgs are created to take load of engineering, and are incapable of doing so, then they need not exist. This goes for DevOps/CloudOps/SRE/Support/QA/Product/Project Mgmt/etc.

You can run a lean startup consisting entirely of 3 engineers. But you can't run a lean startup consisting entirely of 3 SRE/QA/Product/whathaveyou.

This is not a knock on these other orgs/roles. In a well functioning shop, they are essential. But when orgs like Product forget that the tail doesn't wag the dog.. bad things follow for everyone.

I've always found PM's that come from a UX/Design background to be more willing to engage with the actual people we are building software for. IME, it's always been BA/MBA types that want to draw up documentation and then chuck it over a wall (development) and call it a day.

That's why the best PMs have some kind of engineering background or are former eng. As small as it may be it is a requirement nowadays.

I've worked with dozens and dozens of PMs over the years and almost zero of them do this. Most of this is always done by product designers.

The best product manager I worked with was just an exceptionally bright person, they were able to understand complexity of implementation (and even have a reasonable chance of doing it themselves) vs understanding the business need. Just basically a value add to the company without being an engineering manager.

Unfortunately most product managers are just people who sit in the role. They are just gatekeepers who take either credit or blame. They often have little skin in the game.

Overall, if you have a product management organisation, you're doing it wrong.

> Overall, if you have a product management organisation, you're doing it wrong.

Agreed, the best (and most successful) products I've worked on have all had product ownership by actual implementers (engineers, designers, customer success, etc). I loved being on the support rotation as an engineer because it closed the gap of abstraction between my work and the real humans who were using it every second.

Very rarely, I have worked with PMs who add net positive value, and in every case they would have made okay engineers as well.

> Overall, if you have a product management organisation, you're doing it wrong.

I've found myself on both sides of this issue in my career and I've landed on it being a good thing to have a PM organization, assuming your entire org is large enough.

The main reason why is that when PM (or whoever plays that role in a team) reports up to the same engineering management chain, all things eventually bias towards the needs of engineering. Much-needed feature work that is likely to advance the business eventually always gets de-prioritized because there's always tech debt or infrastructure work that inhibits people in some way. Sometimes it's actually the right move to do that, but you need tension between two orgs that have equal chairs at the table to make that kind of call. That ends up not happening when it's a part of engineering.

Of course a lot of the sad reality in our industry is that separate PM orgs get to have more power than engineering orgs because they get to own "what's good for the business", and when you combine that with a bunch of PMs who know how to follow a process or framework but don't actually understand their own products or users, you get a nightmare.

I think in ratios.

How many frontend engineers to backend?

How many engineering managers to ICs?

How many technical writers to (all) engineers?

How many product managers to (all) engineers?

And I try and keep the ratios finely tuned to have the greatest impact but the least meddling, the least micromanagement.

What the numbers for these ratios are is likely specific to your organisation, but if you detect meddling or too much of the "how" not coming from the engineers themselves, change the ratios, increase engineers per people or product manager, make it so that they cannot do this and instead have to prioritise what they get involved in, to step back from the micro, and to cede autonomy on how back to the engineers.

This is the only sand way to go. It's surprising how many places just don't have PMs, or have far too many PMs (also applies to QA, junior engineers, senior engineers, architects, HR personnel, Vice Presidents, salespeople, etc.)

I’ve been in product management for over 20 years, and I agree with most of what is said here. Ratios matter. CPOs end up empire building with an army of PMs. The organisation ends up with PMs owning a slice of the customer experience such as a single page, optimising CTRs on buttons, with no meaningful contribution to the product strategy or vision. It’s hard to be a Product Manager without owning a product.

Indeed. PMs are paired on a scrum master level. Then scrum master - due to the fact that they are "SCRUM MASTERS" and not developers focus also on PM type work. To make matters worse the "easily interchangeable" developers are coming from an outsourcing company. Now the development needs to be isolated from the customers with more management. It is a great way to increase the GDP.

Longtime PM as well, and I strongly agree. PMs should have lots of surface area —- ideally, an entire product (or more).

PMs should also be a lot more focused on the business’ goals than most PMs are. It’s necessary but insufficient to solve problems for your users. Solving those problems needs to translate into value for your company too.

Strong, product-minded Eng/UX partners are essential in enabling that.

This. The closer to the P&L the better. It forces you to act as a "whole product" manager and not think everything is solved by adding a new feature.

> It’s hard to be a Product Manager without owning a product

I'll say it depends on the size of the product. If you're dealing with say ERPs (Oracle Fusion Apps, WorkDay, SAP, etc), a PM can't own an entire product. Instead, they'll own multiple features where each of those features are complex in themselves and being ERP typically involve integration with multiple other products.

But I agree with the general thrust of your point which seems to be that the PM should own something 'significant'

As a developer, and a development manager, the best product managers I've worked with rarely got involved in the "how". Sure, they may generate epic-level tickets in your back log, but lower than that, they trust you and the project people to get things done.

Problem is, the org needs to support that, and in most companies, the work that gets the most attention isn't visionary or growth focused, it's whatever is making the loudest noise. Often that is in direct conflict with a product owner/manager's desires.

Or they are super into weeds polishing stuff in code level but it is never between those two approaches. Also very good pm can be kinda shackled if there is lots of mediocre pms running around.

On the other side I have worked with PM/POs who have no clue and the developers are just telling them: "Oh this is super complicated you would not understand" or "This will take a long time to implement" and its a small feature.

There must be a balance. There must be some basic understanding by the PM/POs. They cant be the person that barley can use a computer.

It also helps to be able to understand the tech enough to know if a certain approach is going to impact other initiatives which are further down the roadmap. One of my favourite questions I've been asked by a PM is "Will any of this work become easier to do if we change the order of these work items?"

I would have thought every manager asks such questions either to himself or to the team quite often.

Not in my experience - juggling priorities is usually difficult enough when you're just trying to manage the C-suite's favourite ideas, or feature requests from the highest revenue customer, etc. Factoring in synergistic engineering efforts is out of reach for a lot of PMs that I've worked with.

> As a developer, and a development manager, the best product managers I've worked with rarely got involved in the "how".

My experience is completely the opposite. PMs that don't understand the how, that is, they don't know how their product works, are the worst.

Best PMs that I worked with had a technical background.

I believe OP meant « implementation » with « how ».

You want a PM that knows the product (really) well and brings new work to the developers in the form of well documented problems, not solutions.

You don’t want your PM to get involved in the technical details.

Careful here!

> not solutions

Often yes, solutions. When you're still in the "what are we building" phase you want a good PM deeply involved in the process. I think you may have implied that, but solution creation happens before code gets written.

You also sometimes want a PM to get involved in technical tradeoffs when they impact the user experience. I've found that this happens more often with a technical product (API capability or SDK interface) than a UI screen, but it comes up. When your PM is the expert in your userbase and how they expect to use something, they need to be involved a lot.

Agree on all counts!

>Best PMs that I worked with had a technical background.

Best PMs I worked with just figured out what users wanted and organized the team to build it through good communication. That's it.

Sometimes the technical PMs can be an issue because they care too much about the how and not enough of the why and what.

If your product is selling devtools to developers, then yes, it helps to have a technical PM. Case by case.

This would also depend really on how technical the product is, but if a product is technical and PMs don't have enough technical background they won't be able to understand nuance of what customers wanted and what is actually possible to do.

Best PMs know both the what, why and how and tries to bridge all that.

It may include knowing technical weaknesses and strengths in the energineering teams abilities and their plattforms abilities and weighing that in for planning and priorities. In reality development in product that are over the teams abilities may lead to a real mess.

Product managers own the "Why?" and the "What?". Project managers own the "When?". Engineering managers own the "Who?". Engineers own the "How?".

When people try treading on other patches, it always ends in disaster. That works both ways: engineers are lousy at the "Why?" and the "What?" because they think too much in terms of "How?"; and yes, product managers need to step away from the "How?" unless it's to clarify the "What?" or the "Why?".

Hard disagree, cross role context is critical for intuition on getting stuff done. A designer with no insight on engineering will create shitty designs that take forever to build, create patterns that arent reusable, etc. Engineers with no insight on product will not be able to balance the debt/product ratio properly. You can say that all of this gets sorted out with proper communication, but knowledge and intuition will always beat leaky bucket cross role comms

"Having context" isn't the same as "having ownership or accountability".

Of course there needs to be communication and context, but when engineers start to try and direct the "what" or the "why", it becomes as absurd as PMs trying to dictate the "how".

If this is the ownership and Engineers ask "How?", there's no one overall to connect the dots. For instance with this ownership dynamic product managers will come up with what and why, and engineers will come up with "how", but no one validates whether the whole thing is worth it considering the technical complexities involved. So scenarios where PMs come up with this and Engineers just ask "How?" there will be initiatives that take a lot of resources, while not giving enough in return.

There's no one to balance the complexity of building this vs the gains achieved.

I think best engineers would be people who also use the product and can give their own insights on this, as well as best PMs are someone who have good knowledge of the technical background and context.

The customer voice - represented by product managers - help join the dots.

It's a team sport, there needs to be communication, but there also needs to be clear areas of ownership.

That only works when the people under them are competent and business interests are reasonably aligned with reward structure.

I’ve worked with a number of Fortune 500 companies and seen many examples of a disfuncional culture. I’ve seen in those places that PMs solve most problems with the one tool at their disposal: meetings. Incentives for promotions are such that the bigger your meeting the more important you are. I’ve been in hi dress of hours of cross functions team meeting where 1-2 people did any work, and usually the PM talked the whole time, while 10-20ppl are on mute and only sign off at the end to show they indeed exist. The end result see teams of dejected engineers that don’t have time for actual technical work, and are asked to give estimates or commitments on the spot without any research or even understanding of the code. I’ve seen PMs reject technical designs because they didn’t like the number or “points”, and engineers just had to reformat the same ideas into different “tickets” to satisfy some inscrutable PM aesthetics. Entire projects delayed and derailed because of lack of understanding and pointless status signaling rituals. On the other hand I’ve worked with brilliant PM who protected the team from such nonsense and helped them stay focused on the right goal. These people are invaluable as much as the others are detrimental.

Not related to number of PMs, but rather the type that I prefer to work with:

I’ve worked at 4 different companies in the industry, ranging from < 40 person startups all the way up to JP Morgan Chase.

I reject the idea that “technical” folks are smarter than “non-technical” folks - in fact, as an engineer I often get caught in the weeds and lose sight of the big picture, and need a PM to help pull me out.

However, in my experience, the easiest PMs to work with as an engineer are ones who have at least __some__ actual exposure to code. Nothing fancy, it could have been building a website with HTML and CSS many years ago, writing some ad hoc SQL queries, or taking a Python class while doing a Master’s degree. __something__ that helps a PM understand that writing code is neither an exact science nor outright wizardry.

These PMs tend to advocate for the engineers they work with, or at least try to strike a balance between business demands and engineering realities. Those who get into PM with zero technical exposure tend to be more “business-oriented”, which may be exactly what a business needs at a given time, but not all the time, and as an engineer I would rather work with someone who has a better understanding of my perspective as well.

Now if only companies (like JPM where I’ve worked also) actually recruited and hired PMs with those technical skills instead of whatever bizarre criteria they use.

No I’m not salty at all :p

One thing I've been thinking more-and-more about recently:

People are unique; there's no doubt about that. But how much of "the product manager does product management" is genuinely just the title they're assigned, versus some innate capability they were born with?

I'm becoming more agreeable to the notion that, at least in product development: most people should be doing more things. People can and should have specialization; but maybe it should be more organic and nuanced, like "Mike is our API guy, but he's also pretty good at organizing large projects and if you've got a big architectural ick to work through definitely go talk to him" versus "Sarah is more on the product side, she'll have great insight into user experience and she knows who to talk to in the organization to get decisions made faster, but she can also take on some smaller frontend tickets."

My argument isn't really "great idea dude, let's get rid of titles"; because I think the critical part is, this mindset is deeply predicated on Agency. You need an organization that assigns High Definition and High Agency to teams. You also need a hiring process that, very specifically, treats Personal Agency as one of the most important qualities a candidate can have; you don't know Go, that's cool, we can teach you Go, what we can't teach you is the genuine desire to want to be taught Go, and Rust, and some language I haven't even heard of, and by the way you're interested in the overall business and revenue and such.

The obvious problem is, people like that are a vast minority, and maybe you can't really scale companies by relying on the people you hire being intelligent generalists. I think there's also something to be said in the force multiplication of technology. A room with five of the right people can be more effective and productive than a skyscraper of 500.

People with a lot of personal agency in this way will also slow things down by expecting rational decisions from management and asking questions when they aren’t. I think this makes for a fantastic partner, peer or co-worker but a horrible employee. So I don’t think it’s too surprising that most hiring managers will be actively filtering them out.

As someone who does very highly value this way of thinking though, how would you try to detect it in an interview setting as an interviewee? That’s like asking them if they have good culture.

So the alternative is for management to be surrounded by "yes" people?

If that wasn’t pretty widely true, would the meme exist?

I mean it is true, but I disagree with your prior comment that people with agency slow things down. It may appear that way, but really, they speed things up and the answer is simple. People with agency scale... a lot. If decision making is centralized, it's like communism, it might work at small scale, but won't past a certain point because the centralized points bottleneck the entire system to the point where it can't operate effectively.

I 100% agree in a smaller company personal agency is huge. Setting the issue of scaling aside, it's very difficult finding people who just get sh*t done and problem solve, no matter what and where in the org. A big part is this has to be built into the org from inception. The other part is that training and encouragement must come from the top. I think more people can grow into having greater agency, but most don't because they tried and got no support and failed, or they actually succeeded but weren't rewarded and decided the juice wasn't worth the squeeze.

> Frankly, PMs are not the ones to handle UX, wireframing, tracking progress, organizing stand-ups, or being the sole authors of PRDs/specs, etc.

Who should be?

There are many schools of thought on this. In the end, it comes down to clearly defining who needs to be responsible for all the different things that go into defining, designing, and building a product.

Given the approach to product management in this article, what would the rest of the team look like?

I've been a PM in a few B2B companies, and the reality of the job was never even close to the ad, i.e. we (PMs) never had authority over either Engineering or Marketing.

"Product-led" is today's buzzword, but I'd have to personally experience it before I believe it.

Yeah, IMO "product-led" is just something that sounds nice when you package it up with a bunch of truisms and sell it as a consultant. There's a nice little industrial complex of consultants, "coaches", and other thought leaders who haven't shipped any product in a decade or more but will gladly sell you their silly services.

We're just here to do a job like anyone else, with hopefully a reasonable area of accountability. The thing that "drives" a particular initiative is what matters the most at the time - could be a big marketing push, engineering quality push, something we know sells well into enterprise markets, etc. It's fine.

Most non-technical PMs I’ve worked with have been ineffective because they don’t understand or think in terms of systems, they only think in “screens” and “buttons”. Put me in the “get rid of product managers altogether” camp.

Being able to show a relational database schema to a manager and ask: "is this the data we need in the manner we need" is invaluable

Good devs with good communication == Better then PM

Dev + Business = speed and customer centric

Dev + PM + Business = one more layer, i.e. slow, i.e. some loss of customer voice

I worked at Amazon as dev for 10 yrs. In early days 2001+. Amazon did not hire PMs then. Best of Amazon exp came out in that period. I was part of that myself. Pm is needed for things like building amazon prime. If at all.

That's a very based take!

The whole idea of a PM boils down to address a less qualified non technical middle man to make all the important decisions, while also pigeon hole your communications with the rest of the stakeholders.

Why does this role even exist is beyond me.

It's like we can't trust the engineers with any important decisions, so we need some business guy who took a two week course and now is suddenly qualified to be calling all the shots.

It is easier to build an engineering team when you don't expect them to be product-minded in addition to being technically proficient.

Working in the industry around 20 years now. It has become painfully obvious that businesses are out of ideas. Speaking in simple terms. Product managers never really stick around long enough to learn enough about a market or a product to bring any valuable insights or new ideas to the table. Spend 1 year to push the "MVP" then it's off to the next one with a salary increase.

Used to be a product guy that was 20 years + with a firm would have lots of ideas and hammering the development teams to ship feature after feature. I just don't see that anymore in the places I lend a hand.

Some great advice. The best PM I have worked with are visionaries and catalysts. They are great at exploring opportunities areas and bringing the team along.

I've worked with some bad PMs and some great PMs.

The great PMs generally follow the advice here:

https://staysaasy.com/product/2023/03/12/pm-engineers-dont-h...

In my experience in multiple roles (product manager, project manager, software engineer) and dozens of successful launches with large engineering teams, the ideal kind of PM has a deep understanding of users, how software should work best for them AND technical experience.

The problem with a purely technical team and no user-centric PM guidance is they'll end up building an engineering designed product, that doesn't resonate with non-technical users. As pure engineers, we love engineering, and may over-engineer solutions given the opportunity. Unless we are building some developer tools or highly technical product, this doesn't work for the majority of non-technical products.

You need a PM who can separate the technical design from the user experience, but also understands how to bridge the two when it comes to actually building the product. No technical experience rarely helps, as you spend a lot of wasted time debating why things should or can't be built.

As a PM with technical background, I'm not going to waste engineering time proposing radical user experiences that I know will require excess resources and time to build. At the same time, deeply understanding what users want, I'm not going to build a product that is too technical for them to understand how to use. We understand the limits of our technical stack and how to reduce user frustration. That is the advantage of having a balanced PM with both user and technical experience.

Most product management functions should be merged into product design - it's impossible to design a good product without thinking about what features that product should have and how users will use it.

I wouldn't eliminate the role entirely but I think most companies have 10x the number of product managers they need to in part because it's a way for non-technical people to get into tech and tech salaries. Now that the market is tightening it's unsurprisingly we're eliminating those roles.

The general pattern of replies from developers to any thread like this tends to go "I worked at a company and the PM was bad so therefore all PMs are bad and pointless". And, let's be clear, there are lots of undertrained, underskilled PMs out there working on the wrong things (delivery management, writing tickets, bossing devs around etc).

BUT - this is a leadership problem. Either leadership want and expects PMs to be doing those things (dysfunctional product mindset) or they want them to be better PMs but don't know how (poor performance management). In either case, firing all the PMs and expecting the devs to do it just means the devs get thrown into the fire instead. They're welcome to try! But, the idea that removing PMs from a dysfunctional organisation fixes anything is nonsensical. The devs will be just as unhappy taking orders from a more senior stakeholder who understands them even less.

Good product managers can be game changers. They absolutely should not spend all their time bossing developers around. They don't need to be former developers themselves (although there's nothing wrong with developers becoming PMs). They don't need to spend all their time on tech. Building great products isn't as simple as saying "The developers can do it" and letting them build whatever. How many developers really want to work on market strategy, pricing and packaging, customer segmentation, user interviews, wrangling stakeholders etc? I guess... maybe some... but enough? The whole fetish that developers have for "just let us do it" will dissolve quickly in a good or bad organisation because they only see the bits they want to see.

For the record, I spent 20 years as a developer before moving into product leadership.

I guess I belong to the tiny minority of self-employed software developers, so my point of view is somewhat unique. In all of the projects where I had to deal with people representing big companies, I was always struck by the sheer amount of wasted time spent on meetings, political machinations, and bike shedding, instead of doing actual work that solves the client's problems.

I'm really glad to be my own boss and to not have a PM over my head.

A bad product manager is worse than no product manager. And it is hard to become a product manager that does not do a bad job.

Feature creep, not understanding software development methodologies, not having an intuition around technology, not talking to users, not talking to the team = bad product management.

Maximizing the value of what the team is working on = good product management.

You can summarize this article with a famous Einstein quote:

> Everything should be made as simple as possible, but not simpler.

Isn't it clear that scale governs the self-determination theory? You can run a company much like a startup if you choose to. Many people/businesses do not choose to do that and that allows bureaucracy and hierarchy to thrive.

This isn't a "product manager" problem. This is a loss of identity or culture. Many of your great people will leave because of this eroding. Blaming it on product managers is lazy because it shows you aren't looking close enough.

https://wikipedia.org/wiki/Self-determination_theory

https://wikipedia.org/wiki/Flat_organization

> the ideal time to hire a PM at a startup is when the founders can no longer be involved in all the important product decisions

No, that's when the founders need to hire actual managers. Their staff is already used to involvement in product decisions, right?

Then there are a bunch of traits and activities of PMs listed. I would think that the time to hire a PM is when the founders can't do that list of things, if that's what PMs do.

> it's easy to overestimate how many an organization needs

Why? The article avoids addressing that, telling us when to hire and how to right-size, but doesn't bother defining the problem being solved.

My experience is that the more devs there are per PM, the more the PMs start thinking they're "in charge of" the devs and then no one's happy. I'd like to see more of a "PMs as customer research consultants" model instead - contribute something that the devs don't have time to do.

> but doesn't bother defining the problem being solved.

An experienced product person could maybe have helped with that *scnr

"Expose everyone to users " - I would note this of course has logical limits. I've worked in orgs where we had shared slack channels (and DM ability) with all customers. Not great.

This meant that squeaky wheels got a lot of oil. They quickly figured out who in the channel actually knew what they were doing, and so every customer had their pet senior engineer they would bother all hours of the day / weekends / etc with questions. Support rotas and on-calls go out the door when your customers can directly escalate to their engineer of choice.

I actually turned off all slack alerts and disabled notifications on my phone as a mental health exercise as a result. So the net result of forcing me to be maximally reachable caused me to be less reachable as a whole. If someone important enough really needed me, they had text/phone/etc.

> I actually turned off all slack alerts and disabled notifications on my phone

Nobody should be reachable after 5pm unless they work the night shift and/or being paid to be oncall.

That you “actually” disabled these alerts points to a culture problem at work. A work app should not even be installed on your mobile.

Put your workstation to sleep at the end of the work day and don’t wake it until the next one. As you said, they can call for the once in a year emergency.

I've recently left a job because of bad product management. The big issue I find is that often PMs are too far away from the product and spending all their time politicking and thinking about "strategy", so they have no idea how much work a particular feature is. I was leading a technical team in my last job working on industrial software, and I'd regularly have a PM come to me and tell me that there's been a contract signed for a new customer, and we have X piece of bespoke work as part of that contract due by usually ~1 month in the future. So you start asking questions, what does X mean, how do you want to resolve this problem, etc. etc. etc. and most of the time, the PM can't answer those questions, so you're stuck. And the deadline gets closer and closer, and then the customer isn't happy when it inevitably gets missed, and the pressure comes down on you as an engineer to make things work, and people get burnt out.

My view is that PMs should sit super super close to the team. There should never be a case where the software team is more knowledgeable about the product function than the PM, but in practice this is often the case.

The reason I can't stand debates like this is that the "most right" answer is highly dependent on the details of the organization. Strong opinions are borne from bad experiences and people tend to generalize the patterns they've observed first hand.

A small org with a founder who has a strong vision they are good at articulating probably doesn't need many PMs. Similarly, you might find teams with engineers who are actually very user and market minded and have the bandwidth to do some of that work. Or, in the case of Airbnb, you can essentially split up the role and assign pieces of it to separate teams (which, the more I hear about it, strikes me as odd.)

At the end of the day, patterns in roles - and the PM role in general - usually exist for a good reason. There's a critical set of skills that, when done well, are very much justified and should exist as a single role - not the side project of a developer or a designer.

Yeah he said that in the article

I wonder what the author might suggest as an appropriate ratio of PMs to engineers might be. I generally like 1 per 10 person team. I also like the idea of not having a separate product tool but have yet to see a good tool that can satisfy software project management (eg Jira, Linear) and product ops (product board, Airtable).

I've never seen the tool before but my guess (based on the frontpage) is that kitemaker is their attempt at building such a tool.

I work at a place with approximately 3 PMs for 6 developers and I wonder what they do all day. Totally absurd.

Ha, what's the difference between a project manager and a product manager?

Two letters and about $50k-100k.

I've done both and it ends up being project management with a few extra steps. The extra steps being, "focusing on the market, solving customer problems, and being strategic.

You'll hear the classic adage of, ” well project managers deal with the how to execute and product managers deal with the what to execute" but the reality is over most orgs Ive been in, they're really just project managers who also have (something) of strategic vision aligned with the marketplace.

Don't tell product managers this because they'll get butt hurt and telling you how they aren't.

As someone who has hired both, I really don’t see it that way. As another commenter mentioned, the difference is the capability for understanding the problem, being able to envision the right solution, and then manage all the moving pieces to make it a reality. The best ones are similar to startup founders.

> see problem

> envision right solution

> Manage all of the moving parts

Congrats you literally just described project management with extra steps.

Thank you

Why not also be the developer if you can do that much already?

Because if you’re working on a project big enough, you don’t have the time to be a good dev or a good manager. As a developer I wanted time to think about how best to solve the problem I was facing, not writing documents, refining the big picture, get a buy in from the stakeholders, giving reports, making sure the other parts of the project kept getting along and so on. It was important for me to be kept in the loop, not doing it on top of my job. As a product manager, it’s the other way: I have a product that need to be there and so I’m trying to find a good compromise between the stakeholders idea, what would really work and what can be done with the ressources I have. That means sometimes I recommend to not start anything, but to buy a solution (then I need to validate that it will work as intended, that the budget and contract are ok and so on)

It’s another job altogether. That doesn’t mean I won’t follow the technological trends, educate myself or refuse to program anything. I wrote some postman script to validate what’s happening with our api, know the infra behind it, and can generally point people in the right direction. I have to know the product inside out to make educated answers when something goes wrong or if a decision is required.

It’s often a people job. And that’s something I try to share with the teams I work for.

We are not talking about a good manager here. We are talking about the one who can program manage to the level of lowest jira issues.

That’s not product management. That’s an under-qualified person misunderstanding their role. Product management is mostly a people job, understanding internal stakeholders, understanding customer, understanding the market, understanding the solution options, formulating and understanding strategy for the product, coordinating product marketing and documentation for the product.

If someone can do all that well, there’s simply no time to micro manage jira tickets

Even if they have the time, my rule is that nobody who does not understand the complexity of the solution (not the problem or the what) should be allowed anything more than watch rights in jira and standups. I would love to hear one non coding product manager who does not run jira in their org of more than 100 people.

The problem is that it is hard to be a product manger and own those tough customer metrics. It is easy to do jira and get credited for engineering work.

When I was a product manager for large computer systems back in the dark ages, I can pretty much guarantee you that none of the engineers wanted to spend probably the majority of their days on the phone with sales reps, in customer meetings, providing updates to management and other groups involved with product launches, writing technical sales docs, and reviewing marketing materials, etc. Many engineers liked sitting in on a customer meeting now and then as a change of pace but they (properly) wanted to spend the bulk of their time focused on actual engineering.

This matches my experience over 15 years and four companies. This is not a scientific study but I can at least concur with your experience. There are clearly orgs that don’t work this way, but I find that it’s very common when chatting with my PM colleagues. The exceptional cases have been project managers for projects that involve wide scope, multiple products, or some other factor.

I’ve also found that in addition to the Project Manager turned Product Manager, there are plenty of Product Managers forced to be Project Managers and it goes poorly unless a Development Manager is willing to carry that.

The ultimate problem is that Project Management doesn’t go away just because a company eliminates the role. The same is true for Product Management. If you’re ok with your developers or someone else doing the work, and it is fruitful, great. For about a decade I tried as hard as I could to get one of the limited Product Managers for the products I worked on to very little avail. As a result I had to guess about price increases and other functions that I, someone with 70% of a CS degree and some extension courses in business topics, have to learn on the fly each time I face the challenge. I was successful but I am sure a real Product Manager would have done a better job.

The companies I’ve worked for typically have a cynical view of dedicated Project Managers but I appreciate that this is a specific skill for similar reasons to my Development Manager forced to be a Product Manager experience.

I have very rarely encountered a PM(any title) who lucidly communicated their value-add to the company. It is certain that, e.g., someone needs to assess the pricing of a product and how to position it in the market. But it's unclear that the vast majority of people I've worked with are performing that task - they are, to all appearances managing projects and doing secretarial coordination work (ticket munging), something experienced devs and managers can do straightforwardly up to a certain point.

I think its one of those roles that you don't need until product (project) scope is a certain point, but it's been glommed onto smaller companies as they mimic the big-corp designs. So it never quite works for those small shops. They really just need a Product Person, singular, who drives the thing forward, IMO.

I had project were we hade not difference between po, pm and scrum master. No difference at all on what they did.

All those jobs do look the same because they are all bullshit jobs which infantile developers assuming they can't do and decide anything for themselves but write code on command.

Project managers don't strategize or lead a vision of what the product should look like.

It sounds like your strength is more in project management than product management so perhaps that's why the organizations tend to place you in that role?

If it wasn't clear, i'm a product manager that started in project management.

The real problem is product management is hot, project management is old.

I've been around the block enough times at different companies to form that opinion and thats OK. Product management is consistently project management with extra steps. Those steps being business and market analysis to solve customer problems.

It seems businesses are starting to realize that.

What you're saying isn't new. It's part of the Product Manager job description. They have to organize their teams to achieve their vision. Even CEOs do project management if the company is small enough. Every founder does project management too. So do engineering managers and individual engineers.

You shared an interesting perspective, but ruined the delivery with the last line.

I think the problem with these two roles is actually the confusion about what each is. Usually the issue is a "product" manager not doing the ideating, not doing research, not enough advocating about what user needs or what the product should be. Instead they do too much "project" management which amounts to gantt charts, check-ins, and nagging about status.

I have seen that in all sizes and maturities of company that people view these roles as interchangeable and they are not.

What founders, managers, and engineers share is the team responsibility for founding, managing, and engineering the product and its value proposition. A product's value proposition may be mostly subjective but is easily made objective by cost/revenue ratio.

> With any experienced team of engineers and designers, PM'ing is not a full-time job, or at least, it shouldn't be.

after the free money era peaked, consultants have now pivoted to efficient downsizing.

when my previous corp merged with another, the first people fired where PM's. so its nothing new. imo PM is the epitome of the bs jobs phenomenon.

Well articulated thoughts that are mostly detached from the eye-grabbing headline.

Good PM's are important. Building product-focused teams is important. More of anything != more better. Duh.

Definitely agree that the ones building should be product-minded. It should be normal and expected for engineers to perform customer interviews.

When I was a software engineer, I used to think I was the smartest person in the room, and derided the work of product managers, delivery managers and to some extent engineering managers. I've had experience of engineering roles up to Principal and Hands-on CTO and felt that we didn't need the non-engineering backgrounds at all.

Today, I find myself in a senior TPM role for a FAANG who also has "product manager" in his customer-facing job role.

I cringe at my behaviour 15 years ago. I shake my head as a I hear software engineers using the same arguments I did. "We know how to do product management, you're just slowing us down".

In recent years, on a few internal projects I step back and watch projects with no product or project management resource - just engineers - and the same pattern emerges over and over again: no clear customer-facing objectives, not enough time spent listening to customers, not enough work in the ramp up to design, not enough work in figuring out the long-term operational factors of owning a product, poor customer communication (no, they'd don't understand your technical documents, sorry, and they've told you that, and you don't know what to do about it, but huh, isn't this tricky?), and more often than not, misaligned internal objectives and politics meaning the product has "camps", driven by individual preferences and career/promotion objectives.

It's a mess. Every time.

You might not need product managers, but you need product management, and most engineers are atrocious at it. They want to focus on the technical work and are not prepared to commit to the work that comes with product management. It's often wise to just hire product managers.

You might not need project managers, but you need project management, and engineers are often poor at it. You probably should have project managers. Product managers often have better organisational skills - and the attuned level of empathy needed to listen to all stakeholders which is needed in project management - to be able to do project management too.

If you're still not convinced look at OSS. Most of it is only accessibly to other engineers, until one of two things happen: a project starts to ape product design decisions made by commercial projects, which has happened with a lot of office and graphics programs; or, somebody with real product management expertise gets involved and is able to influence the project.

I know many people will disagree. They'll insist they know better. I expect downvotes because some people will feel affronted.

I know this, because 15 years ago I felt the same. I was wrong. You're wrong if you feel that way too, and you'll realise it over time, particularly if you're asked to do it for a while. Product management is a real skill.

And yes, most teams could do it better. And project management skills - particularly agile skills - are awful in the industry. But please, stop thinking the answer is more engineers.

> But please, stop thinking the answer is more engineers.

The answer isn't more PM's either, though. In my experience when people are struggling, the default answer is "we need more X", be it engineers, PM's, money. It's very rare to have a group that looks at that and says "we need to do better with what we have" and is able to do so.

A good PM will make sure that everything your product team is working on is the correct thing to work on, which is so much more efficient than hiring 2 more engineers to work on those things. A bad PM can come in many different ways, (just like a bad engineer - we've all worked with the Arcitecture Astronaut for example).

The article is actually making a case for fewer PMs, not to do away with PMs altogether. In startups, founders tend to do PM because they bring the vision for what to build. Additional PM hires in such environments aren't likely to add much value. Even in large enterprises, most product decisions are really taken by a handful of very senior roles. Most of the PM org is there primarily to ensure fulfillment of whatever decisions are taken. They get reduced to a more of a bureaucratic function, which is where most people's frustration arises.

Nobody likes to have a stakeholder with no power to make decisions. A product manager who cannot tell you what comes a year down the line. A project manager who cannot change processes to improve efficiency. An engineering manager who cannot create opportunities for their team. Or a tech lead who cannot prioritise tech debt. You cannot avoid bureaucracy in large organisations, but you can reduce the surface. There's a case to be made to consolidate such bureaucratic functions under a single role for a team. But in smaller organisations and startups, it can perhaps be done away with entirely too.

Thank you. I fully agree with every word you wrote.

> But please, stop thinking the answer is more engineers.

The answer is to hire more product-minded engineers.

Ahh, to be young and (even more) arrogant again.

What you just described is called growing up or maturation and not limited to software engineers. The next step is to generalize the idea.

Designers should understand design, engineers should understand function - and PMs should understand the market. For instance why should we prioritise one segment over the other? How should we price the product? What are the second order effects of prioritising one feature over the other?

I am a software engineer, most of the time, PMs are just make my work harder.

Reply on news.ycombinator.com