Books I've read, revisited or found useful — from product management and design to behavioural science and technology. No star ratings: for each one, why I'd recommend it and what I took from it.
Product
Marty Cagan
How product teams discover and build things customers actually want — the discovery side of product work rather than the delivery side.
Why I recommend it. It gave me the vocabulary to separate discovery from delivery, and to argue for it. The part that stuck is that a roadmap of features and a roadmap of outcomes are not the same document, and that most of the risk sits before a single line of code is written.
Product
Don McGreal & Ralph Jocham
Product ownership framed around value rather than around the backlog: what the role is for, and what it degenerates into when the value question goes missing.
Why I recommend it. Because it makes the point that ownership is not administering a backlog. It pushed me to be far more explicit about value, about who the stakeholders actually are, and about which decisions are mine to make — rather than letting the role collapse into grooming tickets.
Behaviour & psychology
Daniel H. Pink
What actually motivates people at work — autonomy, mastery, purpose — and why incentives often produce the opposite of what they promise.
Why I recommend it. Most of my work happens without formal authority, across teams that don't report to me. This book explains why pressure and incentives are the weakest levers available, and why context and purpose do the work instead.
Behaviour & psychology
Richard H. Thaler & Cass R. Sunstein
How defaults, framing and small frictions shape decisions — the book that made choice architecture a thing you design on purpose instead of by accident.
Why I recommend it. It reframed defaults as a design decision rather than a technical leftover. Once you see that every empty state, preselected option and extra click is already steering someone, you stop treating those choices as neutral.
Design & strategy
Osterwalder, Pigneur, Bernarda & Smith
A working method for connecting what you build to what someone is actually trying to get done — and for noticing when the two have drifted apart.
Why I recommend it. It is the most practical of the strategy books I keep going back to: a method, not a manifesto. I use it as a periodic check that what a team is building still maps to a job someone is trying to get done, because that link erodes quietly.