This piece would be better titled "Startups stop innovating when they have poor leadership", and reveals a fundamental misunderstanding of the PM role and the nature of the problems the author is witnessing.
One of the most important aspects of the PM's role is not to take a list of feature requests, and not to give customers what they directly want/ask for, but to understand their problem space deeply, and to use that understanding to guide the dev team to the right solution. This still leaves power in the hands of the dev team to innovate, but ensures that innovation is directionally correct. If you don't have a dedicated PM, someone still needs to do the role, and if the dev team is doing this better than the PM, they needs a new PM - maybe whoever is doing this successfully from the dev team (this was my path into the PM role as a lifelong dev).
Forgetting to focus on the right things quickly leads to an XY Problem [0], and in my experience over the past ~20 years building software, almost every customer falls into this trap, and engineers are just as susceptible to this problem as the person doing the PM role.
I some have empathy for the author as someone who has experienced working with a bad PM, but it would be easy to write a response to this post that mirrors the author's arguments while describing a poorly executing dev team and the resulting outcomes of that.
The failure modes of dev team without product thinking (whether that thinking comes from someone on the team, or from a dedicated PM) are just as severe if not worse as the failure modes of a poorly run PM org. I've seen teams spend 6+ months "innovating", only to find they did not really understand the customer problem, and what they built was never used.
The other thing worth noting here is that "innovation" is not necessarily a good primary measurement when thinking about progress building B2B products - especially enterprise products. Innovation is often directly at odds with the needs of the business buying the tool. They're running a business on this product, and they value stability and "does this thing solve my problem" far more than innovation for innovation's sake. If innovation is required to solve a new problem or to improve the stability of the business, so be it, but running a business is often at odds with dev team's willingness (even desire) to move fast/break things.
My advice to the author would be to spend some time seeking out information about good product managers. Establish a working understanding of what the role looks like when executed well. Engineering can often guide the direction of a PM org, and identifying poorly performing PMs is as important as identifying poorly performing engineers. But starting from the position presented in this article is just a complete non-starter for any such progress. It shuts down the conversation before it even starts, because it demonstrates a painfully glaring lack of understanding of what the problem really is.
And this doesn't even begin to touch on the myriad of factors that play into product decisions once the company starts to grow. Factors that no engineering team wants to deal with - pricing, packaging, putting XYZ on hold for a release to focus on ABC because there's a product-wide priority, etc.
(Disclaimer: I switched from dev to PM late in my career because the team needed a technical PM, but the majority of my professional experience is working as a dev).
This guy gets it. Thank you for taking the time to write this up properly, the failure of OP to understand the PM roles relationship with the concept of a "problem space" is a fundamental misunderstanding of the role that never seems to go away.
One of the most important aspects of the PM's role is not to take a list of feature requests, and not to give customers what they directly want/ask for, but to understand their problem space deeply, and to use that understanding to guide the dev team to the right solution. This still leaves power in the hands of the dev team to innovate, but ensures that innovation is directionally correct. If you don't have a dedicated PM, someone still needs to do the role, and if the dev team is doing this better than the PM, they needs a new PM - maybe whoever is doing this successfully from the dev team (this was my path into the PM role as a lifelong dev).
Forgetting to focus on the right things quickly leads to an XY Problem [0], and in my experience over the past ~20 years building software, almost every customer falls into this trap, and engineers are just as susceptible to this problem as the person doing the PM role.
I some have empathy for the author as someone who has experienced working with a bad PM, but it would be easy to write a response to this post that mirrors the author's arguments while describing a poorly executing dev team and the resulting outcomes of that.
The failure modes of dev team without product thinking (whether that thinking comes from someone on the team, or from a dedicated PM) are just as severe if not worse as the failure modes of a poorly run PM org. I've seen teams spend 6+ months "innovating", only to find they did not really understand the customer problem, and what they built was never used.
The other thing worth noting here is that "innovation" is not necessarily a good primary measurement when thinking about progress building B2B products - especially enterprise products. Innovation is often directly at odds with the needs of the business buying the tool. They're running a business on this product, and they value stability and "does this thing solve my problem" far more than innovation for innovation's sake. If innovation is required to solve a new problem or to improve the stability of the business, so be it, but running a business is often at odds with dev team's willingness (even desire) to move fast/break things.
My advice to the author would be to spend some time seeking out information about good product managers. Establish a working understanding of what the role looks like when executed well. Engineering can often guide the direction of a PM org, and identifying poorly performing PMs is as important as identifying poorly performing engineers. But starting from the position presented in this article is just a complete non-starter for any such progress. It shuts down the conversation before it even starts, because it demonstrates a painfully glaring lack of understanding of what the problem really is.
And this doesn't even begin to touch on the myriad of factors that play into product decisions once the company starts to grow. Factors that no engineering team wants to deal with - pricing, packaging, putting XYZ on hold for a release to focus on ABC because there's a product-wide priority, etc.
(Disclaimer: I switched from dev to PM late in my career because the team needed a technical PM, but the majority of my professional experience is working as a dev).
- [0] https://xyproblem.info/