This book titled “Transformed: Moving to the Product Operating Model” is the third one on core product management principles by the venerable Marty Cagan. His first two books Empowered and Inspired have been referenced umpteen number of times in product circles and are absolutely must-reads for anyone wishing to start their PM careers on a solid footing or in general for brushing up on fundamentals which sometimes are relegated in the background during professional grind!
This book as the many reviewers put it in its beginning aims to be “an essential guide for any company navigating the transition to the product operating model”. The book differentiates itself from author’s other two books by directly “addressing how to make the necessary changes to how you work”
Here are a few key takeaways for me from this book
- The product operating model is about consistently creating technology-powered solutions that your customers love, yet work for your business. And “the product model is meant to address the unique challenges of those who are building technology-powered products and services”
- There are 3 axes along which product model brings change
- how you build (product delivery)
- how you solve problems (product discovery)
- how you decide which problems to solve (product vision and strategy)
- There are 3 axes along which product model brings change
- The CEO in any org is the chief evangelist of the product model and for any transformation work to have reasonable chance of success, it’s imperative that the CEO is aligned, supportive and preferably the driver of the work him/herself
- The general rule of thumb is that any idea tested in product discovery should be at least one order of magnitude less expensive and faster than using the engineers to build, test, and deploy an actual product
- Here are a few thumb rules to assess product competency levels and expectations of PMs and their leaders
- It’s important that product leaders are NOT seen by other leaders to be having their own agenda in the journey of transformation hence being transparent is a must
- Product leaders should lead with context rather than control. People see what the their leaders do, especially under stress
- It’s important for product leaders to assess the overall chemistry of each team and either coach or shuffle people to get the teams to operate together effectively. To foster collaboration, OKRs can be assigned to the product team rather than to individual members
- One clear sign that the product team lacks a competent product manager is that all decisions require either an escalation to a manager or a stakeholder meeting where the stakeholders are asked to decide
- How are PMs perceived by the executive team and are the product managers receiving coaching on a weekly basis?
- Are product leaders deeply aware of what is going on in their product teams without micromanaging them?
- Your head of product will be judged by her weakest product manager
- Your CEO should believe that each of your product managers has the potential to be a future leader of your company in the next five or so years
- The product leaders are specifically responsible for the product vision, the team topology, the product strategy, and the specific team objectives
- Purpose of the product vision is to describe the future that you are trying to create, whereas the product strategy begins by focusing on the most critical areas for business success
- Product vision is typically the single most powerful recruiting tool for strong product people
- Purpose of the product vision is to persuade and inspire—it is meant to be emotional
- The product strategy describes how you plan to accomplish the product vision, while meeting the needs of the business as you go
- Experienced product leaders will manage the portfolio of risks by placing a series of bets each quarter, working to maximize the likelihood of meeting the company’s annual business objectives by the end of the year
- In any org, direct access to users and customers, direct access to data, and direct access to stakeholders is key for success of PMs. Having this direct access is one of the few truly non-negotiables in the product operating model
- Of all the principles underlying the product model, the single most important one is the realization that innovation absolutely depends on empowered engineers
- In data-driven product management, the big limitation is that this data generally can’t tell you why customers are using (or not using) your product ideas
- High integrity commitments (i.e. release a feature X by date Y because someone highest up there is asking for it!), though sometimes absolutely essential, should be sparingly used by leaders since they break the product operation model
- Technical debt is one of the true business continuity risks that companies face and of course sometimes is desirable
- It is usually better to have a smaller number of somewhat larger teams than a large number of small teams
- Innovation should be prioritized over predictability in product delivery
- If at all the product team is to build a feature for one specific customer, it’s their job to ensure that the feature is useful for many other customers. Else this task should NOT be undertaken!
- These one-off requests generally come due to lack of having referenceable customers for salespersons
- The reason why strong product solutions rarely come from customers or salespersons is because they may not know what’s technically possible now
- With customers, if there is a choice it’s preferable to share the product vision rather than product roadmaps
- To build really fruitful relations with stakeholders in the organization, the onus is on the product leadership to ensure that every product team has a competent product manager who has put in the work to understand the various constraints of the business and to be an effective partner to the stakeholders
- Product teams depend on the executives to share as much of the relevant strategic context as possible, so as to make good decisions. And executives expect product teams to share openly and honestly the data and reasoning used to make their decisions
- To avoid surprises, Product teams must commit to preview any potentially risky solution with the relevant executives before building it
- How to know if there is enough focus on product discovery work in your team?
- If the number of ideas being tested is the same as the number of items being built, then this is likely product design rather than product discovery
- And lastly product teams must produce results!
This book can be finished in a long 5-6 hours sitting. The adage around valuability, viability, usability and feasibility is repeated many times over. Similarly belabored is the point about the need to build solutions for customer pain which also works for the business. Case studies, though enjoyable to read, break the flow. The impact of AI on the future of PMs, their competencies, product operating model and the overall transformation playbook is hurriedly described and I feel could have been covered adequately considering we are two years into GAI era now. All in all, you should read this book – not in the least to understand how inspired and empowered product teams can bring about transformative changes to their organization and how to overcome org inertia to the change!
This book seemed to repeat a long list of mantras and marketing concepts that can be used to socialize the “concept” within an organization. What it does not do is explain the mechanics of what this actually means.
ex: “The product operating model is about consistently creating technology-powered solutions that your customers love, yet work for your business.“
Cool story. What does that even mean?
“Innovation should be prioritized over predictability in product delivery “
Great. So…… ?
LikeLike
I somewhat agree with overall characteritisation, Marty Cagan does sound “theoretical” at certain places. To your question, I think what he means is creating space for disruptive / untried bets over the ones wherein outcomes are within bounds. For example, if you are an ecommerce company – you can of course optimize your checkout conversion to the t (predictability) AND / OR decide to experiment with a novel way of checkout (innovation). Depending on how the tech stack is built, the latter can be disruptive / non-trivial implementation
LikeLike