[nandorsky]

This is a poorly written article that is all over the place. It’s evident the author had a horrible experience with a PM. Their description of a PM is a description of a PM who’s doing their job poorly.

Qualitative research at any company is critical and poor qual research (interviewing the wrong people, asking the wrong types of questions, etc) will yield poor insights as is the case here. Any PM working at a B2B startup not understanding the complexities of how the buyer and users differ and asking questions such as, “Would you use this feature?” is a poor PM.

Don’t let one bad experience ruin your perception of the role.

[polote]

Well I agree that this is poorly written (I wrote it).

The point of the article is not that companies shouldnt have PM, but that you shouldnt make them owner of the innovation in a B2B context. Of course if you start with the assumption of "Good PMs" it will work, but you will rarely find these "good PMs"

[passwordoops]

100% what others are saying. This is a hot take rant with bad arguments based on an experience with a bad product manager (or maybe you're just difficult to work with and your ideas aren't as innovative or as good as you think).

I can easily flip the script and say "Devs at B2B shouldn't be anything more than oompah-loompahs" or "UI designers shouldn't be allowed to give ideas" based on a couple of my own isolated experiences.

You want to be taken seriously? Don't rant and explain what structure/methods would be more appropriate for a B2B business that would balance the need for innovation that makes users happy with keeping the paying gatekeepers willing to keep paying

[llamaLord]

In this whole article the word "problem" is only written once, and it's in the line "the problem with product managers is".

Given you don't understand that the core pillar of the product manager role is to be the owner of the problem space, I'm not sure how qualified you are to comment on how valuable our role is or isn't.

Discovery isn't about decided what does or doesn't get built, it's about discovering what the real problem is that your customers need solved (almost like it's in the name).

If your PM is good at their job, the answer to that question should be pretty clear once they're done. That's not them "telling you what to do", if you want to go build a solution to a problem nobody actually has, you have fun with that.

And if you PM is defining solutions and telling your team how/what to build, that's on you to push back and take ownership of the part of the process that you're meant to be owning.

A lot of PM's end up overreaching because they're just tired of there being a leadership vacuum and nobody willing to fill it. Trust me, we're busy enough, we don't want the extra work.

[thereddaikon]

I've worked with good and bad PMs and this jives with my experience.

[xbar]

> A lot of PM's end up overreaching because they're just tired of there being a leadership vacuum and nobody willing to fill it.

This kind of apologizing for horrific behavior undermines what I thought were otherwise strong points.

[llamaLord]

It's not meant to be apologising, it's meant to provide context so that engineering teams can be more comfortable pushing back and retaking control of the solution space.

Should PM's be better at not steam rolling engineering teams? Yeah, 100%, it's literally the #1 thing that I consciously work on when it comes to personal development and self discipline etc.

But it would also help if engineering teams were more... I want to say "aggressive" when it comes to solving new problems and building new solutions.

I get that "new features" is seen as a PM thing and we always get shit for pushing "new features" over things like fixing tech-debt. But for 95% of products, "new features" are going to be a very consistent reality and often they're responded to extremely negatively by engineering teams, even (and some times especially) when those engineering teams are placed in the drivers seat to come up with the solutions.

[haswell]

What is the horrific behavior, here?

[polote]

Sorry if you took it personally or you think this is a rant. This is clearly not the case, I can repeat it, PM have a lot of value, but there is one specific area that we shouldn't give them control over.

It doesnt mean they are bad PM or good PM, innovation requires just fundamentally opposed skills to the standard product management ones that we see in books.

[llamaLord]

I didn't take anything personally. IMO your implication that I did just feels like another attempt to straw-man PM's.

Trust me, we deal with so much psuedo-emotional garbage every day that stuff like this just slides off our backs.

My point is that you obviously don't actually understand what a PM's job is, so you probably shouldn't be telling everyone what they can and cannot do.

As a PM I've been the one that's lead some of the largest and most successful innovation focused initiatives that the companies I've worked at have ever delivered. In some cased delivering revenue uplifts totaling 20-30% of the companies entire income.

Engineers don't have a monopoly on innovation. Innovation is what happens when a great solution is paired with a nasty problem. For at least one half of that calculus, most companies need good PM's.

[haswell]

> but there is one specific area that we shouldn't give them control over.

This is a bit like encountering an engineer who isn’t very good (or maybe it’s just a lack of experience) and then concluding that the engineering org should not be allowed to control architecture based on that experience.

Or encountering a dev team who goes off and builds some complex feature that no one asked for and then concluding that dev teams should never have a say in what should be built.

The existence of bad PMs or bad devs (or good PMs/devs executing a misguided plan) shouldn’t be used to justify a general sweeping argument about either discipline.

[bigbillheck]

Going by this article and the rest of your writings it's hard for me to think that this 'one specific area that we shouldn't give them control over' isn't really 'whatever area polote happens to be in right now.'

[le-mark]

I don’t get all this criticism. It’s a rant, I personally enjoy a good rant so thanks! Now everyone saying you don’t understand the role? Hogwash, most companies and their management are incompetent and don’t understand the role either, they simply hobble along on their “chaos is a process” BS. I read this as one of those. It happens, a lot.

[Ialdaboth]

Yep. It's no longer a rant when a recognizable pattern emerges.

(and I don't think they are personnally incompetent - quite the contrary; but in my experience, it's the managerial process that is often designed to generate incompetency as a side-product)

[brianwawok]

I think the article had some good points.

I’ve had the same b2b PM woes. I even had my PM tell someone that they (the PM) didn’t really need to know how to use our product, as long as they talked to users and wrote down what they wanted into stories.

I have since taken back more product owner power as founder. Innovation is up again! So I think it’s helping.

[jayparth]

Paul, it’s a bad article. Your arguments don’t make sense and are mostly strawmen. If you want to improve it, show it to someone in real life and have them talk over it with you. You’ll probably get a lot farther than a few sentences of feedback over the internet. But it’s really bad.

[singleshot_]

Imagine feeling qualified to write this article without knowing the difference between a project manager and a product manager. Imposter syndrome indeed. Thinking you are the correct person to evaluate a “PM” without knowing what half the letters mean is pretty amazing, leaving us to wonder what would happen if this person ever were to encounter a program manager.

[llamaLord]

Let's be fair here... I consider myself a pretty proficient Product Manager and even I would struggle to tell you what the Program Manager in our Org is actually meant to do.

Don't get me wrong, they do a lot and it's all valuable. But even they can't tell me what their fundamental role responsibility is hahaha.

[singleshot_]

On the other hand you’re not out there writing slam pieces on project managers, so I don’t think your lack of clarity around these terms is causing anyone any heartburn. And yeah these terms are a little under-differentiated in some shops. How I learned it [0]:

Project manager handles a discrete undertaking with a beginning and an end that falls outside whatever your org considers “ongoing operations.”

Program manager handles a portfolio of interrelated projects. If a lot of projects are failing and you want a single throat to choke, the program manager might be a good person to replace.

Product manager seems like it could be interpreted as kind of like a program manager (for a large, complex set of inter related projects) or a project manager (if there’s only one project) except that the organization’s ongoing operations include the creation and development of the product, instead of the product being a single event/discrete undertaking.

Source: read PMBOK decades ago

[0]: maybe others who learned differently can chime in? Doesn’t seem like this terminology is universal.

[sb8244]

It also matches with my experience fwiw. The biggest issue I saw with qualitative is that it almost always was used to reinforce an existing idea that the PM has. I've never heard a PM say they learned something surprising and are reconsidering their initial idea.

[kareemm]

> I've never heard a PM say they learned something surprising and are reconsidering their initial idea.

You have never worked with a good PM then. I hear unexpected things from customers pretty much every single time I talk to one.

[ttymck]

It's possible I've not worked with a good PM, but the fact remains that I haven't seen the industry _incentivize_ the "good PM" behavior you're describing nor have there been consequences for "bad PMs", so does "good" and "bad" really mean anything?

[kareemm]

There are lots of companies where talking to customers is a requirement for a PM to have continued employment. I’ve worked for more than a few. Seems to me that’s a pretty significant incentive.

[ttymck]

"Talking to customers" is "good PM behavior"? Isn't that like saying "writing code" is "good developer behavior"?

[llamaLord]

Additionally, as a PM, I hear unexpected things from my engineering teams to and they very often change the course of an initiative we're running.

A PM is an Air Traffic Controller - not a dictator.

[Lalabadie]

Presenting a dichotomy of "Developers aren't social and product managers are" says a lot more between the lines about the author than the actual words advance any argument.

[jbverschoor]

Great headline though

[propogandist]

B2B startups stop innovating the day you give powers to developers (video)

https://twitter.com/alain/status/1625297691617169408

[haswell]

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

- [0] https://xyproblem.info/

[llamaLord]

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.