[baxtr]

That reminds me of the time I was heading the Product Management department of a large company. We had so many discussion about what a Product Owner, Manager, Technical Product Manager is. Their role. Their responsibilities. Endless discussion with much feelings involved about respect, ownership and so on. Nowadays I am convinced that a great company just doesn't need any PMs. It is way better to empower the tech and UX people. They have to have the ownership, the product role should be filled by one the people building things. There is no need for another role in my opinion and creates more discussions than necessary. It also reduces the ownership of other roles. My 2c at least.

[grandvoye]

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)

[gen220]

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.

[grandvoye]

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.

[gen220]

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!

[staysaasy]

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.

[theschwa]

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.

[rakamotog]

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.

[DamilolaA]

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.

[staysaasy]

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.

[SimonPStevens]

This is a good comment, but It's easy to generalise one specific experience that works successful and mistakenly think it applies universally.

You may be right within your company, but I can offer an alternative anecdote.

I work at a company that makes energy trading risk management software. It's complicated and niche, and the customers are varied and have very different mindset to develops and testers. We have traders, hedge funds, energy generators and retail suppliers all with different use cases.

We absolutely need a product manager who has the time to dedicate to understanding the customers needs, understanding the changing landscape of the market and understanding the competition. This is not something we can just expect a developer or tech lead to do through ownership.

I'm certain your way works for many though.

[paxys]

That is never, ever going to work. I do think some companies have too many PMs, but eventually there needs to be someone driving actual product development and making business & customer focused decisions, if not for an individual team then at least at one level above. If an engineer or designer is doing that then you are just wasting their skills.

[saberdancer]

I agree completely. I was a lead engineer on a product in a situation where we did not have a real product owner or a project manager. While I could manage the team and organize work, I struggled massively to come up with well defined and focused features for us to work.

I would spend lot of time talking with different customers and trying to move that into development, but I was losing so much time I could have spent solving serious technical problems.

Having a good product owner that sees the big picture and can write down a rough specification of features would have helped massively and allowed me to do what I do best.

On other hand, I was also in a situation where product owner depended on me to do his work. That is even worse.

[ghaff]

I was a PM in a long ago prior life and, at one point, we decided to bring development managers into more customer meetings. It wasn't a bad idea but they had their "day jobs" so would end up being only in a few meetings. So it ended up as almost mirroring sales where the last customer they spoke with was taken as gospel and a blueprint for what we ought to be doing.

To one of the broader points, in both my personal experience and what I see software PMs doing in my current non-PM role, they spend a lot of time talking to customers.

[ch4s3]

I worked in a role in healthcare for a few years where I was the lead engineer and sat in on most customer meetings, and even did some field observations. It was an invaluable experience. It was super useful for disabusing me of certain notions I had about which features mattered. I learned a lot about product work from the experience and started asking myself and the team different questions during the development process.

I got to see a broad swath of users with pretty different needs, and learned a lot about how their clinics worked. It was really good for thinking concretely about tradeoffs.

[putlake]

Perhaps it works at your organization. I've been a PM where engineers and UX had no sense of ownership nor business sense. A PM's role is to understand what is important, how to prioritize, how to validate ideas fast, and how to avoid the tail wagging the dog (the tail could be UX, tech or your VP). If you have engineers and UX folks who can do this, more power to you!

[ryanbrunner]

This is a bit of a devil's advocate argument, but perhaps the reason engineering and UX didn't feel ownership was because you were the PM. Not you specifically of course, but if the role of PM exists, and the culture is such that the "business" outside of eng / design treats the PM as the owner, it's natural that the engineers and design folks won't feel empowered to take ownership themselves.

[latch]

If the product is something engineers and UX use, then they'll probably _want_ to be a PM. If it's something they don't, you might need a PM.

Having worked in both situations, many times, I'm pretty sure this is the most underrated factor in success. Companies where the staff doesn't use the product are facing a huge uphill battle. Oftentimes, this is inevitable and I think the only solution is a huge salary premium - but more often than not, these are the companies on the lowest end of the pay spectrum (double whammy spells near certain failure).

[steve_gh]

> how to avoid the tail wagging the dog

Hahaha.

I once worked at a major telecoms equipment manufacturer. Our competition analysis group had two functions. One was to work out what our competitors were doing. But the really good people were tasked to find out what our engineering group was up to. Basically, they were powerful enough to do whatever they wanted, and screw the product managers and technical marketing folks who actually spoke to customers.

This company is basically no longer in existance.

[skohan]

I can't imagine how that would work at my current company. It's an IoT startup, and the hardware, firmware, software, and operations timelines all have to be coordinated to deliver on a tight release timeline. I can't imagine developers also having to take on the requirement and dependency management on top of building the actual product.

I've also worked at places where the P*M level seemed to mostly get in the way and just serve as a middle-man and information degradation layer between design and engineering.

[calciphus]

That sounds like you had several people to do one person's job, not like it's a job that doesn't need to be done.

Solid UX people think like product people, but you either over-burden them, have them shift part of their roles off to others (research, user testing, etc),or do both jobs poorly. Good product people not also doing design, research, technical work, etc...they should be able to manage several teams / projects in a related area at once.

[ntsplnkv2]

Yep.

This all sounds nice, but developers/designers rarely want to do PM work. The PM position is as much a creation of developers who don't want to interact as it is management.

Even developers that do don't want to spend all day in meetings. A PM can help there.

[ryandrake]

I don't know--I think there are plenty of developers who would love to have more of a say in what they're building, rather than toiling away building someone else's pet feature that they (the developer) know is going to fail.

[ntsplnkv2]

A lot of developers think that way, just like everyone else in their jobs, thinking they could do it better.

When they realize it's more soft skill oriented, endless meetings, power point deck after power point deck, stakeholder after stakeholder, and 1 hour left to code, they finally get the picture.

I was once that developer, thinking I knew what was best for everything. I scoffed at management and project managers. Now I know the real truth - their job is way harder than it seems.

[k__]

I think, you're right.

I'd even go as far as saying management roles aren't needed at all below the C-level.

The problem is that many companies already moved their engineers and designers away from the customer, and I think this model only works with small autonomous teams that talk direktly with customers.

Most engineers don't even want to talk with customers, they just want to solve what they think is the most important technical problem and be done with it.

[baxtr]

Exactly. That mirrors my experience. Devs start saying things like “go ask the PM, I just care about code quality”

[lazide]

There is the 'only so much time in the day' issue too. If you have millions (or even 1000's if they are high touch) of customers, you'll never be able to code if you're spending your time talking to them - and it will probably be required to develop specialized skills in talking to them too.

At some point, specialization has to happen. It also has drawbacks. Small teams are often dramatically more effective than large teams for similar reasons (ownership of the problem, less communication/education overhead), but they can only scale so far.

[brightball]

I tend to agree with you, but the hardest part is when it comes to making coherent decisions about priorities and direction. You've got to have an agreed upon way to set those priorities, otherwise it will just end up going to whoever the loudest person in the room tends to be.

I'm a big fan of the idea behind the Weighted-Shortest Job First approach but the trick is balancing the time investment to do it to the size of the decisions that warrant it.

[polote]

> It is way better to empower the tech and UX people

And who empowers them if not the PM ? I mean in theory you could say that to get a product, you only need a designer and a developer. But you know the reality is different. This is not a hazard that most successful tech companies have PM (except Apple)

[baxtr]

Thanks for the comment! I know that I am putting something out here, which is definitely controversial. I was a PM myself for a long time...

To your question: I think it is the role of management to empower the devs and UX people. To your point about Apple: Isn't it amazing that one of the or even the most successful company on this planet doesn't have any PMs?

[polote]

One role of the PM is to close gaps between departments and make people work together toward the same goal. It is very hard for a manager to do the same thing. For a PM it is easier because he is not the boss of anyone and don't try to gain power over other's stuff. On the other side if a manager is trying to do the same thing, you will have other managers try to protect their department.

As for Apple, yeah they are one of the most successful of the planet, but the feedback I have, is that developers would love to have PM to work with.

The issue is not to have PM or not. Anyone company in the world understand the benefit of having a good PM. But a lot of PMs are shit and just make things worse.

[ryandrake]

It's a little more nuanced. Apple doesn't just throw away the PMs and tell eng leaders "You just have to do that work". Their culture has baked in the whole "DRI" concept where a single individual is directly responsible for all aspects of the product, and has corresponding decision-making responsibility and accountability for its success or failure. In typical companies, when eng and PM disagree, the decision is often escalated up the management chain, to someone even less involved and clued in. With the "DRI" model, any conflict between eng and product needs is purely in the mind of one person, and gets resolved right there.

The tough part about doing this is when you hire engineers, you need to also interview for good product sense and have more emphasis on soft skills. Not easy to find.

[ako]

Huh? If you go to the apple jobs page and search for "product manager" it comes back with 600+ results in the US: https://jobs.apple.com/en-us/search?search=product%20manager...

An example, Apple Pay Product Manager: https://jobs.apple.com/en-us/details/200185069/apple-pay-pro...

[mmcnl]

The problem is that PM responsibilities require a vastly different skillset than engineers usually need. I completely agree with you, but these people are extremely rare. Also, technically this doesn't eliminate the role but it does eliminate the position.

[ako]

There's tons of stuff i do as a product manager that neither tech nor ux will do:

* Finding new customer needs that are not yet covered by the product (new products, so not existing product),

* determining how a product might address that need,

* determining the alternatives, competing products, customers may choose,

* the (financial) risk of not addressing the need,

* the business case of creating a new team to implement this need product/capability,

* the pricing of said new product,

* determining what the key product features of the competition are that we need to address to be able to win deals when in competition,

* and what features are relevant according to gartner, to ensure we're part of the short-list of potential customers

* determine how to prioritize product releases and features to ensure we can win markets (think crossing the chasm).

* ...

[tootie]

I hate to say it, but "empowering tech" is usually an anti-pattern. Technical work is done in service to business needs. The role of Product is to bridge that gap. Both pushing the tech team to focus on the most valuable work and explaining outwardly why a tech team might need to focus on quality or refactors instead of delivering features. It could be the same person the same way someone can be a doctor and a pilot, you'd just have a very hard time finding enough people who can do it all.

[gowld]

How do 100 empowered tech and UX people build a coherent product?

Why do movies need a director? Screenwriters and actors and cinematographers and effects teams and all the rest are brilliant at their jobs.

[minitoar]

Totally agree. I feel that product managers are the emperor’s new clothes.