Hacker News new | ask | show | jobs
by cnorgate 4399 days ago
Call it whatever job title you want, there inevitably needs to be someone steering the boat. You can get rid of 'PMs' but you can't get rid of the need to set strategy / vision, understand the customer problem, identify solutions, collaborate with design and corral the rest of the organization (marketing, sales, support, operations) to bring it all together. If you don't have a PM performing those functions, then a member of the engineering team needs to step up, or perhaps someone from the executive team. But then guess what... that person is doing the things that PMs do, so I guess you might start calling them a PM...? Or a 'Product Editor'... or 'Program Manager'. All just names for something pretty similar.

When organizations are small enough, the whole team performs those functions together. As you grow it makes sense to have someone double down and own those responsibilities. Though this doesn't absolve engineers of the need to understand customers and help paint the product vision.

Perhaps the better question is 'Where did all the non-technical-purely-business-MBA PMs go?'

The answer is that it is likely a disappearing breed. An MBA won't teach you how to build great software or lead technology teams, so it's foolish to believe that someone with such credentials would be a natural fit to come lead a software organization. Good PMs I've worked with can have a conversation about the technology stack as easily as they can debate a marketing strategy. Great PMs these days need to span the entire 'company stack' if that makes sense.

Lastly, if you don't know why a given role exists, then it's probably because you haven't worked with someone great in that role. There are a number of roles in tech companies I found less useful until I met someone who had mastered the craft - when I saw them in action, it became clear why the role existed and how they could perform a certain function infinitely better than I.

As a last thought, I worked at Intuit a while back and I'm not sure they are a 'shining star' of PM training. They have done a good job of 'marketing' themselves that way, and they are an example of a company that typically has 'less technical' PMs in their organization. This is because Intuit is more of a 'marketing / business' driven organization. This contrasts with Google who is known to favor promoting engineers into the PM role. Neither model is 100% - the ideal is probably somewhere in between.

1 comments

So, within an SCRUM/agile process, where do you see the PM role? The scrum master? The product owner?
I worked at a place where agile failed because (1) the "Product Manager" was AWOL (he punched a timecard but never seemed to put stories in) and (2) the lead developer refused to put in estimate for everything. (As the one developer who actually put in estimates, I just got abuse because my estimates were "too long")
Sounds like a nightmare! Nothing worse than an environment where you get blamed for estimating something.

I too have worked in places that called themselves Agile but where everything but.

On the other hand I also was part of a well adjusted SCRUM team where the roles were fulfilled properly and we rolled through the project like a steam train. The key was to have a really well filled backlog and then wear most of the pain during the sprint estimation meetings, and the whole team sat in on that. This made everybody understand all the features and their potential complexity before the sprint even started, and gave full visibility of the cost of each of these to the product owner, who could de-prioritise something or swap it out in that very session. The actual sprints then were really straight forward and I really enjoyed myself there.

Prior to that I had plenty of contracts where I get "specs" from PMs, but then have to question each aspect of those, often resulting in me having to ask the product owner myself to decipher what it meant. Inevitably, nobody ever had time and I spent 50% of my day waiting for people getting back to me or work on whatever I could come up with.

At the very least they are the product owner, and if needed can step into a scrum master role depending on resources / constraints.