The dark side of Marty Cagan'ization

Marty Cagan and his authorship has brought immense clarity to product world at a global scale. We can easily say that there was a world before the book Inspired, and after.

The Marty Cagan Phenomenon

Building products across India, SE Asia and Europe, I have first-hand witnessed the contribution and impact of Marty Cagan’s work on the product world. Once in many decades, someone brings a near absolute clarity on craftsmanship of a field and Marty Cagan brought that moment to the product world through his famous book INSPIRED and his other works.

By now, most of us who have read Marty’s works know (by heart) that Product Manager is fully responsible for the value (Will customers find value in the product?) and viability (Will it add business value?) risk associated with products.

The PM works with engineers (responsible for feasibility) and designers (responsible for usability of products), and also in a way takes responsibility of overall value delivered by team across the 4 types of risks.

Also, the PM is solely expected to have combined deep understanding of customers, business, industry and data. Of-course, all of this combined, the PMs have a lot on their shoulders and the job is not easy.

---

---

Since most product builders well aware of product practices laid down by Marty Cagan and his authorship has brought immense clarity to product world at a global scale, I call this phenomenon as Marty Cagan’ization. We can easily say that there was a world before the book INSPIRED and there is a world after.

But as with life and in product, all good comes at a cost. And this is the cost I wanted to make you aware about as we grow as product managers and leaders.

Product Managers, beware of the cagan’ization of Product Interviews

Given that Marty Cagan’s school of thought has guided and inspired many re-structuring of product organizations as well as how PMs operate, it has become a second nature to PMs to speak in the language of Marty Cagan.

Interview Question: Tell me about a leadership challenge you faced

PM Answers: As part of XYZ product launch, I discovered that while I was given full independence to guide the product team’s execution with engineers, but I was not fully in control of business value of the product as well as customer value. I felt I was not in an empowered position. So I evaluated that while we were getting good at feasbility risk and usability risk, the other two suffered. (** pauses with a Marty Cagan Cough**). So I explained to my management that we will never be an attractive employer if we continue to disempower Product Managers..

While one may argue it is a good answer or not, the marty cagan’ization of answer is clear. As a Product Manager giving interviews, there are two issues you should be aware about while giving such an answer or anything resembling the words picked from Marty Cagan book’s dictionary:

1. All organizations are not the same. There is not just ONE way of doing product. There could be many - in-fact theoretically infinitely more.

2. Your hiring managers are smart enough (hopefully) to know #1

As you learn and grow in your product experience, you will realize how different organizations do product. Some have done it not so Marty Cagan way and succeeded, such as Apple relying a lot on top-down decision making on designs and product choices. (Read full tweet here)

or Meta being a very engineering-led organization where Product Managers are mostly doing vision and strategy work with management + deciding jointly with tech leads on product roadmaps but leaving it pretty much to tech leads to achieve outcomes and drive product sprints.

It is not highly deviating from Cagan’s writings, but Meta definitely has a different flavor to it. (Read the full tweet on Meta here)

My experience working at Booking.com was very different. The product outcomes were completely dictated by statistical significance of experiments. The business value was standardized across the organization (increase booking conversions) and PMs would design experiments to optimize this metric and at the same time controlling whether it led to any increase in customer complaints or pains. I will not call it optimizing for customer value, but it was something like: “Let us increase business value, ensuring customer value was not harmed in the process”

So, in summary, if you’re giving an interview, it is important to note that the organization you are interviewing for may have its own product culture that has led to its immense success. Marty Cagan’s works are recommendations for great product practices, but it is not the only formula to succeed.

Keep your interview answers honest and uniquely yours (in your own words) while keeping the Marty Cagan framework at the back of your mind as a general best practice.

Product Leaders: Don’t blindly cagan’ize your organizations

Organizations have been gaining tremendously by adopting empowered team setups and also taking steps to further improve them. These setups lead to better maturity curve for PMs to care about both business and customer value while also evolving engineers and designers in the product success.

But, the truth is - not all organizations are either fit or at stage to move to this empowered product team setup. Sometimes, there needs to be fit-analysis or some pre-work needs to be done before moving to an empowered team setup.

PMs do not magically become empowered one morning, if you decided to tell your PMs they now onwards own value and viability. How would the top management change? How can they stop dictating business value? How do you get the right designers who care about usability and engineers who would participate in product decisioning?

Moving to the setup recommended by Marty Cagan requires change-management that impacts more than product teams - it impacts the decision-making machinery and overall cultural mindset.

As the demand of incoming Product Managers to work in empowered organizations have gone up, the product leaders (i.e hiring managers) on the other hand are moving their product cultures to marty-recommended empowered setup to satiate the demands.

I would recommend to do these checks before you plan to change your team setup:

1. Is the organization fit for empowered team setup right now? or later?

2. What do you need to do before you move to such a setup?

3. At what stage of product growth will this setup makes sense?

Lastly, build your unique product culture

…keeping Marty Cagan’s best practices in mind. As I shared in examples above (Meta/Apple/Booking.com), every organization grew to its million or billion dollar revenues with its own product culture, some of it might seem archaic or old-school but the fact is these businesses have been successful and their products are liked by customers. Hence, find what unique culture works for your business and customer problems.

Sometimes the pace at which you need to try experiments needs to be fast enough (for example when investor money is running out) that many decisions turn out to be founder-led. A founder is so different from a Product Manager, and the need for survival trumps all best practice discussions. In such cases, both product leaders and managers need to see what is needed and now what is best practice.

Or sometimes your organization just has a different kind of leader that likes to take product decisions because of his/her immense experience of catching patterns and trends - top-down decision making is not always bad when you have experts who could be mostly right about their decisions than being wrong. Of-course not always true, but many decisions could save a lot of time with experts on the team.

Or you might have ended up with an asshole boss who just owns your product roadmap. Then, the marty cagan’ization might become the right scale for you to know if the product culture is immensely pathetic or decently painful.

The last one might remind you of Elon Musk when he took over twitter (Source):

So, as a product leader, you need to utilize the marty cagan’ization of the product world in the way that it fits your situation. You could use it a yardstick to know if your product culture can get better, or you could use it as a way to communicate expected responsibilities across product team members, but you don’t have to make it your religion.