Most technology organisations know they need to change. The language of empowered teams, outcome orientation, and product discovery has reached every level of leadership. What is far less understood is how that change actually happens - what needs to shift, in what sequence, at what organisational level, and at what personal cost to the leaders who are expected to drive it.
Marty Cagan's Transformed is the most direct answer to that question he has written. It picks up where Inspired and Empowered left off - describing not what great product organisations look like in steady state, but what the journey from an IT-delivery model to a product operating model actually involves. It is a more demanding book than its predecessors, because it is asking organisations to look honestly at what they are and what they need to become.
The vast majority of large technology organisations are operating on what Cagan calls the "IT model" - technology as a delivery arm of the business, executing on roadmaps defined by stakeholders, measured on feature delivery and project completion. This model was adequate when technology was a support capability. It is inadequate when technology is the product, the competitive differentiator, and the primary means by which the organisation creates value.
Transformed is for the leaders who already know this is true and are struggling with the practical reality of changing it - against resistance, within constraints, without destroying the delivery capability they already have while trying to build the product capability they need.
Cagan's characterisation of the IT model is precise and recognisable: technology teams exist to serve the business, which defines what needs to be built. Work flows in as requirements from stakeholders, product managers prioritise and translate, and engineers deliver. Success is defined as on-time delivery of committed scope.
The product model inverts this relationship: product teams are accountable for business outcomes, not feature delivery. They have genuine authority over product decisions and genuine accountability for whether those decisions produce results. Stakeholders set the outcomes they need; teams have freedom over the means.
The transition between these models requires changing who makes what decisions, how success is defined, what skills product managers need to develop, and what the relationship between technology and business leadership looks like. None of these changes are superficial.
One of the book's most important structural arguments is that enterprise transformation does not happen by changing everything at once - it happens by creating a small number of genuinely transformed teams that demonstrate what good looks like, and using that evidence to build the case and the capability for wider change.
This pilot model has several implications. The teams chosen for the pilot need to be set up to succeed - given genuine autonomy, good coaching, clear outcome goals, and protection from the organisational forces that will try to pull them back toward the IT model. And the outcomes they produce need to be made visible to leadership as evidence that the model works, not just as a team achievement.
The most uncomfortable argument in Transformed is directed at the senior leaders who commission transformation programmes and then watch them fail. Cagan's diagnosis is blunt: most transformation efforts fail not because of poor execution at the team level, but because senior leaders have not changed their own behaviour.
The leader who still approves every roadmap decision is not running an empowered product organisation - they are running an approval-dependent one with better vocabulary. The leader who measures teams on feature velocity rather than outcome achievement is not running an outcome-oriented organisation. And the leader who has not personally invested in understanding modern product practice cannot coach the people they are responsible for developing.
Transformation requires leaders to change their own mental models, their own daily behaviours, and their own definition of their role. This is harder than any process change, and it is where most transformations stall.
A recurring theme in Transformed is that the product operating model is a coherent system of practices, roles, and relationships - and that partial adoption is more dangerous than no adoption. Organisations that adopt the vocabulary (empowered teams, outcomes, discovery) without changing the underlying decision-making structures produce confusion, not transformation.
Specifically: empowered teams that are not given genuine authority are just confused teams. Outcome goals without the autonomy to choose the means of achieving them are just rebranded feature requests. Discovery practices without the organisational willingness to act on what is discovered are just more expensive research.
The system works when all of its components are in place. The sequence of adoption matters - but the commitment to complete adoption matters more.
The final insight is a direct application of the outcome-versus-output principle to the transformation process itself. Transformation should not be measured by how many teams have adopted agile, how many product managers have completed discovery training, or how many roadmaps have been converted to outcome formats. It should be measured by whether the products are getting better, customers are getting more value, and the business is seeing the results that the new model is supposed to produce.
This is a high bar, and Cagan is uncompromising about it. The question that should be asked at every stage of transformation is not "are we following the model?" but "are we getting better at building things people want?" If the answer is not clearly yes after a reasonable period, the transformation is performing rather than producing.
The most powerful signal that a transformation is not working is when the teams that were supposed to be empowered are still waiting for approval before making product decisions. If that is happening, the transformation has changed the language without changing the power structure.
Transformation programmes that are owned by programme management offices will produce programme management artefacts: adoption metrics, training completion rates, and process compliance data. These are not evidence of transformation. They are evidence of a well-run programme.
The leaders most committed to transformation in public are often the ones most resistant to the personal changes it requires in private. The test is simple: what decisions are they still making that an empowered product team should be making instead?
If your product managers could not independently define the outcomes they are working toward, identify the customers they are serving, and make product decisions without escalation - they are not operating as product managers yet. This is not a skills failure. It is a system failure.
The best evidence that transformation is working is the quality of the products. Not the process health metrics. Not the team satisfaction scores. Whether the products are measurably better for customers than they were a year ago.
Identify your pilot team. Which team has the right skills, the right leader, and enough organisational breathing room to demonstrate the product operating model? Define their outcome goal, give them genuine authority, and protect them from process interference for one quarter.
Audit the decisions you are making that your product teams should be making. List every roadmap decision, prioritisation choice, or product direction call that you made in the last month. For each, ask: why did this come to me? What would need to be true for this to be made by the team?
Have a direct conversation with your product leadership about coaching. Not training programmes - coaching. What specific capability gaps are you working on with each of your product leaders? What does good look like for each of them in six months? If you cannot answer these questions, the development investment is not targeted.
Define your transformation outcome. Not "adopt the product operating model." What business result will you achieve that you cannot achieve with the IT model? What customer outcome will be measurably better? Name it, measure it, and make it the north star of the transformation effort.
Share the evidence of the pilot. When the pilot team achieves something - however small - make it visible to the organisation in terms of customer outcome and business result. Transformation requires a narrative, and the narrative needs to be built on real evidence from real teams.
"The goal of transformation is not to adopt a model. It is to build products that your customers love and that work for your business. Everything else - the practices, the processes, the organisational structure - is in service of that goal."
- Marty Cagan