Cagan's follow-on to Inspired shifts from product craft to organizational conditions. The argument: you cannot have great products without empowered product teams, and empowered teams require managers who coach toward outcomes rather than manage toward outputs. Addresses the question Inspired leaves open — what do you change first?
Cagan, who ran product at eBay and founded the Silicon Valley Product Group, wrote this as a sequel to Inspired, moving from what product teams do to how leaders should enable them.
The central distinction is between what he calls feature teams and empowered product teams. A feature team is given a roadmap of features to build and is measured on delivery. An empowered team is given a problem to solve, expressed as a business outcome, along with the context to solve it, and is measured on whether the outcome improves. Cagan argues that the first arrangement wastes the capability of the people employed, produces features that do not move the outcomes anyone wanted, and cannot attract or retain strong engineers and designers.
The leadership content is what distinguishes this from his earlier book. Cagan argues that empowerment requires specific things from leaders that most do not supply: a product vision that gives teams a shared direction over years, a product strategy that identifies which problems matter most and which the organisation will not address, coaching of individual product managers, designers and engineers as an explicit and continuous management responsibility rather than an occasional review, and the willingness to accept decisions the leader would have made differently.
He is direct that most companies claiming to have empowered teams do not, and he identifies the tells: roadmaps of committed features with dates, teams that cannot change what they are building, product managers acting as project coordinators, and stakeholders directing teams around the product organisation.
The book is prescriptive and derived from Cagan's consulting practice rather than from research. It assumes a technology product company with dedicated engineering, design and product functions, and translates poorly to organisations that build software as a support function. The distinction between outcome and output is the transferable core.
Executives and product leaders in technology companies who want the leadership practices that outcome-oriented teams actually require.
Chosen by shared topics, the entries that hold them, and the people who recommended both.