A good PM can clearly articulate what is to be build and why. In my experience, the why is often completely lacking. Zero research. Shady A/B tests with unclear conclusions. Pretty much the "why" is often somebody deep down in the business emailing a random idea. And it seemed cool and people want to please people rather than dismiss them.
With a clear and simple goal and why, if you have half-decent engaged engineers, they can now think along on how to best achieve the goal. This could refine the feature itself, its visual design, anything. The idea that product people have monopoly knowledge on product is ridiculous.
So with a clear and hardened idea you build it. Then we come to the other part that PMs never seem to engage in: feedback.
Did it work? Did anybody use the feature at all? Was the goal met? Did we get user feedback? Often lacking as engineers are to focus on the new sprint.
Engineers can't grow or feel product ownership if they're so far removed from its real world impact.
And as for my second trigger: don't "negotiate" technical debt. The idea that it's negotiable is why it won't get done, so make a stand and remove room for negotiation. It very much is in your power to do so.
I'm sure I'll sound like a jerk because this exact idea is taken as gospel: I still 100% disagree, though.
It is a bit incomprehensible to me. How could a non-technical person decide what is to be built? It would be like a farmer deciding which crops to plant — without knowing the critical details of the soil, the seasons, or the local environment.
IMHO, the role of a PM is three things:
1. Collaborate with Engineering and Design (as well as other relevant folks, like PMM) to collect, filter, and synthesize raw customer data. Together, turn it into a clear statement of the problem to be solved. If the PM needs to be fed some "leadership" kool-aid, then, sure — tell them it's their job to make sure the collaboration happens.
2. Build absolutely bulletproof reasoning around why this problem is the most important one to solve now. Maintain and update that reasoning as the data, the vision, and the solution all evolve. (This is the "value risk," in some modern product lingo.)
3. Continuously rally every internal stakeholder around that reasoning, and clear obstacles in the way of a successful business outcome. (This is the "viability risk.")
I think we actually mostly agree with each other. Your point about having a proper feedback loop — based on real data, rather than politicking and optics — is absolutely gold (and sadly rarely done).
Giving a PM sole ownership (or even "leadership") over the what to build piece, though, is a subtly slippery slope. Down that path lies the inflation of ego, the end of equal collaboration amongst the Product Trio, and the eventual snuffing out of psychological safety as everyone else checks out and stops feeling any real ownership in the product.
> How could a non-technical person decide what is to be built?
Agreed. My somewhat controversial position is that the rise to power of product management has ruined silicon valley. We now have non-technical PMs making decisions about technical details and prioritizations they are not qualified to have an opinion on. This leads to endless technical debt, security vulnerabilities, scalability problems, fragile systems, etc.
It used to be that PMs brought in requirements from actual customers and provided reasoned direction on where the product should go given what customers wanted and the competitive landscape. This was taken as a strong signal by engineering but ultimately it was engineering leadership that decided how to fit it into the roadmap along with all the other factors mentioned above (sane architecture, security, scalability, etc).
Today in most organizations, these other factors have no seat in the table and we only have PMs managing jira sprint stories, with the inevitable outcome of lousy products.
In your farmer analogy, you totally omitted that you need to consider market demand. That’s why you’re growing things in the first place. That’s not a technical decision, and totally is something the PM should understand.
Just because a PM makes "the decision" doesn't mean this should not be informed by the engineers. Consensus is not needed, but accountability and buy-in of all involved is essential.
Just because engineers are "informed" doesn't mean they get to make "the decision" (or indeed that they are the most suitable agents to do so in terms of goals and incentives).
It's harder that it seems to figure out what to do - because many orgs don't give PMs enough time to focus on that part of the job. Mostly because research can be weeks of no outcomes - just research research research. Most product managers know they don't know the market as well as they should and they face enormous pressure to "get things done".
Another issue is the lack of political capital. Very often a product "owner" doesn't own much at all. Some may have reasonable decision power but it's constantly undermined by powerful other stakeholders.
The problem often starts from the very top. Say a CEO tells the business to grow revenue by 20%.
The business/markets then come up with terrible ideas to do that. Aggressive, cutting corners, user-hostile, but likely to work in the short term.
Then they ask the PM to implement it. You can't stop it at this point.
Yup. Honestly at many companies the CEO is the only real decision maker and everyone else is just execution. No matter what their title says.
To your point on stakeholders - most PMs are just trying their best to balance the 35 different constraints/ideas thrown at them by the 5 or 6 most important stakeholders all while appearing upbeat and happy because the PM is supposed to be Miss/Mr/Mrs Positivity.
I’m not too fond of the “separate Product and Engineering organizations” model… The whole idea of having one branch of the org chart telling another what to do is kind of flawed. I think it’s often better to divide up the product over many separate small teams, each with a product focused “mini CEO” and a tech focused “mini CTO”.
100% this, what ends up happening is product wedges themselves between business and technical so they wield the power due to having business' ear, and any attempt by technical to communicate directly with business is met with severe reactions.
The thing to understand is that very likely your technical people are smarter than your product people. In addition, part of software development is being able to identify what needs to be solved. Any developer with a modicum of experience knows how to do this.
Just as you have a technical leader on the team, you need a technical architect on the team. That person can interface with the business or the business analyst (or both) as needed.
separate teams is a degenerate case for strong software development.
I once literally had a business person ask "who should be involved in this conversation" and my response was "product and technical so we can advise". Product responded after me with "Product" and the lack of technical there was deafening.
It becomes a power play, the theory of the different departments works out about as well as putting a racist and a black man in a room to collaborate on race relations.
>very likely your technical people are smarter than your product people
Intelligence is multifaceted. That business listens to product and not to engineers could be seen as a type of social intelligence of which engineers are notoriously unskilled.
Regardless, framing any portion of your organization as "smarter than" (implicitly "better than") isn't going to help in terms of fostering collaboration.
Also a lot of PMs are former engineers. One could argue a person capable of doing both at a high level is "smarter" than a person who cannot. Certainly they would have a unique perspective compared to people who have only been on one side or the other.
But like you said, intelligence is multifaceted, and comparing people's intelligence is pointless and divisive.
PM is not product, when they get separated from technical in companies, they're literally product, as a team.
But more importantly, most of the time what happens is these people have 2, maybe 3 years of experience. They've done enough to be able to roughly understand technology, and that experience helps them communicate with the technical side, but in no way shape or form does that mean they would come anywhere close to that 20 year old vet on the development team.
But the flip side isn't true. In companies without that strong delineation between them, it's the 20 year old vet who would be doing what product is doing.
Companies who do this are too compartmentalized and they become extremely slow as a result. It's all in an effort to keep technical from having an outsized influence.
I have never understood why companies consistently hire people right out of college (often with random degrees unrelated to anything relevant) to tell a team of engineers with 10-20 years of experience what (and often how) to build.
Back when I was new, engineers worked directly with subject matter experts and the occasional business analyst. Now we’ve mostly replaced SMEs with product, and I don’t think it’s working out.
> Back when I was new, engineers worked directly with subject matter experts and the occasional business analyst. Now we’ve mostly replaced SMEs with product, and I don’t think it’s working out.
Exactly this.
Not only that, but when it works the way you're describing, it's often a 2-way conversation. The developer strives to understand the goals, then starts making suggestions to determine if the business is ok with shortcomings that would make it a lot cheaper and faster, but would fulfill those goals. They'll also dig into what the business wants in the future so when the implementation starts they can take that into account.
Instead we get product who wants to own all of that and then throw things up into a jira ticket and have it magically be great. There's no value add there.
> Intelligence is multifaceted. That business listens to product and not to engineers could be seen as a type of social intelligence of which engineers are notoriously unskilled.
To some extent that's true. I'm sure that product folks tend to have higher verbal intelligence (on average). But all forms of intelligence are highly correlated with each other, and engineers are likely higher overall. Many (though not all) of the engineers I know are quite articulate, even when English isn't their first language.
Much of the difference in "social intelligence" might just come down to being more outgoing and assertive, rather than an actual difference in ability.
> Regardless, framing any portion of your organization as "smarter than" (implicitly "better than") isn't going to help in terms of fostering collaboration.
I agree that the other poster's framing was hostile, but I am sympathetic to their frustration. I think it is helpful to remind product and business leaders that your engineers can be great allies in solving hard business problems.
It's not hostile, just a simple statement of fact.
These product teams aren't interested in collaboration, that's part of the point. A strong software developer can do products job better than they themselves can do it, but they get treated like code monkeys.
I am an engineer by trade, but I would argue product is more important than engineering. WHAT you work on is ultimately more important than HOW it is achieved from my experience. Yes, bad engineering will ruin a product, but it is all moot if you are not working on the right thing. So many companies I have worked with are working on the wrong thing. Another way to put it is, a company with a great product that has bad engineering will outperform a company that has great engineering but a bad product. Product/market fit rules all. Once I understood this I was able to work with the product team better.
Yeah I mean I work at a place that thankfully has no "product" team. That was a valuable thing at a certain place but it's been replicated needlessly and most product managers are glorified project managers with no power or responsibility.
^ and this attitude is _exactly_ why so many companies can't get anything done and why I explicitly pointed out that software developers tend to be smarter than your product people.
So lets be very clear on what I was saying.
software developers can do the job of product, product cannot do the job of software developers
It kills me how many people seem to think the doers are the least important part of it. Gamedev gets this right with the insistence that the idea guy is worthless.
I work as a software architect and I see this all the time.
It's not a job, it's a role, one that senior developers take on all the time.
It gets turned into a job and the result is business people constantly bitching about why everything is slow and what DOES get done is never what they wanted.
The reason you found it so hard is because you weren't doing the implementation, which is why software developers should be taking on that role.
At that point you're a glorified translator hoping that both sides are understanding each other perfectly. And what's worse is they both speak English!
Translating between who? I don't think we share the same experiences with companies, roles etc, so we might be talking past each other. Product is a pretty ill-defined role.
between business needs and how it gets implemented.
Companies that do this took 3 roles and smashed them into 1.
- marketing fit
- business analyst (aka domain experts)
- technical implementation
The reason you see people talking about how hard it is for product is because product gets to interface with the business and has an understanding of the problems and the proposed solutions. They try to tell technical to implement with no real understanding of both, due the reality of the phone game it's never implemented as they want, and they get frustrated.
The solution is to stop trying to make technical the tech equivalent of ditch diggers.
Yes, if you want a ditch dug it's relatively easy to communicate that to someone. Software aint ditches.
So while product couldn't begin to start implementing themselves, technical can absolutely be having those conversations with business.
I can see what you are saying if one is the environment you describe.
I've never worked somewhere where eng was treated like ditch diggers. But I've also never worked anywhere where this "business analyst" actually existed. If you build products for many customers there is no such person, because different customers need slightly different things and you have to pick a position v competitors.
Maybe try changing environments? Not everywhere works as you describe.
Most people who have done real engineering and real product jobs will tell you PM is a harder job to do well.
There is more pressure, less control, more uncertainty, more people to keep happy, more ambiguity. And the number of context switches is high. One has to be highly organized too. Crazy difficult to do well. Very easy to do poorly.
It is a lot easier to be a bad PM than an engineer, I'll grant you that. And most PMs aren't great.
What you mean is it's extremely difficult not to produce shit software with a setup like this, even though paradoxically the theory is that this should produce higher quality software.
The reason for this is something called tacit knowledge. The only way for a developer to be successful is if they have the same level of understanding that product does. Since they don't, product needs to be the one implementing. Since neither happens, you get shit software.
The solution is either product starts implementing or software developers stop being treated as line workers.
product used to be three roles that worked together. software dev, business analyst, and marketing. And depending on the size of the company, business analyst and marketing often means working directly with business because that's who collaborates between those two.
There is no value-add in product, the theory has proven out to be untrue.
Give it another 10-20 years and we'll be reading articles about how the "smart" companies are doing away with product and giving it back to the other roles and asking them to do something crazy like talk to each other.
"working with business" suggests we must be talking about different situations.
I'm talking about a company building software products they sell, eg an enterprise software product like salesforce, google cloud, aws, splunk etc. Not internal software or software built for a specific client.
It's all the same, someone has a need and you give them a solution.
That need is either driven by business wanting to improve the software or by technical wanting to improve the software. product doesn't belong in there.
product will never identify that a technical change will enable new things, for example. The ones who can do that aren't allowed in the conversation.
We are talking about quite different environments.
Trying to simultaneously satisfy many customers in a market where there are multiple options, different ways to slice and dice the customer segments, different dimensions on which to optimize a product, different ways to reach customers, different systems to integrate with, it's just a whole different ballgame to building a specific solution for a specific customer.
And at somewhere like google for example, most of the PMs are former engineers and can see technical changes enabling new things. On top of that, at somewhere like Google engineers do meet with customers, frequently. There isn't some dividing line like you describe because all the business units are run by PMs or engineers. They are "business" in your terms.
It is what it is. Your observations and suggestions may well be true and sensible in the environment you are operating in.
Yep, you can structure the roles however you like. I'd guess every plausible combination has been tried.
In my world engineers are first class citizens who have real input to the product decisions and meet customers, the PMs are usually technically capable, the PM job is too big to be done part time and hence isn't. It is what it is, and doesn't seem to be close to how things work in your world. But in my world, the product job is more complex than "someone has a need and you give them a solution". For internal development or consulting, that's probably right.
Regardless, the job is still extremely difficult to do well. Anyone who tells you otherwise hasn't really done the job, at least not outside of the simpler world of consulting/internal software where it's best described as "requirements engineering".
Then communication happened, and oddly enough, communicating succinctly was more important than listing out all possible combinations in an effort for perfection.
Your comment completely ignores my point! My point is that I want conversations on this site to be worthwhile, and divisive thinking tends to destroy that. Your example “black man” is unnecessary and creates a divisive context. I think you make the same category of error in your implied definitions of “engineer” and “intelligence”. If you might spend some time to read through the comment tree below your GP comment, and try and understand why various people are reacting, I think that would help you and the HN community. Aside: Yes, I did understand “the point” which was written about in the article. Disclaimer: I have no HN superpowers.
Edit: What outcome do you want for yourself by commenting here? For me, I want to read insightful comments, and I want to practice my thinking by challenging myself to think about topics that others know more about.
> The thing to understand is that very likely your technical people are smarter than your product people.
Weird. I was an engineer for about 13 years, and I was good at it by the accounts of others. I’ve now been a PM for 6 years and most of the engineers I looked up to along the way have either become PMs, EMs, or Architects. All of us are well above average IQ. We didn’t lose any IQ points by changing job roles.
I would suggest that if the basis of your world view is that other people are less intelligent than you due to their job role that you may wish to rethink it. You are placing way too much emphasis on the wrong thing and prejudging your (current and future) work colleagues based on an inaccurate stereotype.
theres a lot of orgs where product people will be onshore and the technies offshore, so the model and barrier kind of makes sense (for this operating model), and typically the Product people will be the more expensive/smarter/critical resource in this case.
The key to this is to only hire "product" people who grew out of either Design or Engineering, Anyone who started as "product" is a wanna be general who provides minimal value.
My usual first question to any product candidate is do you find yourself coming from a Design, UX, or Engineering background?
I’ve had luck hiring people with “dev bootcamp” level experience who didn’t excel as an engineer post-bootcamp, but know enough technical jargon to communicate, collaborate, and understand engineers.
Often these are people who became bored with day to day coding having more interest in the business side of the company
> I think it’s often better to divide up the product over many separate small teams, each with a product focused “mini CEO” and a tech focused “mini CTO”.
This only gets you so far. It tends to optimize for speed of teams but at the detriment of the overall product.
Eventually you end up with splintering of ideas, terminology, duplicate functionality and features that almost work the same way. You see it across all big companies and products. AWS is a great example of the mess they've made between services and how they don't always play well together and you end up with teams actually competing as they assert that their product should own something that's others shouldn't. I wouldn't be surprised if Google is in the same mess (Drive is a fucking cluster of a mess and it's basically impossible to use for anything productivity related - and don't get me started on how Google Classroom works within that ecosystem that's a double yikes). Same goes for Atlassian. What's the saying? Don't ship your org chart?
Can you think of any FAANG scale orgs that haven’t run into having a fragmented product landscape? Maybe there’s just a hard limit of how much complexity one business unit can handle before it stops being able to scale up. With that in mind, decentralized teams with tight product+tech collaboration seem to be a successful model. Otherwise we would probably already have seen an example of a successful tech company with centralized product/tech departments.
The fragmentation issues doesn't need FAANG scale, and is already a possibility for any org that scales past 50 people or so. If a team has the potential to interfere with another, or the need to depend on another, you already have the primordial soup for conflict and widening cracks.
I was wondering the same thing. I suspect that Apple has a strong top-down culture that's been set by Steve Jobs, so you likely have a "single-threaded owner" model, regardless of how the org chart really looks. Companies that rely on more distributed models where you have peers that have final say over their product decisions end up with splintering and features that don't align well.
Fortunately, this article isn't either. The second half of the article is about breaking down that wall (From the article):
> Eliminating the wall between Product and Engineering is essential to establishing high performing product teams.
(Quoting parent post):
> The whole idea of having one branch of the org chart telling another what to do is kind of flawed.
Completely agree, and all of these approaches are destined to fail if it turns into different branches of the org chart fighting with each other.
Most of my issues with separate product orgs have come from product executives who feel the product/engineering relationship needs to be more of a handoff or prescriptive relationship. It's not.
> I think it’s often better to divide up the product over many separate small teams, each with a product focused “mini CEO” and a tech focused “mini CTO”.
Whatever you do, don't call them "mini CEO" and "mini CTO". This generally implies that the CEO is at the top, which breaks the whole collaborative team idea that we're going for in the first place.
Our company did a restructuring a couple years ago where the web/user-facing part of the dev team was moved under the same branch with Product. At first I was skeptical, but it has worked out very well. Product Managers and the developers feel like they are on the same "team" working toward a better product. There's a lot more collaboration with PMs trying to get developer input/insight, etc. Things used to be a lot more siloed, and I think it really hurt innovation.
I disagree but the thing I'd disagree most about is calling your product managers a "mini CEO". That exact mistake as led to some of the worst product outcomes I've witnessed.
I think it sets the wrong expectations for those product managers but in terms of their duties and in terms of collaboration with their team members.
I've seen product managers who thought they were _managers_ actually in charge of the people on the team and this led to frustration. OR they thought they were decisions makers who had some measure of authority instead of just another member of a team with a specific role. In general collaboration with
And when I think about the product managers, I've worked with who described themselves as "mini-CEOs" they lacked basic product management skills. For example: focusing on the what over the why, being overly process driven, and lacking a cohesive vision for what the product will be long term.
I can't tell you correlation-causation here. Whether the description of "mini-CEOs" attracts people who are bad at product management or whether telling someone their job is to be a "mini-CEO" causes them to behave poorly.
What you're describing is how it's already usually done, from what I've seen.
But the PM still reports to a director of product, and the TL still reports to director of engineering.
And when the director of product and director of engineering have different visions and priorities and criteria for promoting, that's the problem described in the article.
And you certainly can't have engineering report to product or vice-versa... I've seen both before and it's utter disaster.
That's usually what happens: assigned product people to engineering teams who focus on what the engineering team works on, then they report one level higher.
You shouldn't be seeing a new decision-making Product person every month or so - that's bad news bears.
It gets to this state naturally if your product is fairly large and has loose/well-defined modules that are distinct from one-another.
Take a rough guide to military planning and you see "strategy, Operations and Tactics" not "business vs tech".
And the prevailing direction is towards "mission command" - where each level provides the resources down to the next but it's not "directing" as opposed to "hand off"
yeah i was at a startup that had SVP of product and SVP of engineering. For the entire year I was there 60% of the time was spent in meetings where they just blamed each other. Engineering would say product didn't tell us what to build so we just built what we thought they wanted and product would say they told engineering what to build but they did it incorrectly.
The company I am at now has a leader who has product and engineering reporting to them for their charter basically following the mini-ceo/cto you described. It has its issues but works much better than the alternative.
The leader who has product and engineering reporting to them is a CTO. Someone who only does one of those things is not a CTO and shouldn’t have C-level decision making power.
I'd be convinced it is a jobs program for overqualified ivy league grads, and as a SWE I thought that for a while, but a GREAT product and/or project manager is worth their weight in gold.
That being said most of them I've worked with in FAANG/FAANGlike are meh to terrible.
Product really suffers from the worst part of being a manager, where you don't control the outcome of other people's work, with the ability to blame shift a lot easier than being a manager since you're managing a product not people. This also makes them super mercurial and since they can move around a lot.
It's doubly an issue, bc a good/great engineering team can compensate for dumb product decisions or timelines with crunch and overtime that destroys the team. Product manager can say see what a good job I did, and then dip to another team before any of the consequences are realized.
They end up doing tons of useless CYA type stuff that gunks up the works under tight deadlines. 90% of PMs I've worked with paid lip service to "unblocking" you, but at best would function as an email relay.
That said, great PMs are fucking fantastic at large orgs.
Project managers: know who to talk to, when to escalate quickly, get everyone on the same page including bad managers, unblock engineering by dealing with all the status update bullshit. Build reasonable timelines, fight scope creep, hold people accountable, and do reasonable amounts of CYA to make disputes quick.
Product managers: Do fantastic market research w/ rigorous testing, constantly talking to users, building a consensus on the team on the product vision instead of just throwing commandments to the engineers. Focuses on the important features that drive impact instead of throwing the kitchen sink in there, takes feedback from engineering on the product, and pulls everyone's work into the view of leadership.
EDIT: One more critical thing PMs should do is be able to get tradeoffs and make a business decision. Under a tight deadline should we prioritize the feature working w/ constraints or delay further.
> 90% of PMs I've worked with paid lip service to "unblocking" you, but at best would function as an email relay.
Too true. And it’s even worse on the receiving end, because all too often this “unblocking” is basically just adding an @-mention to you in Slack with zero context (hope you enjoy reading a 200-message slack thread trying to understand the context!) or just adding you as a CC to an already extremely long email thread (again with no summary of what’s being asked, hope you enjoy reading 100 levels of indented quotes figuring wtf it is they even want.)
All this ends up amplifying confusion… a problem can go from 99% solved and only needing a question from another team, to several meetings where everyone’s confused, all because of miscommunication that is made worse by the very PM’s that are supposed to be helping the matter.
If you can’t tell, I’ve never met or had a good PM in my life. Not one.
The issue has been and always will be that if you only let Product determine the what, the wrong thing will be built almost one hundred percent of the time. They lack the ability to describe the "what" in a way that's practically achievable. The exact same problem exists with Design.
These people are good at their jobs, but only if they have the humility to admit that they should not be defining requirements on their own.
Development, Product, and Design require an equal voice and agreement on direction for all endeavours. Win together, lose together.
If Product don't include me in requirements gathering at all, it's their fault when it falls apart. That's hubris. It's equivalently my fault if I don't engage them. Engineering should never agree to build anything they didn't have a say in because they actually build it and can find problems with the "what" that were never even dreamt of. Equivalently, the best Product people I've worked with have always had a good idea I hadn't thought of.
Positioning one group to have final authority is a fatal mistake. The final authority already exists naturally - it's cost/benefit/time.
I've become pretty skeptical about "Product Management" as a function. I feel like it's one of those ideas that's cargo-culted from Google without anywhere near the same rigor.
A good product person is worth their weight in gold but holy hell there are a lot of charlatans out there. These days I prefer to work at companies without PMs, as an engineer the odds simply don't work in your favor.
Counterpoint: I've seen the fallout when you get teams of very smart technical people who don't have the product management skill set.
They:
- Prioritize building the wrong thing
- Don't prioritize customer interviews and think they know what is best for users, which can be a double whammy when you consider social skills are not always a strength of very technical people
- Don't understand the role marketing or sales plays in the success of the product because of their limited understanding of those roles and preconceived notions that prevent them from collaborating effectively
I've also met plenty of supposed technical people who fail to ship code or grasp some of the technical concepts for the work they are supporting.
I think it depends on the product. If it's something that's fairly common and easy to grasp for the typical engineer then I agree. If it's something very domain specific (accounting, legal etc), then I think having a PM that has knowledge / expertise in that area makes a lot of sense. You don't want the engineers spending months / years learning about accounting principles or legal nuances.
I have never worked for a company where the PM was an honest to goodness subject matter expert. There have been PMs who learned a lot about the domain, the same way good experienced software devs do.
But the majority of the time it feels like we just stuck a middleman in between engineering and the real subject matter experts.
Fair discourse: I have worked at Google, Credit Karma and now Sivo (YC W21) as a (technical) program and product manager.
I know for a fact that Google doesn’t actually have “Product Owner” as a role in their org chart.
At Google, the separation is:
Product Manager (Vision), which is focused on gathering business needs and driving the Feature Roadmap.
Program Manager (Execution), which focuses on finding ways to unblock delivery of the vision with cross-functional teams, such as getting designs, legal approvals, etc.
I recently experienced a Product Owner for the first time when hiring one at Sivo (YC W21).
It seems like Product Owners exist to accelerate the Roadmap vision into Epics and Stories in solutions like JIRA so product visions are more actionable by engineering.
Similarly, while not a role at Google, I have heard that some MegaCorps will have “project managers” that often report up into Program Managers. This is similar to the product owner and product manager relationship.
Thank you! That is the first coherent explanation I've seen. Reviewing these in the light of agile software development in the form of scrum and kanban:
I'm struck by how close your definition of Product Manager is to the idea of Product Owner: a person who understands the interests of the users and the business and prioritises work in order of bang for buck. Someone who is really good with the 80/20 rule.
It also explains to me why no-one can explain the transition from PO to PM: the people who think there is any difference did not really understand the PO role.
Dividing work up, organising an issue tracker etc. are tangential activities that POs frequently perform, but they can also be performed by anyone else on the team.
I'd argue that when you reduce the "owner" to the person whose only job is these tangential things, you actually hurt the team by taking initiative away from engineers. Engineers should be capable of organising their own work as a team, and should be considered junior if they can't.
I first encountered the ideas of programme manager and project manager in the pre-agile world (from orgs that liked PRINCE/2). It makes sense to me that the programme manager role exists now in a larger team of teams of teams environment. The agile manifesto was about small teams and didn't really have anything to say about larger projects.
A hat tip to scrum masters who seem to have been sidelined in the product management world, because their (no-less important, when done well) role was to unblock in exactly the way that you describe a programme manager doing (plus understanding people and improving collaboration). The main difference I can see here is that a scrum master was usually responsible for one team only, which was probably too little authority to compete with the ambition of product people and the disinterest of business executives. Hence no surprise that the role has disappeared.
The "project manager" role isn't something I've encountered recently, but seems like what it always was (what you get when developers aren't/cannot be trusted to take initiative). It sounds like a more honest title than watered-down "product owner": these orgs never understood agile or product and just gave their project managers a new title.
The Product person spends all their time understanding the market and figuring what to build, who to target, how to work with marketing/sales, how to price it, what the competition is doing, syncing with other PMs to make sure everything is coherent, communicating around the org to people who need to know, answering questions from legal/accounting/sales etc. The engineering manager can focus on how to build it, who should work on what, engineer's careers, technical challenges, team stuff and many other things depending on the circumstances, and the program manager can project manage, focus on syncing eng efforts across teams, moving blockers etc.
Those three things are an enormous amount of work, each one. If anyone tries to do more than one they will suck. There are exceptions... some people are able to pull it off. Those people should go start a company and not be PMs.
At least in my experience, good engineering managers had a lot of input into the product function because they were paying attention to the customers and had insight into what could be built - part of the reason they are a manager is they have more than eng skills. The PM and EM need a good relationship and usually do, at least at Google. The program manager has less input to what to build.
Outside of Google the product management function does indeed seem to be... pretty awful for everyone involved. Bad PMs annoy everyone and give the function a bad rep, good PMs come in and are treated poorly (due to bad function rep) or have silly expectations put on them due to a lack of understanding of the function, and leave.
> Outside of Google the product management function does indeed seem to be... pretty awful for everyone involved.
If the best product managers are at google, then that's very damning, given that Google are notorious for having awful product sense. I'm not convinced that's true though. I've worked with good product people at small companies.
I'm not saying that - I'm saying the job and whole situation around it is pretty awful, for everyone, outside Google. And it's a sweeping generalization. There are obviously going to be pockets where the opposite is true.
That said - I don't think Google PMs are notorious for having awful product sense. They do seem to get hired at a lot of places. And product sense is a wishy washy term. If someone tells you they have great product sense ask them why they don't have a billion dollars.
I can’t judge Google PMs. But Google the company’s products are not good. Often they start out good, and then get progressively worse, stagnate, or are killed off entirely!
Regarding why product people don’t have $1m. I would suggest that building a great product is not sufficient for that, you also need to be able to sell it.
>> I would suggest that building a great product is not sufficient for that, you also need to be able to sell it.
I might be putting toooo much responsibility on product, but realistically to have a good product in a good market, it has to be sellable - ie built with the distribution in mind so that an economical go-to-market is within the control of the company. For large enterprise customers the product might built with direct sales in mind - high price, high value, features large enterprise need, sufficiently defined buyer group etc. If one doesn't factor that into what product to build for what market, I don't think they have product sense.
In the most functional engineering orgs I've seen, this is the correct setup. There are clear and concise goals for each. (Everyone should know a bit about the other ofc.)
Most super early startups I've seen w/ serious problems can be traced back to the founder doing all three and sucking at each.
Only thing I'd say is that it's not just PM/EM that do scoping and input on product but the whole eng team. The healthiest teams I've been in used that setup and it worked really well.
This is how you end up with 8 bosses like in office space. EM, TL, ATL, PM, PgM are all telling you what to do and asking for status updates. I wish there was someone to liase and multiplex all that, but I think they all think that's what their job is.
I feel like the difference is company dependent, but in my experience the difference, or at least the difference that is wanted is that a product manager implies a manager of both the end result and the process by which that end result is met. A product owner is someone who decides WHERE the product goes, but has no say in how the engineers make that happen. Its their job to set priorities and keep the product going forward but they have no tech management authority.
Product Management certainly predates Google by at least a generation. Indeed, Google is notoriously skeptical on the product management role and requires their product managers to have a technical background to at least some degree.
Google isn't skeptical of the product management role. They are skeptical that non-technical people can do it well. And that's mostly right, but there are exceptions.
What is true is there will be fewer VPs than people they manage, fewer PMs than engineers, and fewer CEOs than almost everything else. ;-) </pedantic>
Given that principle though, what do you think I meant by "When I look at the ratio between engineers and product managers, it seems they are skeptical about the role."? Do you really think I meant that since there are fewer product managers than engineers, I've concluded they're skeptical about the role?
The statement suggests a belief there is some information in the ratio.
Google tends toward about a dozen engineers per PM overall. It varies across the org depending on the product. Google is explicitly pro PM. The CEO was one. There is no information in the ratio.
Product management is clearly a legitimate function. A good PM embedded in a cross-functional team can make a night and day difference.
Problems seem to begin when product management is externalized from the product teams, put into dedicated teams or departments. The role is seen as something like "telling the devs what to build and making sure they build it."
The very first figure in this article illustrates one of my pet peeves: We see a classic S curve productivity chart and then we immediately attribute it to some sort of management failure instead of pure unadulterated reality.
As it turns out, the S curve is a plot of the area under a bell curve; at the beginning of the project it's hard to get traction. At the end it's hard to cross all the T's and dot the i's. Most of your velocity comes in the middle, which is why it's so hard to plot an intercept.
We usually make the fiction of the intercept into reality by accumulating tech debt more quickly. If you're very lucky with your engineering culture, you are maintaining the slope of the line at the end because you built a culture of competence along the way and you are now capable of completing more tasks per unit of time than you were at the midpoint, often by sacrificing throughput before the midpoint.
What I have noticed even in top engineering companies is an interesting dichotomy. Product determines the "innovation", engineering determines how to build it. I wonder if thats because, if you let engineers do both, you end up with a mess and accomplish nothing. Programming is hard enough, programming within well defined barriers and goals is much easier. You have a low risk cycle of design -> code -> test.
The issue is that often product is not technical enough to bake in technical possibilities to how they think about innovation. Not always, but I have seen this happening even on recommendation and ML marketing systems for some of the large most sophisticated companies.
> I wonder if thats because, if you let engineers do both, you end up with a mess and accomplish nothing
No, it is because an Engineer (with technology selection blinders on) will jump to a What/How before the Why actually lands in a conversation.
The why will be recorded as "what the customer wants", we jump from problem to solution too fast.
In fact most of the times the product org only provides a "What" to the engineering team which is where most of the problems are buried & plays it close to the chest with the "Why".
I was an engineer reporting to the CPO in my last job and my entire job was to diffuse the "Why" down to the engineering org, so that they felt purposeful about the problems they were solving & to push back on the What if there's a better solution possible. But I didn't get to redefine the "Why" part of the question, even though I really wanted to do it to make more progress in the directions I was already headed.
Once you got "what", then you get to "how", "who", "when" and usually "how much?".
The message usually bounces off the end of that and goes back, to the customer who's eventually going to solve the "how much" problem.
>is because an Engineer (with technology selection blinders on) will jump to a What/How before the Why actually lands in a conversation.
I'm in marketing/biz dev now at an engineer-led company, and in a meeting last week a dev team presented a new UI that is a MASSIVE departure from our current approach. At the end of the demo, they informed us that a) it's being released in 2 weeks, b) do you think the clients will like it, and c) can we charge more for it?
> What I have noticed even in top engineering companies is an interesting dichotomy. Product determines the "innovation", engineering determines how to build it. I wonder if thats because, if you let engineers do both, you end up with a mess and accomplish nothing.
The top companies have product and engineering working closely together. This allows product people to go deep on optimizing their product skills and engineers to go deep on optimizing their development skills, both of which are most effective when performed in conjunction with each other as part of a strong team.
There are great product-minded engineers and great engineering-minded product managers out there, but it's much easier to find people who are simply good at their domain and know how to work closely with people in other domains to get things done.
Some companies try to cargo-cult this by drawing a dividing line: Product defines the "what" and engineers define the "how". Product works in isolation, hands things off to engineers, then engineers churn through tickets in isolation. This is not good at all.
In my experience, it's way too easy for engineers to geek out on the how without addressing the "why". I'm guilty of this myself, from time to time.
When product is leading the charge, it often means they've validated a need from a customer and are ready to address it. When engineering leads, they're often pushing a capability without having evaluated it against customer needs.
On the contrary, I've seen product teams assume the pain of the consumer and relay the same to engineering; and then engineers having to push back on the insane requirements.
Nevertheless, product which work in an agile model without collaborating with tech is doomed to fail
I think we've settled on the wrong model for product management, and it's serving us poorly both at our companies and even as a society. Everything you hate about name-a-tech-company is because some product manager's bonus depends on them getting something from you that isn't what you want to actually do.
I don't have a better answer, I sure as heck shouldn't be planning product strategies for the web companies I've worked for. But this isn't it.
Here's a different twist on these issues that I don't think comes up all that much. (B/c it's pretty niche).
How do you deal conflict between product engineering teams <-> Infra Engineering teams.
Particularly when Product Engineering teams have product managers and the ability to say, business impact is X while infra teams don't.
It's a pretty difficult nut to crack at least at my current org, because the near term goals (usually) align, but longer term goals separate out. Eventually the product team becomes parasitic and destroys the infra team. From what I can tell looking at orgs like this, usually the eng team picks up the slack of bouncing tasks as much as possible to keep up. (But all the extra work slows things down.)
E.g.
Product team wants to build feature X, their PMs and managers all line up to say it should be in Infra, infra team says no, but then leadership vetos it because it's the only way to keep the product team on track. (Because they have the most influence in management.)
This happens two or three times, the infra team is now fighting over piles of technical debt in order to get things out, and can't work on new features to attract new customers to keep the current one happy. (and justify their existence.)
This is part of a whole series[0] that I am reading and finding quite insightful.
I think the "pull quote" for me, was this, from the immediate article:
Establish team working agreements at all levels. Ensure every team member knows what role they’re playing
I think this is a real problem not just in scale ups, but in a lot of engineering organizations. There's no working agreements on what roles that each part of the company plays and expects others to play, its often weighted against some preference of higher up management (often VP / executive / director depending on the size of the org and influence each layer has) that creates these silos and break downs.
I think its uncommon to think of start up environments like this, but it is entirely true, once you get past a certain number of employees and start having more delegation layers (directors / VPs) you start to run into these silo problems quickly if you aren't aware of them or don't actively do something about preventing them.
Whole thing is worth reading though, very insightful to me at least!
Bad (and common) engineering managers avoid agreements on purpose to:
1) cover their asses
2) change anything at will
If you never agreed to anything, then you can keep demanding whatever, and blame whoever as well. It's a really shitty management style. I left such an organisation not too long ago where I would say that the engineering department survived not because of, but rather despite of the head of that department. First few years nobody had a clue what he was doing most of the days and when he decided to get actively involved it was obvious he had no clue about anything. He still has no clue but he's made sure to surround himself with incompetent yes-sayers to cement his position.
Early in my tenure running a Product team I decided that one of my goals would be for PM/Design and Engineering to be as close as possible. I would literally say that I wanted them to view one another as brothers/sisters, and tried to set the example that we would go to bat for engineering (and expect the same) in almost all cases. I think it was probably one of the best organizational decisions I ever made.
I'm a Chief Product Officer at the moment with both experience around product design, UX/UXR, product management — but also a very deep software engineering background.
I certainly have some blind spots, but it's a real advantage to be able to communicate a cohesive narrative and build "one" team (with lots of fantastic disciplines and even, at times, some intentional silo'ing). I can describe the why behind our prioritization, but also keep in view the strategic engineering investments we'll make to support our product vision over the long-term. Will it scale forever? Who knows.
But I absolutely believe in fully-integrated product teams. You can really ship some amazing work when you get it right.
I have seen cases where pm is close to developers or close to the business leaders. Sometimes too close to either group excludes the other. A balanced pm is preferred.
The elephant in the room for me is that it’s only the existence of “product organizations” that create the problems described here. Product skills are a vital PART of a multi disciplinary team, but should not be separate or - heaven forbid but just the unfortunate reality - consider themselves in management over or otherwise in charge of any other part of the team. You want to make software? Fine, come be part of the team with me. We’ll work together and make great things happen. Don’t fool yourself that things will be better if you just tell me what to do.
> Leaders should set a principle and expectation of a blameless culture. When something goes wrong, it’s a wonderful learning opportunity, to be studied and used to continuously improve. An example of this is the concept of a blameless post-mortem.
I understand this idea. I've read several books on the subject and worked to integrate it into several teams now. I think it's an admirable goal.
But the blameless culture idea becomes counterproductive when taken to extremes. I've been in a couple "blameless cultures" where a small number of people were clearly to blame for every project falling behind, but every retrospective was about how we could have organized our work better, or planned better, or been more clear about the expectations. No, at some point, the only way we're going to ship better is to shine some light directly at the one poor performer on the team that everyone knows is to blame. That doesn't mean being mean or rude or calling them out in public, but something must be done.
In my experience, there is a thin line between "blameless" cultures and "responsibility-less" cultures. Blameless cultures accept that we are all human, make mistakes, have off periods, etc. "Responsibility-less" cultures are as you describe -- they eschew honest conversations about the actual forces that affect projects. Instead they tend to repeat the same process discussions ad nauseum, typically discussing symptoms rather than the actual causes.
Since we as humans often prefer to avoid conflict (sometimes at all costs), it's not uncommon to see companies tilt towards the latter. This is exacerbated in "scale up" environments when rapid personnel changes make it difficult to build the kind of trust necessary for direct, honest communication.
Yea there is a balance between giving engineers power to effectively do their jobs and limiting the amount of damage they can do. You can put up more guard rails for engineers, but it will most likely make it harder to do their job or deal with production emergencies. What is also tough is if you have a group of highly privileged engineers who can manage not having guard rails except for a few cowboys who cause problems. You can limit the capabilities of the entire group to deal with the cowboys, but then you are making all of the responsible engineers less effective.
One solution is to move the cowboys to a position where they can do less damage, another is to make the cowboys responsible for their repeat offences, or you can just go full up blameless and have to deal with outages caused by repeat offenders.
I have seen this in action at my org — we basically have a chaos monkey who is a person. They cause an outage and not even a week later they are doing dumb/overly risky actions again.
It feels hopeless because I don't think their incentives align.
The PMs want to get features out asap. Test out ideas asap. They want to get new work into production.
The engineers want to build features that are well thought out, low maintenance. This takes time.
PMs can get engineers excited and get them to want to work quickly and worry about the little stuff later. The problem is the little stuff that needs to be fixed never seems to become a priority because the next new feature needs to go out. But only the engineers are responsible for the fixing.
I've seen it work, and I've seen it not work a lot.
The key to getting it to work is to build an environment, a culture, where the product testing and feedback is baked into the process and communicated directly to the engineers and designers doing the work.
It looks a lot like a race team building and operationalizing a new racing platform. The movie ford vs Ferrari captures it well. Pragmatically in what I do (design medical devices and robotics) it looks like regular "labs" where you test your prototype product in real world conditions, gather feedback, and iterate the design based on that feedback. It doesn't work when those functions are siloed. I.E. The lab people run the lab in a vacuum, write up theor findings, send them up through their management then back down through engineering management then to the individual designers. This doesn't work, it's like the game of telephone, the end is never what was initially communicated.
What works is to entrench those two together. The designers doing the work attend and are part of the labs. They know first hand what to do and why. It cuts out the miscommunication and also cuts out 50% of the needless work and meetings.
Why do so many companies separate product and engineering if it creates all these problems?
In my experience it works better when engineers report to product engineering managers. The only trade off is that you have to find engineers who have good product opinions, and product managers who the engineers actually want to be managed by - which helps you execute, anyway.
Senior Product Manager here - let me tell you it is a horrible job to do well and a constant battle (customer, politics, management, engineering, Ux, money etc)
I believe more in the PM, UX Lead and Tech Lead trio and very good collaboration. All this « mini CEO » are clickbait articles - in the end a successful PM can lesd while getting constructive feedback and saying no when necessary.
Unfortunately few organisations are willing to put the money into training product and product-mindset into an organisation which is one of the main reason for failure IMHO.
Already lost me at attempting to introduce the material highlighting trust issues at a startup.. like who can “boil it down” with a group of humans as tiny as a startup’s typical size? Product and Engineering? The pretentious tone knows no bounds.. Is that even worth talking about businesses at that stage? Lame. And come on, like he’d be in touch with the scrappy startup vibe at this point knowing what he would charge for consulting.. No thanks!
Hard to get right, becomes a mess if you don’t. The toxic us vs them attitude can quickly take over and jam up any hope of progress. Having them on one team is helpful. Also having a healthy org culture of no blame games, mistakes are not ideal but they happen, and focus on spreading happiness to your customers in a sustainable way for everyone also plays a role.
First of all, I think that the title "product manager" is not a very good one, and is actively harmful. While it is technically correct, the word "manager" in most people evokes the idea of managing people, and there is a very short step from there to seeing PMs as ones who "manage" everyone involved with the product development. "Product owner" is not much better either.
But we don't have a much better term, so PMs it is.
For all practical purposes, the amount of features a software product can have implemented is virtually unlimited. In reality, features can only be added over time, and the role of product managers is to guide the prioritization by making product decisions. Long time ago, in a talk at a startup event, I compared PMs with the people being quartered in medieval times [0]: the product development process is pulled in different directions by various "horses" - groups more or less directly involved in the development and use of that product, and the PM's role is to balance those horses and prevent any one of them of dragging the whole thing in its direction. (I have identified those horses as, respectively: sales, marketing, end users and engineering. This is a common arrangement, but others are possible in some environments.)
Ultimately, the PM should have enough understanding of particular interests of each of those groups to be able to make informed decisions. Sometimes, the priority will be to make the product easier to sell (e.g. add this feature this potential customer is asking for); at other times, the priority will be to resolve some technical debt to make deployment faster; and so on. Obviously, that understanding does not come from vacuum; it requires talking to the representatives of the all of the "horses" and gathering all the necessary information.
In practice, it is common - as some other comments have mentioned - for the PMs to succumb to the pressure of the "business" side of the equation (sales and marketing). As a technical lead, I have always made a point of working together with the PMs and help them keep that balance.
In my ideal world the role would be called something like "product developer" with the responsibility to develop and articulate a clear vision for the product (with a holistic understanding of "product").
"Product Designer" is becoming a more common role at big companies these days, and tends to have a similar role to a traditional PMs. Usually from a designer background.
Product developer (or Product Engineer since we use the word engineer everywhere). Compare team A = {software engineer, product engineer, design engineer, qa engineer}, and team B = { software engineer, product manager, design engineer, qa engineer }. Team A screams "all team members collaborate the same way when it comes to build a product". Team B screams "there is 1 manager, and the rest are not"
Does "Product Lead" evoke similar (negative) thoughts for you? I find that title (and anything "... Lead") carries the least connotation.
And IME, in an org that has PLs, PM becomes "one who manages PLs" - otherwise, if there are PMs but no PLs, I get the impression they are mostly Project Managers, rebranded to Product Managers, but without any of the Product responsibility or thought.
> at other times, the priority will be to resolve some technical debt to make deployment faster; and so on
It's interesting you mention this. In my experience, PMs have only owned end-user experience, they come up with end-user project prioritization. The consolidation of asks from various departments was instead done by dev managers/directors/VPs. So for example, a dev manager decides between a customer-facing feature and some tech debt to make deployments faster - contrasting short term deliverables with long term velocity of the team.
> they come up with end-user project prioritization
Then they have failed from the beginning. Technically, everything you do affects end-users - including faster deployments - although in some cases that effect is more obvious than in others.
In a perfect world, each product (or, in a complex system, a well defined subset of features within a product) should have a dedicated representative of each of the "horses", who should agree on the priorities - with the product lead (thank you @Jenk!) guiding the process and helping resolve the conflicts.
> Technically, everything you do affects end-users - including faster deployments - although in some cases that effect is more obvious than in others.
I agree with this. This is why the dev managers/directors/VPs own the _delivery_ of the business goals for the year. They balance the customer-facing improvements with internal improvements which affect development velocity (deployments, ops, how easy is it for new employees to onboard onto a code base, how easy is it for someone with <2 years experience on a codebase to ship a feature, etc.).
So PMs in collaboration with dev managers own _what_ customer-facing improvements to deliver, and the responsibility of _how_ to deliver and the actual delivery falls on the dev managers.
I'm not proposing this as a new model, I'm saying this is what I've seen been followed in some companies.
I think this runs back on "Innovator's Dilemma"[1] and "... they didn't think if they should build it."
I say it is also a failure of scaling and power struggle. Because you have to have a VP for engineering and a VP of product to show to your customers and to your employees right?
As the article does well to point out that backfires in so many ways: "engineers get stuck due to lack of context." Imagine the market needing a bridge and internally to be playing pantomime on "we need a beam I think of x weight..." Try to build a plane that way I dare you. Software is fine as you can just convince the customer to buy extra hardware.
That sucks of course if you expect to consider your employees as resources in a factory chain because of course those models apply cleanly to engineering work... (That last sentence was sarcastic.)
Companies do it because it is cheaper to have people multi task in the short term and ticks boxes. That's what kills companies so I am fine with that I guess. More companies will sprung that will be better hopefully.
source: worked on the 787 program, the hardware for our team was selected before there was a team. Our part was only successful and on time in large part because I'm a stubborn asshole.
Thanks for the input!
I have only second and third hand input from the 787 program so didn't want to imply anything there.
I hope Boeing fixes that managerial issues leading to what you describe as I am a fan of its historical product in general. (If I am reading your comments right and I am not blinded by my pre-conceptions.)
Boeing isn't Boeing anymore, it's McDonnell Douglas wearing a Boeing skin suit.
I think that example is slightly tangential to your thrust, but sort of illustrates the bigger problem that when a project is operating anywhere near the boundaries of logistical possibility, it becomes very hard to incorporate perspective from the people with boots on the ground, who know ten ways to get something done and that your suggestion isn't one of them.
It's the same problem General Contractors have with trying to herd architects who try to design at the limits of materials science and don't understand that there's a large gap between physics and execution, where building codes, manufacturing defects, and the ravages of time all live. Not to mention costs (exotic materials often require exotic labor).
The role of "Product Engineer" is a deeper solution to this issue that I find appealing.
But let's do away with the term "engineer" almost completely, because what the average web application developer is doing is hardly engineering. The tools are at the point where most of the computer engineering has been abstracted away to the point where developers can primarily focus on business logic. Most experienced web application developers that I know have already been doing product work in their day-to-day routines. People who actually write code in direct contact with customers and their needs is highly efficient.
Our industry needs an order of magnitude less people who do not write code. In my view everyone should be a programmer of some sort. Our management tools are programmable yet management will not lower themselves to the ranks of the manual laborer and instead will choose to hire someone to program their management tools for them. This is highly inefficient. I'm sure we would see less meetings if management actually had something worthwhile to do with their time.
I do see a need for computer engineers in that they should write the tools that the other programmers use for these kind of domain-specific purposes.
Great insight. Like Hal Abelson said, nowadays it's more of a matter of how "you use various kinds of programming styles and techniques like combinators to glue things together." This lowers the bar to programming to more people, making the excuse "i'm not technical" less and less relevant.
You may have had the pleasure of working at places where developers are very self-directing and don't need constant hand holding. As an engineer (developer) of more than a decade that has since transitioned to product, my experience is that developers (again, just in my experiences) at places I've worked are entirely are completely incapable of knowing what to build. They don't ask the right questions and they don't understand the business needs well enough to know the right solutions. They get stuck at the smallest hurdles and I have to guide them over each and every one of them, even when it's 98% a technical problem (which legacy database should this application be populating? I don't know, let's ask the PM instead of consulting technical documentation or running our own profiling to determine this). They don't want to make decisions around anything at all.
Managing questions and making decisions for a team of 6 is easily a full time job for me combined with client management and meetings. I work a lot of extra hours to do actual PM work on top of that. I realize this is also largely my organization's fault for not having a dedicated project manager, but that's still not really helping me see your argument about needing fewer non-coders.
What if instead of you and a team of six developers there were just yourself and one other who did all of the development as well as product work? And what if the tools you were using for development and even the language itself were geared specifically for your domain? What if you have computer engineers who worked on the language and tools so you could focus as much on the customers and the product? People use Google Sheets without having to know anything about how Google Sheets is written or deployed!
My theory is that a lot of management is there in an attempt to make up for all of the organizational inefficiencies and that meetings are mainly there to make up for inefficiencies in communication because of the divide between the "what" and "how" at the same level of abstraction.
I'm perfectly fine with top-level management keeping all of their programming confined to a spreadsheet but even there I see room for improvements to their tooling!
This should in turn reduce not only the layers of management but the need for managers to make up for the inefficiencies between "person dictating idea" and "person implementing idea".
It's also a sign to me that our tools for product development are too general purpose and we would benefit from less capable and easier to learn and use DSLs. Those DSLs should at least be extendable from in-house computer engineers who do in fact worry about things like data storage, CPUs, and memory management.
The Us vs. Them dynamic always fails. The "We are all in this together" bs also fails because is empty rhetoric. What works is surround ALL SIDES of the organization with people with superior soft skills.
A good PM can clearly articulate what is to be build and why. In my experience, the why is often completely lacking. Zero research. Shady A/B tests with unclear conclusions. Pretty much the "why" is often somebody deep down in the business emailing a random idea. And it seemed cool and people want to please people rather than dismiss them.
With a clear and simple goal and why, if you have half-decent engaged engineers, they can now think along on how to best achieve the goal. This could refine the feature itself, its visual design, anything. The idea that product people have monopoly knowledge on product is ridiculous.
So with a clear and hardened idea you build it. Then we come to the other part that PMs never seem to engage in: feedback.
Did it work? Did anybody use the feature at all? Was the goal met? Did we get user feedback? Often lacking as engineers are to focus on the new sprint.
Engineers can't grow or feel product ownership if they're so far removed from its real world impact.
And as for my second trigger: don't "negotiate" technical debt. The idea that it's negotiable is why it won't get done, so make a stand and remove room for negotiation. It very much is in your power to do so.