Takeaways From Reading Transformed by Marty Cagan
I recently finished “Transformed” by Marty Cagan and team, and it’s helping me connect some crucial dots about how modern product organizations actually work. Here are the key themes I’m continuing to grapple with afterwards.
The IT vs Product Operating Model
The biggest eye-opener for me has been understanding the fundamental difference between IT and product operating models. You can spot an IT model when you hear people refer to “the business” as a separate entity making requests. In contrast, a product model implies an integrated and empowered team, solving customer problems in ways that work for the business.
This isn’t just semantics - it completely changes how work gets done:
- In an IT model, business analysts translate stakeholder requests into requirements
- In a product model, product managers and designers work directly with stakeholders to understand underlying problems
- In an IT model, teams commit to delivering features by dates
- In a product model, teams commit to solving problems and demonstrating outcomes
I’m highlighting the contrasts, but the changes are more on a spectrum of frequency than a mutually exclusive state. Said another way, you can tell if you’re in one model vs the other by how frequently you hear the language of that model.
High-Integrity Commitments: A Different Way to Think About Dates
Zooming in on the delivery date topic is fascinating to me. Rather than treating every delivery as date-driven, they introduce “high-integrity commitments” - a formal process for those rare cases when a specific date really matters.
What’s fascinating is who makes these commitments: not executives, not sales, not even product managers - only the product team itself can commit to dates. And they can only do so after proper discovery work to derisk the solution.
This ties into a deeper truth I’m still processing: in modern product development, you often need multiple teams pursuing the same goal to derisk important deliveries. When I reflect on projects in my career that missed dates, I can see how having just one team per problem (common in IT models) set us up for challenges.
Leadership as Coaching
Perhaps the most surprising insight is about product leadership role in the organization. The book suggests that coaching should take up to 80% of a product leader’s time - far more than I typically see discussed. This isn’t just mentoring; it’s about helping teams transition from feature delivery to genuine problem-solving.
In practice, I see leadership roles most often expected to be a “player-coach” model, which can be short-hand for a Principal PM with a side gig of mentorship. The team behind Transformed strongly believe in the leader being the accountable educator: not a consultant or a training team or a seminar. It’s the leader’s role to improve the practice.
Still Processing
There’s a lot I’m still wrestling with:
- How do you maintain a mapping of the frequent and specific releases with larger strategic initiatives?
- How do you make headway in this model when parts of the organization still operate in an IT mindset?
- Is the implication of all leadership roles similar, ie shift to coaching rather than decisions?
The book emphasizes that the product operating model isn’t about standardization or common templates - it’s about creating a culture of experimentation where innovation is prioritized over predictability. That’s a profound shift in thinking about how modern businesses should operate.
If you’re involved in product development at any level, I highly recommend picking up a copy. It’s helping me see both where we’re headed and why some of our current challenges exist.
Have you read it? I’d love to hear what insights resonated most with you.