7 ms·

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 bee

by ath3nd 3y ago

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.

alistairSH 3y ago
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?
- lol768 3y ago
  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.
- laurels-marts 3y ago
  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.
  - alistairSH 3y ago
    So you DO have a product manager. You might not call them that, but that’s exactly what they’re doing.
    - ath3nd 3y ago
      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?
      - tomrod 3y ago
        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.
    - lol768 3y ago
      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!
      - tomrod 3y ago
        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.
        ath3nd 3y ago
        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.
  - allsunny 3y ago
    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.
- ath3nd 3y ago
  > 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.
  - alistairSH 3y ago
    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).
    - ath3nd 3y ago
      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).
      - mike_hearn 3y ago
        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.
- allsunny 3y ago
  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.
  - alistairSH 3y ago
    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.
- 015a 3y ago
  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.
naijaboiler 3y ago
What was the product being built.
andruby 3y ago
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)
flappyeagle 3y ago
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.
- liquidpele 3y ago
  Pffft, they train the juniors? Hahaha, that’s funny.
  - solatic 3y ago
    https://careers.microsoft.com/v2/global/en/students https://careers.microsoft.com/v2/global/en/students https://www.google.com/about/careers/applications/students/ https://www.google.com/about/careers/applications/students/
- jsdwarf 3y ago
  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.
  - aleph_minus_one 3y ago
    > 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.
015a 3y ago
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.
ako 3y ago
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.
- suction 3y ago
  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…
- ath3nd 3y ago
  > 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.
anon3949494 3y ago
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.
jasondigitized 3y ago
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.
- StableAlkyne 3y ago
  Could you elaborate on what you mean by that? Is it the standard scope creep / premature generalization pattern, or something else?
  - stavros 3y ago
    If I had to guess, it's a lack of adequate market research.
  - OnlineGladiator 3y ago
    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.
    - cebert 3y ago
      > 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.
codingdave 3y ago
"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.
nfm 3y ago
What kinds of products were those teams building?
jsdwarf 3y ago
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.
NearAP 3y ago
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 https://news.ycombinator.com/item?id=25975417
- idopmstuff 3y ago
  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.
deleted 3y ago
[deleted]
SkyPuncher 3y ago
If you don't have product, who is talking to customers on your team?
sublinear 3y ago
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.
satvikpendem 3y ago
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.
- jjav 3y ago
  > 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.
snapetom 3y ago
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.
achow 3y ago
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).
featuregag 3y ago
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.
- ath3nd 3y ago
  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.
  - featuregag 3y ago
    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.)
ike2792 3y ago
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.

by ath3nd 3y ago

alistairSH 3y ago

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?

lol768 3y ago
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.
laurels-marts 3y ago
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.
- alistairSH 3y ago
  So you DO have a product manager. You might not call them that, but that’s exactly what they’re doing.
  - ath3nd 3y ago
    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?
    - tomrod 3y ago
      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.
  - lol768 3y ago
    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!
    - tomrod 3y ago
      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.
      - ath3nd 3y ago
        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.
- allsunny 3y ago
  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.
ath3nd 3y ago
> 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.
- alistairSH 3y ago
  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).
  - ath3nd 3y ago
    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).
    - mike_hearn 3y ago
      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.
allsunny 3y ago
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.
- alistairSH 3y ago
  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.
015a 3y ago
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.

naijaboiler 3y ago

What was the product being built.

andruby 3y ago

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)

flappyeagle 3y ago

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.

liquidpele 3y ago
Pffft, they train the juniors? Hahaha, that’s funny.
- solatic 3y ago
  https://careers.microsoft.com/v2/global/en/students https://careers.microsoft.com/v2/global/en/students https://www.google.com/about/careers/applications/students/ https://www.google.com/about/careers/applications/students/
jsdwarf 3y ago
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.
- aleph_minus_one 3y ago
  > 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.

015a 3y ago

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.

ako 3y ago

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.

suction 3y ago
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…
ath3nd 3y ago
> 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.

anon3949494 3y ago

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.

jasondigitized 3y ago

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.

StableAlkyne 3y ago
Could you elaborate on what you mean by that? Is it the standard scope creep / premature generalization pattern, or something else?
- stavros 3y ago
  If I had to guess, it's a lack of adequate market research.
- OnlineGladiator 3y ago
  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.
  - cebert 3y ago
    > 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.

codingdave 3y ago

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

nfm 3y ago

What kinds of products were those teams building?

jsdwarf 3y ago

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.

NearAP 3y ago

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 https://news.ycombinator.com/item?id=25975417

idopmstuff 3y ago
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.

deleted 3y ago

[deleted]

SkyPuncher 3y ago

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

sublinear 3y ago

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.

satvikpendem 3y ago

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.

jjav 3y ago
> 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.

snapetom 3y ago

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.

achow 3y ago

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

featuregag 3y ago

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.

ath3nd 3y ago
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.
- featuregag 3y ago
  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.)

ike2792 3y ago

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.