5 ms·

In that scenario, who is driving product requirements? For example, in an area with strict financial/regulatory compliance laws, are you expecting every engine

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.
        growse 3y ago
        > I care only about one thing: solving the problem! Who prioritises the problems?
        ath3nd 3y ago
        The developer teams, of course. They are solving the problems, so why should they not prioritize them? They just need to have other parts of the org heard, but if you are solving it, you get to choose how to do it, in what order and with what priority. If that's not to somebody's liking, they are welcome to prioritize and solve the problems themselves.
- 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.

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.
      - growse 3y ago
        > I care only about one thing: solving the problem! Who prioritises the problems?
        ath3nd 3y ago
        The developer teams, of course. They are solving the problems, so why should they not prioritize them? They just need to have other parts of the org heard, but if you are solving it, you get to choose how to do it, in what order and with what priority. If that's not to somebody's liking, they are welcome to prioritize and solve the problems themselves.
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.