Marty Cagan on TRANSFORMED: Moving to the Product Operating ModelHow 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. Pawel and I learned that, and more, in an hour-long conversation with Marty Cagan:  In this conversation, Marty Cagan:
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.
It guides you in assessing your current situation, understanding where you want to be, and planning a path to transformation. Supplemental Thoughts to TransformationIn the spirit of supporting Marty’s guide, the inimitable Paweł Huryn of The Product Compass 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 DifferentLet’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:
In our perspective, you can translate this into 3 key elements of the Product Operating Model (this classification doesn’t come from the book):
Let’s cover each. Model Element 1 - The principles of the teamCompanies like Apple and Google have dramatically different cultures. We all know that. But the principles they emphasize in product development are relatively the same:
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 doEven 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 focus on different risk areas:
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 leadershipIn this model, product strategy & team topology come from leadership. The key responsibilities of product leaders (managers) are:
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):
His core observation aligns with the takeaways from the product operating model. The majority of 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.
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 diveToday’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,677 | Est. Reading Time: 30
1. Addressing the key criticisms of the Product ModelAs 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 idealisticThe most common complaint of the product operating model is that it creates an idealistic picture of the job:
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:
It’s easy to criticize what you haven’t seen. Subset: It papers over politicsA subset of the idealistic criticism is that the product model ignores that PMs spend the majority of the week justifying their decisions. It typically sounds like this:
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 execsThe second area of more substantive criticism is that all the matters is execs:
Again: it’s true. An IC just can’t fix a broken system, on their own. But they can:
Marty expounded on this:
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 strategyThe final area commonly criticized is that PMs have little value in driving strategy:
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 hardThe final area of criticism you hear often is that the job done this way would take far too long:
This relates the confusion with criticism 3. There’s 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 the expectations for designers and engineers to be equal partners in the product process. This ends up reducing project managerial responsibilities of PMs. Marty expanded on these points over e-mail:
None of these invalidate the product modelEven 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 forLet’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 final area that you may also find this piece valuable is:
We’re going to focus a lot on how individual PMs and product leaders can change their circumstances and be less miserable with their job. 3. What a transformation is and isn’tTransformation 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... This post is for paid subscribers. You can unlock 1 post for free.A subscription gets you:
|
This week’s system design refresher: Top 9 Most Popular API Protocols (Youtube video) What is a deadlock? What’s the difference between Session-based authentication and JWTs? Top 6 ElasticSearch Use Cases Top 9 Cases Behind 100% CPU Usage SPONSOR US ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ...
Comments
Post a Comment