Hacker News Reader

Comment by grandvoye | Hacker News Reader

The challenge I've had with that model is that as a company gets more complex, having someone whose sole job is to focus on the business <> technology interface is invaluable as people start to specialize. It's often more valuable to have engineers with (say) 6/10 expertise in the business and 10/10 expertise in their technology domain, working alongside PMs with 10/10 expertise in the business and 6/10 expertise in the technology. It's simply very hard to be 10/10 in both domains.

I agree that PMs are largely overhead in the early days of a company, provided that you have strong product-minded engineers/designers.

(Also just my 2c from heading a PM department / being a former engineer)

View on HN

Not intended as a rhetorical question, can you describe the dynamics of a long-term successful team where the PM had more business expertise than the engineer?

I agree with the division of labor you describe, in principle, but I've never had the opportunity to observe it in practice. Maybe I've only worked at places that are not old + big enough yet.

In the (relatively few!) teams I've known, the PM's business expertise has usually been strictly less than the most experienced engineer on the team, leading to a typically never-ending, and eventually abandoned game of catch-up.

I work in an area like this. I'm in the automotive space where there's just a whole slew of industry knowledge to stay on top of; both business practices that change frequently as well as regulatory information.

It's pretty rare to see engineers that know the industry as well as the PMs, so we focus heavily on having good communication and dedicating time to make sure features are well understood before any work starts. Our structure works well for us, but I can definitely see how it would be advantageous, where possible, to have engineers who knew more about the business.

Hey good q. I work in enterprise SaaS and our team builds a fairly complex product. We have a range of technical and non-technical users within a given account, who use our product in different ways, and we have accounts that range in size from dozens to hundreds of thousands of employees with the differences in terms of usage patterns and needs that you'd expect. We also operate at high scale so our engineers need to know a lot about distributed systems and the integrations that our product has with other vendors/platforms/etc. We aren't unique in any of this from my experience.

(sorry for being somewhat vague but I try to keep this account anonymous!)

It's simply too much for our engineers to spend time deeply understanding every nuance of our business ("how should we make this product tradeoff between the needs of SMBs in Asia vs. the needs of our largest 10 customers across all countries? How will this then impact our pricing strategy?"). But PMs have more context here, because in exchange they don't (for example) know every nuance of how our data pipeline works.

In terms of how we make it work, we 1. try really, really hard to align incentives between Eng/PM so that they win together, 2. make sure that teams work together closely and have time to bond, and 3. write things down in planning docs as much as possible, as that's one of the best ways to reduce conflict and also fully leverage non-overlapping expertise.

"the PM's business expertise has usually been strictly less than the most experienced engineer on the team, leading to a typically never-ending, and eventually abandoned game of catch-up."

That's rough... those don't sound like good PMs to me fwiw.

What I have seen are cases where very senior engineers have a better grasp of the overall product vision than some PMs, due to experience and tenure. But they usually don't have more expertise in all of the business questions simply due to relative lack of time spent in that domain.

***

All of this isn't to say that engineers don't need to know about the business, or that it isn't a huge advantage if they do (it is). Just that there are so many hours in the day and eventually you've gotta get some division of labor.

Thank you for the super detailed response! It's illuminating.

For the product you're describing, it seems the division of labor is a no-brainer and highly-productive.

It seems there is a spectrum of maturity/complexity (correlated with age and scale), and depending on where your product falls along that spectrum, it either makes sense to have a PM "role", or not.

Additionally, it appears that the domain-relevant experience of the PM is a big factor. If a company is hiring to fill an org chart, rather than hiring to fit an expertise gap, it's more likely to end up with PMs in the scenario I describe. I suspect this is also correlated with age and scale.

Finally, I guess there are orgs that expect PMs to be (or become) business domain experts and orgs that expect PMs to be highly-educated secretary-task-masters, and these expectations weight the outcome.

In any case, thank you for sharing your experience, this was a very interesting snippet of insight!

No problem! A colleague and I actually write a lot about these types of topics (link in bio) if you're curious.

A few quick reactions:

"It seems there is a spectrum of maturity/complexity (correlated with age and scale)"

100%, I don't think that early stage companies really need PMs, and IMO PMs at early stages can be actively harmful by causing overhead / trying to make themselves useful and failing. At early stages the founders/engineers/designers/even some sales or support people should fill the necessary parts of product management. Product management at this stage can be more like a set of activities that produces good decisions, rather than a formal department.

(Fwiw the company I work at has many hundreds of employees)

"there are orgs that expect PMs to be (or become) business domain experts and orgs that expect PMs to be highly-educated secretary-task-masters"

Yeah, the latter is kind of terrible I think. If you need secretaries or task masters you should probably hire engineers/designers (and management) that can keep the trains running on time or set up mgmt processes to do so automatically. PMs ideally only get involved in project management because they have the skills and they're incentivized by outcomes to roll their sleeves up when needed, not because it's part of their core job.

Good PMs also don't want to primarily do admin project management work, so (to bring it all back to your first comment) you'll end up with crappy PMs who are strictly less knowledgeable than your engineers.

As a PM who works with multiple scrum teams / products - I agree with this and I understand where OP's message comes from as well. While I work with 4 teams, my involvement in each team is dependent upon the product mindedness of the team. I take care of internal/external enablement, customer documentation, bargaining design bandwidth exclusively for all the cases, for a couple of teams, I call team leads into more than half of my customer conversations, product strategy discussions. I believe the team collectively can decide the best work item for them 80% of times without my inputs. Only when org strategy or market reactions change, we reset.

That being said, product mindedness is hard for engineering teams. 2 of the teams I work with, I am giving them inputs on every single feature they need to build. While I dislike doing this for every feature, its upto how the engineering leader envisions their team to function. For some, unless there are jira tickets, properly prioritized, with designs ready, they dont want to involve engineering teammates.

I agree but I don't think an individual can be 10/10 in both domains like you inferred. I think there will always be the need for a product person outside the engineers and developers.

Maybe I wasn't clear, but I specifically do not think that getting people to be 10/10 in all domains should be the goal – I agree with you. This is why you need PMs IMO.

Thanks for writing this post and generating this discussion.

Reply on news.ycombinator.com