Product Management is broken, a change is coming

It started as a promising concept:

The Product Manager and the Engineering Manager team up. The Product Manager decides WHAT should be made, understanding the customers’ needs and talking to stakeholders. The engineers plan HOW to build these ideas, and then code without distractions from customers.

THIS JUST DOESN’T WORK!

For 2 reasons:

1. PMs don’t make the right decisions

Most people cannot be good PMs of a new industry/product/domain immediately.

How do PMs decide what to do? They don’t know what it takes to build the product, and they don’t know the industry!

• You’ve been a PM in a fintech startup for 2 years, can you make the right decisions in a HealthTech one?

• You’ve been a PM in a large B2B company and you moved to a small B2C startup, does the knowledge transfer?

• You’ve been a PM of a mobile app with 50 users, and now you moved to a website of 100,000 daily users, do you know how to prioritize the technical part?

With an average turnover rate for Product Managers of 6-24 months, it’s not surprising they can’t take the time to dive in and learn everything about the industry/product/technology.

Since Covid, we have seen ‘Zoom-based Product Management’. PMs who have never met customers in person, or seen firsthand how the product is used (and no, a logrocket recording doesn’t count).

Before I go on, I want to make it clear - I’m not blaming the PMs here. It’s a very tough job, and impossible to clearly define. PMs around the world feel the problem too: “After 6 years of PM-ing, I have a strange feeling that product management is a fake profession”.

“Senior product manager is the #1 job that people are trying to get out of (66% of PMs surveyed)”.

(From

Aakash Gupta

‘S very interesting article about the future of the profession in Product Growth)

2. Engineers are not involved in the decisions

Engineers build something without ever talking to the customer, and with no direct input from their side.

I’ve been in my company for 3 years, and I’ve NEVER been in a meeting with a customer.

In the worst-case scenario, it looks like this:

• A customer talks with the CS (Customer Success) representative, telling them

  feature X is critical for them.

• The CS describes this to the PM, who decides it’s important enough to develop.

• The PM sits with the designer, and explains how they should develop a feature the CS said the customer needs.

• The engineers receive a design, that the designer thinks solves a problem that the PM said that the CS said that the customer has… 🤮

In a (just a bit) better-case scenario, the PM and designer jump on a 60-minute meeting directly with the customer, get a sense of what they need to do, and go straight to designing.

It might have been a GREAT 60-minute meeting with the client. The PM will spend a week writing a detailed PRD (Product Requirements Document), and the designer will spend a week on the design.

Then the development team will work on it for a month, without ever talking to the customer.

Isn’t it crazy? Shouldn’t it be the other way around? Most of the time spent on actually understanding what are we trying to solve?

Even if that single customer would be happy, what business metric did we improve?

Sidenote: Yes, I know about KPIs and OKRs. They are usually (based on my own experience and conversations with friends in other startups) bullshit. “We want to improve user retention after 1 month by 5%, so we will add this super useful feature to our homepage”.

When it didn’t have the effect expected, everyone just moves on to the next feature. “It’s not hard science, we need to experiment! We are AGILE!”.

Asking the customers what they want just doesn’t work. And listening to people who shout the loudest doesn’t work either.

I want to thank

Leonardo Creed

for his help in writing this article 🙏 I highly recommend subscribing to

Engineer’s Codex

, tons of useful information there!

So how to fix it?

2 things need to happen in parallel:

PMs will get closer to the business side

1. The PMs will SPECIALIZE in the industry and product type. PM roles will have higher standards and fewer job switches.

   Aatir Abdul Rauf
   has an interesting take on it:

There's a growing trend of specialization in Product Management. The advice I’ve been contemplating on is “1 Major, 2 Minors”:

1. Major in product management.
Product Management is no joke and it takes time to master. Ensure you develop strong foundations in discovery, strategy, roadmaps, prioritization, stakeholder management, and product analytics. Without that, you’ll struggle no matter what the domain.

2. Minor in a product type.
Pick up a product type like B2B and get depth in how the buying cycle works and the considerations PMs have to make in it.

3. Minor in an industry.
Take time to build depth in domain knowledge and get into the weeds of it.

This might seem like an awful lot but a solid 2-3 year stint at a growing company can enable you to achieve this.

2. The PMs will take OWNERSHIP of their business domain. Here is an interesting approach to it by Tyler Hogge, back when he was VP Product.

• The bedrock the philosophy is that PMs are the GMs of their product. “The main goal for a product manager is not simply to ship software — it’s to deliver business outcomes.

• PMs own actual revenue number for products — sometimes jointly with the revenue team — which means revenue and product teams are much more tightly aligned. They have a variable compensation incentive tied to business outcomes (e.g. sales, revenue, ramp rate, contribution margin, CAC).

• PMs sell — they join sales calls, give demos, and often travel to onsite client visits.

Delivering on milestones should be table stakes for PMs at any company. The real question PMs should be focused on is: Does this software create the outcomes you wanted for the business while also delighting customers?

Engineers will be more involved

30 seconds that summarize this topic, from 0:10 to 0:40:

To paraphrase it a bit:

“Why can’t the customers just talk to the software people?”

“I’ll tell you why.. because engineers are not good at dealing with customers!”

That might have been true in the 80s, when engineers were mostly hard-core geeks. It’s definitely not true anymore.

Engineers caring only about tech debt is a myth. If you push them with unreasonable deadlines and they create unmaintainable software of course there will be pushback.

The 2 best PMs I’ve worked with (out of 6), were both ex-senior engineers. Technical background might not be a must, but it gave them a big advantage. They could tell on the spot which solution is viable and what are the downsides (without needing to ‘take it with the team’).

The shift is already happening:

Software companies are changing. Where once product managers and software engineers dominated, now a new role is emerging: the product engineer.

Leonardo Creed

covered it in depth in his article:

Most engineers in companies are silo’d away from users and interface with product managers instead. This is usually done because having clear “roles” allows for higher focus.

On the other hand, product engineers get to wear many hats, doing engineering, product, and UX work. The interface of a product manager is removed.

Instead, a product manager goes deeper into aspects of the product when necessary, supplementing surface-level insights and taking over investigations that product engineers don’t have the bandwidth for.

PMs will dive deeper into solving customer problems, gaining valuable knowledge and specializing more narrowly. Engineers will have more space in the conversation, being involved in the earlier ideation/discovery phases.

So what should I do?

If you are a development team leader like me, there are a few things you can do:

1. Challenge your PM, don’t take any feature for granted.

2. Be more involved - learn about the industry, ask questions, try to get access to clients (or watch recordings of meetings if you can’t). Here are some unique ideas for how to become business-oriented.

3. Help your engineers be involved - invite them to meetings, ask for their opinion on the PRDs.

4. Learn more about Product Management. I highly recommend 3 newsletters:

   1. Kyle Poyar’s Growth Unhinged
      by
      Kyle Poyar

   2. Untrapping Product Teams
      by
      David Pereira

   3. Product Growth
      by
      Aakash Gupta