[hvb2]

Assuming your PM is for product manager not project manager.

I would think the engineers usually get their kick out of making things fast or easy to maintain. If you have a product manager and the customers hate the product, how is that the engineers fault?

I've built a couple useless features that I wouldn't want to use and couldn't explain how to use. But if you have a product person, they get to design is BECAUSE they're in the line of fire.

That's a comfortable position to be in as an engineer, except that you sometimes have to build things more than once.

[zamadatix]

There are two separate problems, and they aren't mutually exclusive, but this post seems to be specifically about the latter case (if one believes the story, of course):

- The PM(s) are bad at listening to customers or turning customer feedback into a focused set of requirements.

- The engineer(s) are bad at following the requirements or going back to the PM(s) when the requirements aren't clear.

In the first the PM(s) can just lack understanding of what the product does or interest in why customers use it, can be overconfident in their ability to "see what the customer actually wants", or just actually want to build something else but are assigned to this product.

In the second, the engineer(s) can just lack understanding of what the product does or interest in why customers use it, can be overconfident in their ability to "see what the customer actually wants", or just actually want to build something else but are assigned to this product.

In either case, it results in the product not fitting the customer needs. I think there are better ways to solve either gap than just having the engineers join sales calls to hope it works out, but I suppose any approach is better than letting the problem sit.

[pyman]

Lots of product managers have never studied product development. You'll find philosophers, designers, physicists, even musicians in the role. Many have great people skills, but little understanding of customer service, building products, or scaling a business. And funnily enough, those are all real careers and degrees.

The result, which you often see in companies with 300+ employees, is that engineers have far more experience building products than their PMs, what engineers usually lack is knowledge of the customer and their pain points, and a roadmap that leads to successful outcomes. In other words: a real product manager.

It's not enough for PMs to throw around cliches like "I represent the customer" or "the product has to be built around customer needs" if they don't understand how to actually build and ship software.

Last year I dug into this and found it's not unusual. Many software companies hire smart people as CPO, Product Director, or Head of Product because they have leadership skills, people skills, and some knowledge of the industry. But most have little to no background in business, marketing, economics, or product development. Some companies go even further and promote an engineer with project management experience to Head of Product. And, of course, people in those roles tend to hire others who look like them, with similar experience. One day their CEO realiseS their product isn't selling, customers aren't happy, or engineers are left to figure out what to build.

To put it in perspective, imagine a company making a lawyer their Engineering Manager and asking them to build an engineering team. What are the chances they'd do better than a computer scientist or an actual engineer? Pretty slim. Sure, there are exceptions, but what usually happens is their engineers aren't motivated and complain about the lack of coaching, vision, purpose, and the poor quality of their tools, processes, code, and work environment.

Bottom line: companies need to audit product leadership roles as a priority and figure out who's really in charge of the product. Run an internal survey to check whether your CPO, Director, Head of Product, and Product Managers have studied business or have actual expertise in it. If not, you're in trouble.

[ivan_gammel]

I support every single word of this comment. Good product managers are unicorn masters of discovery and delivery who are so rare that they climb up quickly in corporate hierarchy to strategic positions leaving holes in product operations. I have seen products running A/B tests without understanding how they work, designing UI sketches without any knowledge of UX, pushing features to roadmap based on a feedback of a single user etc. Maybe it makes more sense to abandon this role instead of fixing it and split the required skills between UX designers, business analysts, marketers, engineering and project managers etc.

[pyman]

I think the role of Product Manager should be renamed Customer Manager to avoid confusion and conflicts of interest. Some companies like Airbnb tried switching to Program Manager, but that only adds to the confusion.

Right now, the Product Manager is seen as the CEO's delegate, making sure the product follows business strategy, while the Engineering Manager is the CTO's delegate, making sure the product follows technical strategy. One represents business the other represents technology. But IMO since both are building the product together, the title Product Manager creates competition instead of collaboration.

The software needs the customer just as much as the customer needs the software. That's why I think the roles of Engineering Manager and Customer Manager make more sense, working together to build the best product possible. The product isn't managed by one side, it's managed by both.

However, the real problem isn't the role title, it's the qualifications of the person in the role. Companies don't hire lawyers as Engineering Managers, so why do they hire musicians as Product Managers?

[ivan_gammel]

>Business strategy

>Customer Manager

That sounds weird. Product managers do not represent customers interests, they represent business value which is not always in making all customers happy. E.g. conversion optimization brings no added value to customers, so it’s not a great name choice. If the role defined as it us now, „product manager“ is the most appropriate name.

[pyman]

It does sound a bit weird, I have to admit. Customer Experience Manager sounds better or just CX Manager.

For me, the title Product Manager sets the wrong expectation, it makes it sound like they own the product, which clashes with other roles. In reality, they don't own the product, they own alignment: customer needs, business goals, and engineering feasibility.

I've heard many YC founders say that the CEO (or CPO) is the only one who truly owns the product, and I agree. The PM should never own it, they are interpreters who take the CEO's vision, combine it with customer insight, and help the team make the right trade-offs.

[jbmsf]

I have worked with so so many ineffective product managers. The good ones are indeed unicorns.

Even when you have good ones, they can't scale up to all of the things that I'd want them to own, meaning that engineering fills a lot of gaps.

This ends up being uncomfortable and necessary. I'm still learning how to make it work.

[pyman]

The best PMs are like mini-CEOs, and many of them go on to become CPOs. But there's a lot of confusion in the software industry about what the role of a PM should be. For example, I see companies putting too much emphasis on usage metrics, while very few focus on the far more important skill of asking the right questions. PMs look at dashboards to make informed decisions, but most of them aren't even asking the right questions. And they don't know if the questions they're asking are the right ones, because they have no real knowledge of product development, just a bit of experience which is limiting. That's what happens when engineers, designers, or musicians end up in PM roles, reacting to data or using it to validate their own or someone else's assumptions.

The real problem, I believe, starts with companies hiring anyone with people skills as a PM. They don't understand their role and responsibilities, it's common to hear PM say "I own the product." But that's not really true. According to successful founders and CEOs, they are the only ones who truly own the product, and that's an important point for leadership to establish. PMs thinking they own the product creates power struggles with leadership, engineering and design, while a title like "Customer Experience Manager" makes it clear the role is about representing the customer's needs, aligning them with the CEO's vision, and making the right trade-offs.

Business people with knowledge and experience always put the customer at the centre and focus on aligning customer value with business value. In other words, if you're the CEO of Uber and your PM isn't driving a taxi once a week, then, IMO, you hired the wrong person.

[timr]

> Last year I dug into this and found it's not unusual. Many software companies hire smart people as CPO, Product Director, or Head of Product because they have leadership skills, people skills, and some knowledge of the industry. But most have little to no background in business, marketing, economics, or product development. Some companies go even further and promote an engineer with project management experience to Head of Product.

I was right with you until the last sentence of this. As an engineer-turned-PM who is still very much technical, I can count on one hand the number of technically competent PMs I've known in my life, and have plenty of fingers left over. Having experience developing products can easily be a liability, because while delivering software is important, you're mostly expected to be an advocate for the business, which means that you live in the world of corporate politics and can't be perceived as too in the tank for the tech staff.

What I see is the exact opposite of what you've described: the PM that gets ahead is invariably someone with a background in business or marketing, and the technical background is deemed almost irrelevant. If you spend too much time focusing on technical issues, someone swoops in with the theater of "data-driven decisions" and "rapid iteration" -- you can justify virtually anything by cherry-picking statistics, and it's always possible to criticize the development speed of a team when you don't involve yourself in the details -- the role quickly becomes about spinning a compelling story to upper management.

Basically, a huge percentage of PMs understand little more than the first few chapters of The Lean Startup.

[Infernal]

I think the comment you're replying to agrees with you - it makes more sense with the last two quoted sentences swapped. I could be wrong but this interpretation seems consistent with the rest of the comment.

"Many software companies hire smart people as CPO, Product Director, or Head of Product because they have leadership skills, people skills, and some knowledge of the industry. Some companies go even further and promote an engineer with project management experience to Head of Product. But most have little to no background in business, marketing, economics, or product development."

[pyman]

I was saying that many companies already make a mistake by putting unqualified people in senior product roles, and some go even further by making the bigger mistake of promoting an engineer with only project management experience straight to Head of Product.

[AznHisoka]

>> Many have great people skills, but little understanding of customer service, building products, or scaling a business. And funnily enough, those are all real careers and degrees.

Where would people skills rank then in your hierarchy for product managers?

[pyman]

People skills matter for product managers, but they come after customer and product experience, business and product strategy, and execution and delivery. Otherwise you just end up with a nice PM who doesn't know how to move the product forward.

[BobbyTables2]

Would also be really nice if companies selected CEOs with a deep understanding of the core business.

[hinkley]

> I would think the engineers usually get their kick out of making things fast or easy to maintain

Is your company hiring? Because I've spent 30 years being this engineer and nearly everyone looks at me like I've got horns growing out of my head.

That's not where most engineers find their job satisfaction, more's the pity. And they think they know better than users. There's a reason UX has been around for at least four decades longer than DX. Developers think both are made up.