> I don't understand, how do you handle prioritization decisions: if you have a 100+ customers that all want something, how do you create understanding of all needs, how do you distill that to an integrated roadmap, and how do you align the roadmap prioritization decisions across 20+ teams?
That does seem to require at least a PHD in prioritization or a totally real role like a Product Manager indeed! A naive approach would be to make a spreadsheet with the names of the clients, their current and potential monetary value, group the issues by the corresponding teams and themes, and let the teams ask additional clarification questions to the clients so they can prioritize. But yes, I can see your point, a PM guy called Josh with an bachelor of arts degree indeed seems more qualified to do it than a bunch of software engineers, and make the better decisions. I dunno what I was thinking.
> How do you organize updating of documentation, training materials, enablement of support
A naive approach would be to have a frequently updated knowledge base. However, I understand that Josh and his arts degree make him the best at producing/updating of documentation, training materials, and enablement of support, so probably...Josh?
> updating of price lists, enablement of sales, presales, and customer success teams?
Sales + developers + finance sitting together? Shared company view of the important client metrics? Nah, Josh will do it.
> How do you manage the input towards analysts like Gartner, that have a big impact on the decision process of your customers?
Marketing departments? But I have the sneaking suspicion Jake (or was it Josh) is a better candidate.
> How do you evaluate the offering of the competition compared to your offering, how do you determine where you should be in 1,3,5 years to have a competing product in the market?
By analyzing competition, thinking forward and having a vision. Are developers supposed to only think on the benefits of mysql vs postgres?
> Most PMs are mostly concerned about what should be built to create a valuable product for customers, that provides healthy stream of revenue for the company. Most developers are concerned about how it should be built. That is a completely different responsibility.
Let me float a crazy idea out there, I hope it doesn't sound too far out, I am just trying to dream out loud. Because I believe that if we dream big, then everything is possible.
Hear me out... How about, maybe having developers concerned BOTH about what should be built and how? I know this is too radical, and we would probably need first to have that notion reconciled with mainstream physics, mathematics, and fluid dynamics, but it's just a crazy thought I've been having.
Just imagine a universe where engineers not only execute instructions from people with suits, but actively decide what to build themselves. Of course, that's science fiction and can't possibly be achieved, but just imagine!
P.S Sorry for the patronizing tone. I just think the industry got it really wrong as a whole, and that we can build far better things and far easier if we treat engineers as adults who know what they are doing. The existence of a PM (or PO) role for me is the opposite of treating devs like adults.
Almost every PM I've worked with had an engineering degree and/or previously worked as an engineer. This "Josh" sounds like a strawman or you've had bad luck with PMs in the past.
It also sounds like you have a PM on your team, but they actually have the title of SWE or Eng. Mgr. They probably spend > 50% of their time on the above listed responsibilities rather than engineering. Hopefully they don't get docked in their performance reviews for essentially performing the duties of a PM rather than those of an engineer.
I am very much for any SWE or Eng. Mgr taking responsibility and spending as much of their time as they see fit on anything they see fit to build a great product. Not only that, but I will encourage them to continue doing so and give them a great review score and potentially a salary bump!
> Performing the duties of a PM rather than those of an engineer.
The duties of an engineer are to know what to build, prioritize it against their other work, and build it, alon with the other engineer in their team. If you consider the "knowing what to build/prioritize" as PM work, so be it. I consider it engineering work.
> By analyzing competition, thinking forward and having a vision. Are developers supposed to only think on the benefits of mysql vs postgres?
No but they are vastly different expertises. And in the time that engineers make decisions on databases, architecture etc, the PM can already do discovery work. Surely you can find engineers that also enjoy this, and are good at it, but someone has to wear to do it.
You time and time again portray the PM role as a junior thing. But it is quite hard to keep everyone focussed on “is this really the quickest way we can deliver value”? You don’t need a degree for it, but you need a certain level of confidence and seniority in most teams.
Saying that having a PM is like treating devs as kids is the same as stating that having a marketing department is the opposite of treating sales like adults. Shouldn’t they be allowed to find their own leads?
PM is not a junior type of job for someone called josh. In my experience it’s a full time job, requiring experience in the customer problem domain, and engineering experience.
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.