Transformed

Cagan's earlier books describe how strong product organisations work. The obvious question that follows is what a company should do if it is not one, and this book is the attempt at that answer.

His framing is that the gap is not knowledge but operating model — the combination of how a company builds, how it solves problems, and how it decides what to work on — and that changing it is organisational rather than procedural.

Everyone can read how good product companies work. The hard question is what to do if you are not one.

Devmark’s reading — not a quotation from the book

His central diagnosis: most companies have feature teams, which are given solutions to build and are measured on delivery, rather than product teams, which are given problems to solve and are measured on outcomes.

His claim is that this single structural difference accounts for most of the gap in results, and that no amount of process improvement inside a feature team model produces the behaviour of a product team.

His model of what has to change: how you build, how you solve problems, and how you decide which problems to solve.

The ordering matters. Companies typically attempt the first — agile practices, delivery improvement — and stop there, which produces faster delivery of the same poorly chosen work. The second and third are where the outcome difference sits.

His definition, which is demanding: a durable team of a product manager, a designer and engineers, given a problem to solve and the authority to decide how, held accountable for a measurable outcome.

Each clause is load-bearing. A team missing the designer, or given a solution rather than a problem, or reassigned every quarter, is not this, however it is labelled.

His treatment of the third competency, and the one he considers most commonly missing: deciding which few problems matter most, which requires focus, insight, and a willingness to say no to things that are individually reasonable.

His criticism of the roadmap as usually practised — a list of features with dates, produced by collecting requests — is that it removes the need to choose, which is exactly what strategy is for.

A roadmap assembled from requests removes the need to choose, which is the only thing strategy does.

Devmark’s reading — not a quotation from the book

His practical guidance on changing an existing company: start with a small number of teams rather than announcing a reorganisation, demonstrate results, and expand from evidence.

His insistence that this requires sustained executive sponsorship, and that transformations without it reliably revert, is the least comfortable and most accurate part of the book.

His argument that the constraint is usually leadership behaviour rather than team capability: executives who assign solutions, demand delivery dates for unvalidated work, and treat product teams as implementation capacity will produce feature teams regardless of what the teams are called.

This is the book's most direct challenge and the reason it is uncomfortable reading for its likely audience.

The evidence is Cagan's consulting practice and the case studies are supplied by companies willing to be featured, with the usual selection problem and no failures examined in detail.

The model also assumes a product-led software business. Companies where the product is not software, or where regulation or enterprise contracts constrain what teams can decide, will find the prescriptions harder to apply than the book suggests.

*Inspired* describes the practices, *Empowered* describes what leaders must do, and this describes how to get from a company that does neither to one that does both.

There is substantial repetition across the three, and a reader starting now could read this one and go back to the others selectively rather than working through all three.

The feature-team versus product-team distinction, applied honestly to your own organisation: are teams given problems or solutions, and what are they actually measured on?

And the ordering of the three competencies, which explains why so many agile transformations produce faster delivery of work that should not have been built.