B2B startups stop innovating the day you give power to product managers

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/

I was a PM for 4 years in a startup. I helped the engineers avoid (most) meetings, I was obsessed with our customers and their pain points - and spoke with them frequently; as well hyper-obsessed with the competition and where we could improve. I took suggestions from users about what features to build next, and we built a few, and ignored others. I wouldn't bother my engineers unless management (who had a technical background) OK'd the feature after discussion and debate. I probably spent 2-3x the amount of time with my customers than my engineers. Sometimes as the PM the only interaction with my engineers was to bring them coffee in the morning while they cranked out code.

Seems there aren't many PMs like the role I played in my team. In a B2B or B2C startup, a good PM can provide structure, cover for the engineers, and a consistent look into how the product is being used, why it's used versus your competition, and what features users want going forward. A PM doing the right things is more of a design and customer support hybrid role than anything else.

That said, I don't understand why it's a bad thing to "stop innovating". If you have an innovative product that is clearly a hit with customers or users, you shouldn't aim to continually innovate past that in the short-term. You should be eliminating technical debt and making sure your core product's experience just fucking works 100% of the time. A good PM can help with that too, by putting management's ideas onto the backburner and saying "we have to solidify our product first" instead of jumping from one product to another.

Every company should be customer led. Not in the sense they tell you exactly what to build, but understanding the customers problem and then coming up with solutions. In small companies it is much easier to align everyone with the customer. When we were a small company I would send engineers to sales/industry conferences, and it was great to see their eyes open and suddenly understand all the 'odd' requests coming from sales.

This becomes harder in a large company, so the customer has to be proxied somehow. PMs and sales are the common customer proxy. But, if the engineers are being asked to do something and they don't see the value, that is absolutely a failure of communication from PMs and sales. I've also seen the other side where the engineers fight anything that doesn't fit in their idea of the product, regardless of customer or business demands. Both are frustrating.