Why Product Management doesn't work.

I recently read Pawel Huryn's breakdown of Marty Cagans 20 product model first principles. They are well structured; they work beautifully in product organizations. They make a lot of sense. You find them in big tech companies and tech scaleups. You don't find them in many other places. That's because, in most companies, product management is non-existent.

I respect Pawel's breakdowns and Marty's leadership, but the advice given by most product management thought leaders is so far off from reality for >90% of people in product roles.

The problem with Product Management Advice.

First off, I worked in product roles for the past 15 years, advising big brands outside of tech for the past 7. These are just based on my observations, so they are biased & I don't have any statistics to prove these statements beyond my own experience.

Feel free to provide counter-arguments, stats, or research to confirm these or disagree with me. But keep in mind that this article is an opinion piece, and I don't claim any thought leadership on any of the topics below. In fact, here are the people I follow and whose books I read and applied in my own work.

Aakash Gupta, with ideas on growth. Pawe? Huryn ????, who is a powerhouse of resources. Leah Tharin, on product lead growth( PLG). Elena Verna, on growth tactics. Jeff Gothelf, with hands-on strategy. Teresa Torres, on discovery. John Cutler, on product strategy. Shreyas Doshi, on general product topics. Ash Maurya, on learning. Maarten Dalmijn ??, on complex topics. Ant Murphy, with practical insights. Marty Cagan, is the GOAT. ? Bü?ra Co?kuner, on no-bs pm. Jason Knight, on pm and agile. Andre Albuquerque, on day-to-day work. Ankit Shukla, allrounder. ???? Chris Stone ????, on anything agile. Stefan Wolpers, on anti-patterns. Maria Chec, with agile tips . Jim Highsmith, a great storyteller . ?? Artur Margonari ??, on hands-on agile. Nisha Joshi, on team agility. Petra Wille, on teamwork. Dr Bart Jaworski, on career tips. Shyvee Shi, curated content. Diego Granados, on product interviews.

Though I love all of the above, there is a big problem with the advice given. It is this: most of it is not applicable in most settings. Here is what most settings look like:

Product in most companies.

In most organizations, there is no dedicated product manager. The role may exist in name only, but usually, you have product owners, solution owners, or some business or function-related title that manages projects.

Cagan and others write about this at length, referring to feature factories and non-dedicated teams. These are seen as dysfunctional or called anti-patterns by different authors. But for companies that did not start out with software and instead added IT over their evolution, the model they create things is what made them successful in the first place.

It's no wonder that a finance company or an automotive company would take the existing structures, processes, and approaches to apply them to the development and management of software products. In some industries - like pharma - you can't develop a product using typical PM advice. You can't simply jump into human trials for customer feedback. Companies in those industries used to do that, and then society put regulations in place for good reason.

Product in most companies is an extension of their thinking. This may seem like a trivial insight, but it's the reason why a product operating model or product organizations do not typically exist outside of tech. Even for physical products.

If you take any traditional automotive company, a car model is stage-gated across the entire value chain, with breaks in ownership, data, decision-making, and processes along the way. This is typical. The result of this is conflicting decisions, like a factory not knowing whether it is supposed to create 300 or 500 of something. The result is also multiple governance forums, distributed ownership, unclear authority, slow decision making and execution.

In these environments, a product is a concept, but it is not a single role or a single team. Products are broken down into sub-components and subproducts, but even those face the same issue. A product is assembled across vendors and teams, or custom built by companies that actually provide service offerings that are described as products, but aren't.

Note that this is 90% of companies out there. In my time working with executives and advising newly minted CDOs, CPOs, and heads of product, there were no product practices in place in almost all of them. It would have meant enterprise-wide transformation. Those are rare, few are successful.

7 Observations

1 - PM advice is not actionable.

If you are in big tech or any scaleup that's built in the past 5-10 years, what Marty and others write makes sense. Read Lenny's Newsletter. Get all the product books you can, you'll improve your work.?

But if you follow this advice in the common settings I described above, one of 4 things will happen to you:

a) You'll accept the status quo and swim along. You'll fight windmills and be frustrated over time, not able to make an impact. You're trying to put principles and tactics in place that will have to work system-wide but only have the remit of changing your team, your department, or the "products" of the company, which aren't defined as such.

b) You'll lose your job because you'll be forced out. Moving into a product operating model needs educating stakeholders and building a base of influence, all the while delivering some impact and quick wins to show. You need to be a mix of political beast, great strategist, and excellent executioner. Very few people are that (I'm not).

c) You'll resign. After implementing some changes, you'll see a lack of leadership support, and too much focus on revenue and cost numbers. The leadership is trying to perform and appease investors and shareholders, but a large upheaval is not something they want to afford. Even transforming a thin slice of the value chain is seen as a risk, so you're left holding your own... principles in hand.

d) You do whatever you can. Most people implement whatever advice they can, and make small changes. This works for some cases and creates momentum, even some small wins. But this type of change is very slow, takes a lot of patience, and you're on thin ice a lot of the time, trying to show why your efforts and your team are relevant. Meanwhile, you get positive feedback from leadership, but they neither kill nor raise your efforts.

2 - PMs are project managers.

90% PMs I met handle multiple products (4 on average). Most do not have authority, autonomy, ownership. They push requests into features, then manage numbers and teams. They aren't spending all of their time on one product.

In many places, the PM role is not even defined. They are called product owners, solution owners, initiative managers, or have a title that is business or function related with project management of the various initiatives.

They manage their projects in excel sheets, spending half their time on calls with the different product roles and vendors, discussing timelines, roadmaps, features, and stakeholder requests that need to be considered. The other half of their time is eaten up with creating presentations and documents for the various decision making boards for the different products. A small amount of time (8-12h if they are lucky) is actually spent on the product vision and the customers.

A terrifyingly high number of PMs do not have any portfolio management practices in place. There are no product vision documents or any form of documentation of product strategy. Knowledge is shared in presentation slides and if the PM drops dead or leaves, the project is in big trouble. The product is often described verbally to other teams and executed with a roadmap that is treated as an execution plan set in stone.

PM training, communities, role definitions, promotion guidelines, and general PM practices do not usually exist. Establishing them at PM level is near impossible since people in these roles do not have the time to focus on one product.

3 - No dedicated Product Teams.?

The engineers and designers working on a product actually handle multiple projects. This is what people call "a feature factory," but the problem isn't that they only work on features. Take any good developer or designer and give them an additional project to work on that is unrelated to the project they already had. This is a surefire way to turn them into average or bad-performing specialists. Simply adding up the overhead of each additional project reduced the time people have to do the actual work.

The result is teams being in firefighting mode, with no team, strategy, or culture principles in place. The work is agile in name only. The people in such a setting are ticket solvers.

That's not being derogatory, it's just the reality of their work. That's why most of them don't care about any one product much.?They are not dedicated to any one product. That's also true for product managers as they juggle multiple projects.

Spreading focus is the easiest way to increase the risk of failure, reduce performance, and slow implementation and decision-making.

These are obvious observations. What's not so obvious is how to get out of them. If you are a PM in such a setting, the reality is that you can't. This needs a redesign of the product portfolio, a re-prioritization, including killing a large number of products, and reorganization and change of processes. Unless you have all the roles involved under your remit—which is never the case in a product role—you won't make the required changes.

So the advice on creating autonomous 2 pizza teams with ownership makes sense, but it isn't possible unless you are creating a new organization with a new team.

4 - No build capabilities.

Most companies outsourced their digital build capabilities for decades, with IT just keeping lights on, and design just making things nice. They then built those capabilities up in the past 2 decades, but mostly through vendor management.

Most engineering and design managers I met are vendor relations managers. They just coordinate the work input and output for outside vendors and contractors. I used to be one of those vendors. That's not a bad thing to fill a gap quickly or get some specific outside insights.?

But PMs who want to experiment with something quickly find that their counterparts are not in a position to do so. Either they've lost their hands-on skills a long time ago, or they do not have the tools, resources, or time to spend on building capabilities.

This is highly problematic, as you have to own any core product or core platform you build. Many financial institutions and medical companies use tools that were built three decades ago by outside vendors. They are either still dependent on them or are struggling to migrate and rearchitect their core to a modern vendor.

Look at any company in tech. Take something like Uber or AirBnB. None of them are using platforms built by outside vendors for the CORE of their business. They own that capability and have built that software themselves. That's their business. You can't use white-labeled systems or depend on agencies. Most "products" that are built are just configurations and dressing of existing software.

This took me a long time to understand. Whenever a PM was talking about a "product," I just saw their engineering lead working with an outside vendor to customize something like ServiceNow and the design lead "creating" the UI by customizing icons and colors.

5 - No focus or long-term thinking at the executive level.?

Leadership is feeling the pressure to play in so many fields. In recent years, AI put pressure on everyone, and before that, it was Covid. There is always something new. The pressure of revenue and cost is high, with leaders expecting immediate returns.

But constantly shifting activities when benefits do not materialize quickly is not pushing anything forward long enough for it to work. When I discuss this with executives, the answer is that the effort has been ongoing for 2+ years. In reality, most of that time was spent on approvals, planning, resourcing, and finding the right approach.

No one (none of the 30+ executives I worked with in 7 years) took a step back, killed 90% of their portfolio, then put resources and focus on only 2-3 things because that's perceived as risky. Instead, people spread their effort to "not put all eggs into one basket."

Look at any successful tech startup, that's what they did. Laser focus is the term.

Just transpose this to your own life. If you have 20+ things you are working on and none of it moves forward, what's the advice your friends will tell you? Do less.

6 - No transformation effort.?

There is a story about a woodcutter and a hiker meeting in the forest. The hiker tells him to sharpen his axe, but he replies that he doesn't have the time. He has to cut wood.

That's the situation in most places. For a while, "digital transformation" became the thing before "transformation fatigue" became the thing. Now it's AI transformation. But in most cases, what is happening is a mix of reorganization, training, and new processes.

There is little work on actually changing the company's underlying model. It takes time to change incentives, governance, authority, and ownership. I haven't seen any case where the actual management and operations model changed.

I have seen cases where the Group CPO of a large automotive brand supported a large transformation initiative that took 6 months to develop, 6 months to align all stakeholders, 6 months to plan and resource the initiative, and 3 months to source vendors. After 2 years of beating the drum, the initiative whittled away when the next market change hit them in the face. The book "transformed" by Cagan is spot on - but transformation cases are very rare.

The instances I have seen work were family-owned or founder-owned businesses, where a single decision-maker makes a radical move to simplify and do systemic changes. I've seen this first hand once with a metal company and once with a heating systems company. And of course, there is the very public case of Steve Jobs coming in and killing 80% of all products, then coming up with only 4 that the company will produce and focus on.

What is the likelihood of your CEO doing this?

7 - No support for change makers.

There are people who try to make an impact within their island inside a large company. I met and advised many of them. Some of them had bigger islands, responsible for hundreds of people. Others only had their small team of 3-5 people.

These are product managers, engineers, designers, data scientists, or business managers with a vision. To some extent, it's a way for them to further their careers and stand out, but to a large extent, it's because they actually care about their customers and team members above the average.

One pattern I have seen, no matter their remit and situation, is a lack of support from leadership. On the surface, the support is there. There is visibility, public announcements, and reassurances. But behind the scenes, they have to fight for and defend their existence every quarter. They are seen as a "cost" and not respected as well as they should be.

I haven't seen any executive stand behind these change-makers to tell reluctant stakeholders to play along or else. Ordering people is frowned upon and not seen as good leadership, though leaders do this all the time in other areas. We tell people to show up for work 5 days a week, to come into the office at a certain time, to use a certain tool, etc. But these are disguised as "governance" and "policies".

Compare this to directives by people like the other Steve. Bezos put an API mandate forward to all teams telling them to make their products available through microservices and API... or else. He didn't care about excuses, technologies, difficulties... it was a clear directive.

So why not support the change with a directive? Try "each of your customer-facing products needs to have a dedicated product team following the introduced best practices... or else". This might mean cutting your portfolio by 80%. But in most places "products are never killed". They just die a slow, gurgling death because change is not made.

Product Management Theatre

Cagan describes efforts and environments where PM lingo is used and practices are spread without changing the underlying principles as "product management theatre".

This is disrespectful and unfair to the people involved in such efforts who are genuinely trying to make an impact. It reminds me of the "agile theatre" and "design thinking theatre" of the past 2 decades.

The majority of leaders that I know do not want to waste resources on something that won't give them a clear benefit. Think of the effort it takes to introduce a new concept with outside practitioners, build up internal resources, and spend time in training, changing metrics, processes, and tooling. Think of the internal buy-in, the pain, and the energy it takes.

No one does that "to play pretend". People do not need big tech brands in their CV. They do not need to publish online or write books. They do not have to be visible outside their company to contribute and make an impact. Most people are not public in their efforts.

For the reasons I explained above, most people are also not in a position to go from being a project manager or some other title in a traditional setting to becoming a product manager in the dogmatic way it is described by some product leaders.

There is no switch to flip to being a PM, to being agile, or to being a design thinker. It's a transition in every case. In Agile, some companies made the necessary changes, others implemented SAFe. In Design Thinking, some companies take customer research and prototyping seriously; for others, it's a checkbox they tick off in their innovation efforts.

These initiatives are often superficial "theatre" in the beginning, then widespread initiatives, and then practices that the company adapts for itself. Sometimes, the adaptation and learning works. In other times, they become formalities and rituals that don't have the effect they should have. But that can be said of any practice, not just product management

How to make Product Management work.

At the product manager level, if you do not have a clearly defined product, no remit to actually do that, and no empowered product team, you can't make it work. You can establish some tactical changes and slowly move your environment in the right direction. But it is a slow and very frustrating process. It is much easier to gain your PM chops elsewhere and apply for companies that have a different environment.

At the portfolio manager level, you can consolidate and reduce the number of products if you are responsible for a portfolio. But in most cases, you are responsible for the individual product performances, not for the performance of an entire portfolio. If it was the latter, it should not matter to stakeholders how that portfolio is composed as long as it keeps growing in revenue. If that is not the case, you can only effect changes a team level and make tweaks, but never actually have empowered teams or a product organisation.

At a head of product / director level, you might be able to put portfolios together and work with other parts of the organization to make organizational and systemic changes. That depends on how product performance is owned. If your organization is distributed with countries or verticals making decisions, good luck. You aren't really the one making product decisions in this case. You can try building bridges to those owners, but they will pressure you on revenue and see every product - no matter its maturity stage - as something that should be profitable and take the profits away from the product. Good luck growing that way.

As for CPO / SVP, you can actually shape the product organisation and put the right practices and behaviours in place. Provided that the CTO and CDO play along or that they are reporting to you. In most places, that's not the case. I've seen CPO reporting to CMO or being "change makers" and owning product in name only.

There are reasons why some leaders (eg AirBnB) are moving away from product management and PMs in general to take alternative approaches. I don't think this is applicable to everyone either. I think this is how to make it product management work:

1. Realize it doesn't work. Just one team, just one training, just one product, and just one initiative are not the activities that will get you there. This needs sustained effort. So realize that you are not there yet. Sure, celebrate the small wins. But ditch the corporate BS talk. There is a reason why your company creates digital products the way it does. Everyone involved is putting in effort, and there are good reasons for feature factories and parallel products to exist. In some areas, they have to exist to create and use synergies. Forcing PM practices down people's throats will not work.
2. Commit to a single change. Do not try to boil the ocean as they say. But if you can take one single product out of everything you do, then encapsulate it from the rest of the organizational madness, then apply the practices, you can create one "lighthouse" example. This is something companies are familiar with. People want to see that it works here. Leaders want to see what the benefits are. They don't want slides and strategy papers by consultants. They don't want inspiring stories from books. Those have their place. But you need to make actual impact in one small space. This is harder than it sounds.
3. Do not scale, learn. Most companies manage 1 and 2. They fail at 3. They jump from lighthouse to scaling it across the entire organisation. Instead of doing that, analyse what was difficult about the change, and how to adapt what you are doing to your company. We all know that copy & paste doesn't work. Yet at the agile wave, everyone put spotify squads in place. At the design thinking wave, everyone wanted to have an in-house IDEO. That's not how this works. These generalist approaches have to be modified for the industry and specific company culture. You can't do that if you go right to scale. You have to figure out adaptation first.

These observations are far from complete. If you'd like to dive into specifics, let me know in the comments. If you think someone else could benefit from reading this, please share.