In February 2023, Marty Cagan announced his new book, “Transformed” on the SVPG blog. Rather than solely focusing on the responsibilities of product managers and product leaders, his book explores how companies can successfully embrace the Product Operating Model.
Since 2017, Marty Cagan has shaped product management and serves as the indisputable face of product-led culture. The fact that he is finally moving away from an idealistic approach is great news for anyone who doesn’t work at FAANG (Facebook, Amazon, Apple, Netflix. and Google).
In this article, you will learn what this new terminology stands for, where it comes from and why it’s worth pursuing by any company or team that wants to be transformed.
The concept of “operating model” is considerably older than its “product” version. An operating model is the crossroad between strategy (why you do what you do) and process (how you do what you do). By aligning the organization’s objectives and vision with the day-to-day activities and expertises, one can increase efficiency across the entire company.
From that original concept, all types of operating models were invented: the Target Operating Model, Dynamic Operating Model, the Flashpoint Flexible Consumption Operating Model, etc. Most of these come from consultancy agencies to sell their services.
The Product Operating Model is a little different.
The first mention of the Product Operating Model comes from a presentation made by Kristen Linnea Johnson and Carol Stone, both AWS advisors, in the 2019 instance of the AWS innovation conference called “re:Invent.”
Amazon is regarded as one of the best product companies out there. A lot of what we consider as product mindset today was built around Jeff Bezzos’ vision on how to scale a business centered on the customer.
The key difference with the Product Operating Model is that it revolves around the user, not the product. The name is a little misleading, but bear with me: companies usually build and then sell. You receive a demand, put something together based on that express demand and then deliver.
This approach is completely product centric since you spend most of your time and effort building it. In a customer centric approach, you should be spending more time with the customer instead.
The famous “working backwards” inside Amazon is exactly that: spend as little time as possible building and as much time as possible validating hypotheses with your customers. Instead of building around specifications, you build around gathered knowledge. This implies that users are the most vital aspect of your operating model, not builders.
And who is the one inside an organization responsible for gathering and disseminating knowledge? The paragon of business in a tech dominated land, the bridge between the ones who build and the ones who sell? The product manager.
That’s why the operating model’s first name is product and not customer. The Product Operating Model revolves around empowered product managers and how they can easily navigate across the entire organization to prioritize, learn, and deliver the best possible value for users.
As time went by, the Product Operating Model became less of an Amazon thing and more of a Silicon Valley trend. From 2019 up until 2022, most of the big and promising names in the tech industry used some version of the Product Operating Model.
The Product Operating Model has a set of indistinguishable characteristics that account for its identity. Also commonly referred as “product-led”, the following are the building blocks of the Product Operating Model:
In the Product Operating Model, teams are not organized around skills, but around challenges. A team that organizes itself around achieving an outcome instead of just delivering features will be way more in sync with the users’ needs, thus ensuring that the user is at the center, not the product.
Also known as the “Spotify squad model,” teams that organize themselves around outcomes must be multidisciplinary by default, since no single speciality will be able to tackle complex problems all by itself.
Pursuing outcomes is way different than performing reckless deliveries. When teams account for the problems they solve rather than the amount of work they do, mitigating the possible risks of not delivering an expected outcome becomes almost as important as building towards said outcome.
Multidisciplinary teams working to address a single issue dilutes the amount of time a team can fully dedicate to each speciality: if you spend more time building than mitigating risk, you might miss the user’s perspective, meaning that your solution won’t solve the challenge that it was supposed to. Alternatively, if you only mitigate risks, you won’t deliver a solution at all, which also fails to solve your challenge.
The solution lies in balance, with quick building loops that start and end with risk mitigation: the famous lean cycle.You hypothesize based on available data, build to validate the hypothesis, and verify results. Do it in cycles and, in theory, you would be able to iteratively deliver on your team’s challenge.
But for that cycle to work like a clock, there must be a strong alignment between specialists within a team. Without a singular directive, it’s perfectly natural that what should be a cooperative build up becomes a competitive stalemate.
Individuals within a team will eventually disagree on priorities, given that each sees issues from different perspectives. When the team is unable to find a solution, a deadlock scenario might ensue, as antagonic perspectives scale the corporate ladder. That’s why it’s so important that outcomes are shared across the entire company, not just within teams.
OKRs are a great way of ensuring that the whole company, from the C-level down to the specialist, are on the same page. With a solid objective in place, hierarchy doesn’t have as much weight. An ill resolved feud between departments can seriously jeopardize a company’s ability to deliver whatever outcome it needs to.
Multidisciplinary teams are not an alternative to speciality stacks, they are a complement. There is no single hierarchical authority over a team.
An empowered team is a team that lacks direct management not by design, but by necessity. Multidisciplinary teams are intended to leverage several different specialities in harmony and direct hierarchical control only damages that.
Middle managers are one of the last heritages we carry over from our project led past. These authority figures were responsible for enforcing the “command and control” policy, with the sole objective of squashing critical thinking and creativity in favor of predictability and scope adhesion.
A “one size fits all” type of management is completely against the volatile nature of problem solving. As users change, so should the teams, scrambling and reorganizing itself in order to better perform their job.
The final piece of the puzzle is the risk mitigating itself. Without a clear definition of which questions must be answered, it’s easy to get lost and validate the wrong answers for the correct question. The four product risks are:
Is this hypothesis the best one to be validated now? Is this the most cost-effective initiative we can take? Will this answer help us achieve our goals? How much money can we make from it?
Has the user manifested interest in this solution? Will they be able to use it? Does it solve our users’ challenge? Is it aesthetically pleasing? Is it vital for the user, or just a luxury?
Do we have the resources and know-how to deliver it? Can we scale this solution? How much will it cost? Will it depreciate fast? Is it the best cost-effective solution? Will it deliver on what the user needs?
Is this solution safe both for the user and for the business? Is it inclusive enough? Is there a risk of public opinion whiplash? Is our solution enabling wrongdoers? Are we jeopardizing some to privilege others?
Agile is over 20 years old now, the lean cycle is older than 10 and the Product Operating Model itself is almost 5 years old. After the pandemic and the startup winter in 2022, so much has changed that one can’t help but wonder if it’s still worth pursuing product management as dictated by Silicon Valley.
Money was cheap, meaning that everybody was free to chase big KPIs. Investor money would pour in as long as your acquisition and retention numbers were impressive. What does it matter if your cash burn ratio was through the roof? What if your product is way behind profitability? You don’t need sales, you need investors.
That’s the environment in which the Product Operating Model thrived in, and more traditional sectors of the tech industry have finally started questioning this almost ubiquitous presence in modern management. You can’t sell outcomes, after all.
Although It’s true that you can’t sell an outcome and that making something better and better doesn’t necessarily mean that it’s making money, or that it will make some day, there might be a compromise between the two opposing views.
It’s way easier to keep a business running under the sell, build, deliver logic. But we’ve done that already, and we know that this is not ideal. Old timers from industries that were disrupted by newcomers suffered their fate because they went against organizations that had better operating models.
Amazon, alone, killed the bookstore, brick and mortar, datacenter, and logistics industries. We can’t simply assume their operating model as outdated.
With the worst of the start-up crisis behind us, apparently, I would say that we might find something in between. Non-tech related departments were pretty much muted up until recently: marketing, sales, customer success. All of those responsible for “taking orders” from customers were downplayed by engineering, design, data and product. I see a comeback happening.
I can’t imagine we simply break away from the Product Operating Method, but it might grow, embracing in scope specialists that are more suited for making sales rather than building knowledge. It’s too soon to commit to anything, but saying that the Product Operating Model has become irrelevant is precipitated.
As a matter of fact, if it’s under transformation, the Product Operating Model is more relevant than ever. Those that, until today, haven’t at least scraped its surface, will have a very hard time coming to terms with it after it undergoes its first substantial transformation ever since its inception.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
As a PM, you can assess your team dynamics with the drama triangle by identifying victims, rescuers, and prosecutors.
Maksym Kunytsia talks about Ideals’ code of conduct for collaboration, which is combined with continuous discovery and continuous delivery.
Over the last years, tech people became resistant to Agile frameworks because their expectations of empowerment didn’t materialize.
Andrew Cheng, VP of Product Management at WellSky, shares examples when he’s made short-term trade-offs for long-term career opportunities.
Learn more →
