TRANSFORMED: Moving to the Product Operating Model with Marty Cagan

How do the best product companies work? How to Transition from Waterfall, Outputs, and Un-empowered Teams to the Product Operating Model. A post by Paweł Huryn and Aakash Gupta.

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 (Pawel) 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

We 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 Aakash Gupta 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:

1. 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.
2. 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.
3. 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):

1. The principles of the team
2. What the people on the product team actually do
3. 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:

1. Teams are empowered to come up with solutions to problems
2. 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.

Thanks a lot

We’ve covered much more in our newsletters:

1. Addressing the key criticisms of the Product Model
2. Who transformation is best for
3. 🔒 What a transformation is and isn’t
4. 🔒 The key elements to a transformation
5. 🔒 How to drive transformation as a product leader
6. 🔒 How to drive transformation as an individual contributor
7. 🔒 Most common mistakes in implementing a transformation
8. 🔒 Our thoughts on where the product model might not be a fit

Two identical posts (choose randomly):

1. Product Growth by Aakash Gupta: https://www.news.aakashg.com/p/transformed-product-operating-model-marty-cagan
2. The Product Compass by Paweł Huryn: https://www.productcompass.pm/p/transformed-product-operating-model-marty-cagan