Marty Cagan on TRANSFORMED: Moving to the Product Operating Model
How to Transition from Waterfall, Outputs, and Un-empowered Teams to the Product Operating Model with Marty Cagan + Your Guide to Transformation.
When Brian Chesky said, “I’ve eliminated the traditional product management function,” a room full of designers cheered.
Thanks to his follow-up statements, we know he didn’t exactly eliminate PM. He changed the role to include PMM, and he is taking a much more active role himself.
But why did designers cheer when they thought he did?
Many of them interact with PMs on feature or delivery teams.
Aakash and I learned that, and more, in an hour-long conversation with Marty Cagan:
🎞️ Watch on YouTube
🎧 Listen on Apple Podcast
🎧 Listen on Spotify
In this conversation, Marty Cagan:
Discusses common misconceptions about product management
Introduces the concept of the Product Operating Model
Explains the critical principles of the Product Model
Addresses common frictions in product teams
Provides insights on how leaders and individuals can drive transformation
I really hope you enjoy it. And be sure to pre-order TRANSFORMED: Moving to the Product Operating Model
Why Transformed?
Marty Cagan has worked in product since the 80’s.
Over his 4+ decades in product, he has been passionate about studying how the best product organizations work.
Apple, Netflix, Google, Amazon, Spotify—you name it, he’s studied them.
Over the course of his studies, he discovered that while each of these companies has its own unique product culture, they all share the same fundamental principles.
Marty's first book, INSPIRED, explained those principles, along with tools for product teams.
His next book, EMPOWERED, went further on those principles, and was aimed at product leaders.
His new book, TRANSFORMED: Moving to the Product Operating Model, answers: how do you actually transition to the product operating model?
It guides you in assessing your current situation, understanding where you want to be, and planning a path to transformation.
Supplemental Thoughts to Transformation
In the spirit of supporting Marty’s guide, the inimitable
of Product Growth and I will also share our take on transformation.We have both been long-time followers of his work and have developed our own takes.
These are our opinions and don’t replace the book!
The Product Operating Model: Why it’s Different
Let’s start with a recap of what’s so different about the Product Model.
Marty has established that there are three things best product organizations do differently:
How you build: This is commonly known as “Agile,” though many of the best companies do not follow the official “Agile frameworks.” Are you releasing at least every 2 weeks (which is nothing to brag about)? You need small, frequent, uncoupled releases with telemetry.
How you solve problems: Product discovery must be performed by empowered product team. They are given a problem to solve and are held accountable for the outcomes, not outputs.
How you decide which problems to solve: Product strategy is singular and comes from leadership. You can’t have a different strategy for every product team.
In our perspective, you can translate this into 3 key elements of the Product Operating Model (this classification doesn’t come from the book):
The principles of the team
What the people on the product team actually do
The role of leadership
Let’s cover each.
Model Element 1 - The principles of the team
Companies like Apple and Google have dramatically different cultures. We all know that.
But the principles they emphasize in product development are relatively the same:
Teams are empowered to come up with the solutions to problems
They are held accountable for outcomes, not outputs
This is a fundamentally different approach from many traditional industries, where the technology organization has been treated like “the IT department.”
In that case, stakeholders fundamentally determine what the teams build. They are not empowered to determine different solutions. So, they are measured on outputs.
It’s much more common to find folks “punch in the clock” in those situations.
Model Element 2 - What the people on the product team actually do
Even though most companies have people with the titles “product manager,” “product designer,” and “engineer,” most companies actually don’t have people performing those roles the same way as the product model prescribes.
The easiest way to see this is the team doesn’t spend a significant amount of time together weekly doing product discovery.
In the best product organizations, the team members work on product discovery together. Designers and engineers (usually the tech lead or Engineering Manager) are actually involved in the process of finding solutions to problems.
Each role focuses on different risk areas:
Product Manager:
Value risk - Do customers want it?
Viability risk - Will it work for the business?
Product Designer:
Usability rick - Can users figure out hot to use it?
Engineers:
Feasibility risk - Can it be done with the current enabling technology?
But, again, it’s essential for them to work together, not in silos. In particular, many of the most innovative solutions come from engineers because they are the experts in what’s possible.
In companies where stakeholders dictate the roadmap, this is almost entirely absent.
In companies as diverse as Apple to Amazon, it’s ubiquitous.
Model Element 3 - The role of leadership
In this model, product strategy & team topology come from leadership. The key responsibilities of product leaders (managers) are:
Product strategy, in particular, what problems will the teams solve? You can’t have a different strategy for every product team in the organization.
Team topology: how will the teams be organized?
Coaching their employees to help them grow as professionals. Coaching is an essential responsibility of a manager.
Importantly, for empowerment to work, you also need leadership that creates psychological safety and genuinely cares about people’s growth.
Why are Designers and Engineers Upset With PMs?
So now, let’s go back to the designers in the room at the Figma conference with Brian Chesky.
Those designers actually would have likely also been joined by engineers. Why are designers and engineers upset with PMs?
Here’s what Brian Chesky postulated on Lenny’s Podcast (8:48):
Why did a room of 5,000 designers cheers when they thought I removed the product management function?
I think a lot of designers in the valley are frustrated with the product development process… Silicon Valley often treats design as a service organization. I think this is not just bad for design. It’s bad for product managers and engineers.
—Brian Chesky
His core observation aligns with the takeaways from the product operating model.
Most designers work with PMs who don’t involve them as a core partner on the WHY and WHAT. Because the PMs themselves don’t do that.
The PMs are really just order-takers for stakeholders.
When the product development process is broken, and that’s the operating model for PMs, designers, and engineers become upset with PMs.
Why are so many PMs miserable?
It’s a meme at this point:
The Reddit posts of PMs wondering if their job is real, whether there is a future for PM as a career, and a general burnout from the job.
Sadly, the job of the feature PM is a miserable one.
Most people who are feature team product managers are not happy in their job.
—Marty Cagan
And since most PMs are feature PMs, we have an epidemic of unhappy PMs.
It’s why PM ended up the number one most wanted-to-quit job.
The solution if you hate your job is to understand how you can transform your job.
Today’s deep dive
Today’s deep dive is an all-purpose guide for PMs, product leaders, and executives who want to push forward transformation in their companies. We’re going to put our own spin on Marty’s work and share the lessons from our own experience.
Word Count: 6,037 | Est. Reading Time: 28
Addressing the key criticisms of the Product Model
Who transformation to is best for
What a transformation is and isn’t
The key elements to a transformation
How to drive transformation as a product leader
How to drive transformation as an individual contributor
Most common mistakes in implementing a transformation
Our thoughts on where the product model might not be a fit
1. Addressing the key criticisms of the Product Model
As Marty is a key figure in the history of product management, there’s been lots of discussion of his work — and criticism.
Let’s cover the 4 most common criticisms: it’s too idealistic, all that matters is the execs, and the PM’s value is from glue & not strategy, and this PM job is too hard.
Criticism 1 - It’s too idealistic
The most common complaint of the product operating model is that it creates an idealistic picture of the job:
It's definitely aspirational. 99% of companies and teams don't work in anything close to the environment Marty envisions
Simply: it’s true. These principles are idealistic.
The product operating model is like watching how a pro team plays a sport. It’s likely going to be very different from how you play it. And that’s okay.
But over time, you try to progress towards the pro direction.
We followed up with Marty directly about this over e-mail for this post:
This is mainly from people that have never seen product done well at a good product company, and partly because they don't believe they have the power to change.
It’s easy to criticize what you haven’t seen.
Subset: It papers over politics
A subset of the idealistic criticism is that the product model ignores that PMs spend most of the week justifying their decisions.
It typically sounds like this:
I joined product management after years of following Marty Cagan-esque material. Realizing the job is frequently much less about discovering user needs and much more about managing insane and demoralizing politics has been a punch in the gut. I can do this job but I wish someone had been realistic and prepared me for it
This is the brutal reality of the PM job. Politics is a part of it, empowered or not.
Criticism 2 - All that matters is the execs
The second area of more substantive criticism is that all the matters is execs:
The only people that matter are the execs. They set rules, they create systems, they control what gets built by controlling what gets funded. No number of best practices from Marty Cagan books will free an IC (individual contributor) to make big changes against the dysfunctional commitments of their employer.
Again: it’s true. An IC just can’t fix a broken system, on their own.
But they can:
Raise their skills to be a better partner in a discussion.
Exercise some control over how things work in their particular team.
Work with leaders and colleagues to win their minds and hearts and slowly change things.
Consider moving to an environment operating at a higher level.
Marty expounded on this:
This is really the topic of agency, and people not realizing how much they can impact, and the goal of the book is to show how product teams and product leaders earn the trust and respect of the execs and stakeholders by delivering outcomes.
We’ll go deeper on how those ICs can do exactly that later in the piece.
Criticism 3 - PM’s value is from glue and being a Subject Matter Expert (SME), not strategy
The final area commonly criticized is that PMs have little value in driving strategy:
Can we not be so cringe in thinking ourselves these deep strategists saving the company? Almost all the value of the PM comes from being a SME and a good communicator, rather than some expert on "product strategy." Marty Cagan is selling a luxury, not a day-to-day reality for most PMs.
This is, again: fair.
Marty explains in the above interview that product leaders are primarily responsible for product strategy and vision, not IC PMs.
IC PMs may indeed find driving strategy to be a luxury that isn’t their day-to-day.
Day-to-day, a lot of their value instead comes from discovering solutions and driving outcomes.
Criticism 4 - The PM job Marty describes is too hard
The final area of criticism you hear often is that the job done this way would take far too long:
I find it really dangerous that is he so popular in the PM world. PM organizations going as far as disturbing his books to teams to make their organization more "product".
Such as saying any "decent" product manager would work at least 50 hours a week?! Excuse me, but I don't work more than 40 hours a week no matter what.
This relates to the confusion with criticism 3.
There are a few things you can do to address the workload of PMs.
First, PMs shouldn’t have to work 50 hours a week if product leaders are doing a strong job on product strategy and vision.
Second, product teams should set expectations for designers and engineers to be equal partners in the product process.
This ends up reducing the project managerial responsibilities of PMs.
Marty expanded on these points over e-mail:
It relates to the confusion behind the previous criticism. People think the PM is supposed to do things like product vision and product strategy (which would be a huge job on top of actual product manager responsibilities). But vision and strategy are part of the product leader's job, which makes the PM job more manageable.
So while it doesn't need to take 50-60 hours a week, it is still a hard job because of the thinking and problem solving required.
None of these invalidate the product model
Even if all of three above things are true, there are still benefits to taking product lessons from how the best companies do it.
The goal isn’t to take everything below 100%. It’s to observe the common patterns, and adopt what you can.
So, now that we’ve got the criticism out of the way, let’s get into the meat of it.
2. Who transformation is best for
Let’s just get this out of the way: In our opinion, transforming into the wholesale product isn’t for everyone.
If you’re in a tech-first company with a founder-CEO who is also the head of product and believes they 'know best,' changing their mind might be difficult.
But if you’re:
A senior leader in a tech-first company (B2B, B2C, B2B2C): you understand the need for change. This article will help you understand how to innovate and prevent others from capturing your market share.
A senior leader in a large company that is trying to improve its R&D (Research & Development) organizations: if you work in finance, oil & gas, or transportation, this article is perfect for you.
Working in a company without executive leadership significantly involved in product: if you work in a tech company where the executive leadership isn’t tightly controlling the product process, they may be open to change, even if you are an IC. We share our recommendations in chapters 5 and 6.
Working in a startup trying to implement better product practices: if you have founders that haven’t been designers or PMs, this article can help you share new ways of working with them.
A final area that you may also find this piece valuable is:
If you’re in big tech — maybe even one of the ‘top’ companies — but aren’t working in this fashion.
We’re going to focus a lot on how individual PMs and product leaders can change their circumstances and be less miserable with their jobs.
3. What a transformation is and isn’t
Transformation is often a theater accompanied by fake practices. Many companies go through the motions without really changing how they or their employees work.
It's not just about adopting new tools, methodologies, and restructuring teams. It’s more profound.
Keep reading with a 7-day free trial
Subscribe to The Product Compass to keep reading this post and get 7 days of free access to the full post archives.
 | A guest post by
|