Inspired by Marty Cagan: why everyone on a product team should think like a product owner
Key ideas from Marty Cagan's Inspired and a developer's take: why designers, engineers and everyone else on a team now need to think like product owners.
5 min read
I recently finished Inspired: How to Create Tech Products Customers Love by Marty Cagan. On paper it is a book for product managers. In practice, I think it is one of the most useful books anyone on a product team can read right now — designers, engineers, QA, and yes, product managers too.
Below are the ideas that stuck with me, followed by my own take as a developer.
The main ideas of the book
Most product ideas fail — and that is normal
Cagan's starting point is uncomfortable: a large share of the ideas we put on a roadmap simply won't work. Customers won't care, won't understand them, or the business can't support them. Even the ideas that do work usually need several iterations before they deliver real value.
The problem is not that teams have bad ideas. The problem is that many companies only find out an idea was bad after spending months building and launching it.
Why so many teams build the wrong things
The book describes a pattern that will feel familiar to anyone who has worked in a company with a feature roadmap:
- ideas arrive from executives, sales or big customers as a list of features;
- a product manager turns them into requirements;
- design gets involved late, mostly to "make it look nice";
- engineers see the work only when it is time to estimate and build;
- the first real validation happens at launch.
Teams call this Agile, but often only delivery is agile. Everything that comes before it is still a waterfall.
Discovery vs delivery
The core of the book is the split between product discovery — figuring out what is worth building — and product delivery — building it properly. Strong teams run both continuously and in parallel.
During discovery, a team tackles four big risks before writing production code:
| Risk | The question |
|---|---|
| Value | Will customers buy it, or choose to use it? |
| Usability | Can users figure out how to use it? |
| Feasibility | Can we build it with the time, skills and technology we have? |
| Viability | Does it work for the business — sales, legal, finance, brand? |
The tool for this is fast, cheap experimentation: prototypes of different fidelity, quick user tests, small live-data experiments. The goal is to learn which ideas deserve to become real products, in days rather than quarters.
Empowered teams solve problems, not feature lists
Cagan argues that the best results come from cross-functional product teams — a product manager, a designer and engineers — who are given a problem to solve and are accountable for the outcome, not for shipping a predefined list of features.
He uses John Doerr's distinction between missionaries and mercenaries: mercenary teams build whatever they are told; missionary teams believe in the vision and care whether the customer problem actually gets solved. Only the second kind consistently builds products people love.
Engineers are a source of innovation, not just code
One line from the book I keep coming back to: if you're just using your engineers to code, you're only getting about half their value. Engineers work with the technology every day and are often the best placed to see what has just become possible. Bringing them into discovery from the start is not a courtesy — it is where many of the best solutions come from.
Outcomes over output
Finally, the book pushes teams to measure success by business and customer outcomes rather than by how many features shipped. A roadmap full of delivered items means little if retention, conversion or revenue didn't move.
My take: everyone is a product owner now
What struck me most is that, although the book is written for product managers, almost every chapter applies to the whole team. And I think that is even more true today than when it was written.
The way we build software has changed. Roles have blurred. Small teams ship what used to need whole departments, and AI tools take over a growing share of routine work. In that world, every person on the team has to act, at least partly, as an owner of the product. Beyond doing their own job well, they need to notice — and often do — work in other areas, because the success of the project depends on it.
The days when a developer only developed are over. From my point of view as a developer, that is a really good thing.
When I understand why a feature exists, who it is for and how it affects the business, I make better technical decisions. I can suggest a simpler solution that delivers 80% of the value in 20% of the time. I can spot that a "small" change will quietly hurt usability or performance. I can push back on a feature that nobody has validated. None of that is possible if I only see a ticket with acceptance criteria.
So my conclusion is simple: regardless of the role — designer, developer, QA, analyst — each of us should learn to:
- think like a product manager — understand the user's problem, not just the task;
- understand the market — who the competitors are, what alternatives users have, why they would choose us;
- understand the business and investment side — how the product makes money, what it costs to build and run, why a given bet is worth funding.
That knowledge doesn't replace your core craft. It multiplies it.
Who should read Inspired
- Product managers — obviously; this is the book's main audience and a strong foundation for the role.
- Developers and tech leads — to see where your work fits in the bigger picture and how to have a real say in what gets built.
- Designers — to move from "drawing screens" to owning usability and value risks together with the team.
- Founders and managers — to understand what an empowered product team looks like and why feature roadmaps so often disappoint.
If you have to pick one book on how good product teams work, I'd start with this one.