Empowered

Cagan's position, stated bluntly: the biggest difference between the best product companies and the rest is the role of leadership, and most product leaders are doing a different job from the one required.

His formulation is that ordinary companies use their engineers to write code and their leaders to decide what code to write, while strong companies use leaders to build teams capable of deciding.

Weak companies use engineers to write code. Strong ones use leaders to build teams that can decide what to write.

Devmark’s reading — not a quotation from the book

His first and largest section argues that developing people is the manager's main responsibility rather than an adjunct to it, and that most product managers are never actually coached.

His coaching tools — the assessment of competencies, the coaching plan, the weekly one-on-one focused on capability rather than status — are specific and are the most immediately usable material in the book.

His argument that hiring is the second core responsibility and that leaders routinely delegate it to recruiters and to process.

His position on the product manager role is deliberately provocative: it requires deep knowledge of the customer, the data, the business and the industry, and most people in the role have not been developed to that standard because nobody took responsibility for developing them.

His treatment of vision as a concrete artefact — a three-to-ten-year picture of the future you intend to create, communicated in a form people can actually see.

His related concept of product principles is underrated: the standing decisions about what your product will and will not do, which resolve a large class of future arguments in advance rather than re-litigating them.

His material on how to divide work across teams, which he treats as a consequential and under-considered design decision.

His principles — align with architecture, minimise dependencies, give each team a meaningful problem space, and accept that no topology is permanent — are sound, and his observation that most organisations divide by feature rather than by problem is the common failure.

His framework is focus, insight, action, management. Choose a small number of objectives, derive insight from data and customer contact, convert that into specific team objectives, and manage the resulting work actively.

His emphasis on insight is the distinguishing element — his claim is that most strategy documents contain decisions without any insight that justifies them.

Most strategy documents contain decisions with no insight behind them. The insight is the part that is missing.

Devmark’s reading — not a quotation from the book

His treatment of OKRs is more critical than Doerr's: he argues they only work in an empowered team model, and that applying them to feature teams produces theatre, because the team cannot choose how to achieve an outcome it was handed as a feature.

This is a sharper observation than most writing on the subject and explains a large share of failed OKR adoptions.

The evidence is consulting experience and named case studies from companies that agreed to participate. There is no comparison group and no systematic data.

The model is also specific to product companies building software at reasonable scale. Its applicability to agencies, to regulated industries, and to companies where the product is not the business is assumed rather than argued.

There is substantial overlap with *Inspired* and with *Transformed*, and the three books restate a common set of positions with different emphases.

Readers report that the coaching section is the distinctive content here and that much of the rest is familiar if they have read the others, which is a fair assessment.

The coaching argument, taken seriously: if you manage people and cannot describe what each of them is working on developing, you are doing a different job from the one the book describes.

And the product-principles idea, which is cheap, durable, and removes a recurring category of argument by deciding it once.