What Melissa Perri and Marty Cagan are actually asking leaders to do
I watched a team get handed a solution and a deadline in a Quarterly Planning session, and then two months in, they were asked why they weren't being more innovative at a Sprint Review.
The leader asking that question was not being cynical, and I want to be clear about that, because the easy version of this story makes him the villain and the easy version is wrong. He cared about the product. He had been in that business for nineteen years and he knew things about the customer that nobody else in the building knew. He gave the team a solution because it was intuitive to him and because it had become his habit. And he thought he was saving them time and making the team more productive.
That's the thing about the build trap that I don't think gets said often enough. It's rarely built by people who don't care. It's usually built by people who care a great deal and express it in the only way anyone ever showed them: by staying close to the decisions.
Reading past Perri's title
Melissa Perri's Escaping the Build Trap is one of those books whose title did so much work that a lot of people never read past it. Everyone in product knows the phrase now. Fewer people can name the patterns underneath it, and the patterns are where the diagnostic value lives.
There are five, and I use them constantly:
The roadmap as promise. Once a roadmap is committed twelve or eighteen months out and treated as a contract, teams build what was promised rather than what the customer now needs. The roadmap stops being a plan and starts being a debt.
Output as progress. Velocity, story points, features shipped. All real numbers, all measuring the wrong thing, and all easier to put in a deck than the alternative.
Discovery as a one-time phase. Something you do at the front of an initiative and then stop doing, as though customers finish having new information about themselves the moment development starts.
Ideas without owners. Requests arrive from everywhere, get accepted, get built, and nobody is ever accountable for whether the idea was any good.
Success declared at launch. The party happens when the thing ships. Nobody comes back six weeks later to ask whether anything changed.
If you want the one-sentence version to hand a leadership team, though, I'd give them Josh Seiden instead. Outcomes Over Output is short enough to read on a flight and it makes one distinction impossible to unsee afterward: output is the thing your team makes, and outcome is a change in human behavior that produces value. A team can hit every commitment for four straight quarters and produce neither.
Actually empowering teams, the way Cagan meant it
Marty Cagan has written three books and I've noticed most leaders don't know which one they're supposed to read, so here's the sorting: Inspired is written for practitioners, Empowered is written for leaders, and Transformed is about the whole-company shift in how the business operates. If you're a senior leader and someone handed you Inspired because it's the famous one, you got the wrong book.
There's a smaller detail I like even more, because it tells you something about how Cagan thinks. He introduced the term "Dual-Track Agile" back in 2012, and then he deliberately backed away from it, because it had turned into a process that teams performed rather than a principle they understood. Teams were drawing two swimlanes on a board and calling it discovery. He gave up ownership of his own popular term rather than let it become theater. In my experience that instinct is rarer than it should be.
And then there's the distinction he's best known for, missionaries and mercenaries. Mercenaries build what they're told. Missionaries believe in the problem. You can usually tell which one you have inside about ninety seconds of a team talking about their work, and here's the uncomfortable part: which one you have is not a hiring outcome.
Where the two arguments meet
Here's where these two connect, and it's the argument I care most about.
Perri diagnoses the trap. Cagan describes what escaping it requires, which is empowered teams. But the phrase "empowered teams" has been beaten so thin that it now mostly means "we told them they're empowered." Cagan's actual definition is much more demanding, because it's three conditions held at the same time.
Authority over the how. The team decides the solution, not just the implementation of someone else's solution.
Context deep enough to use that authority well. Strategy, customer knowledge, business constraints, the economics. Authority without context is abandonment, and I've watched teams get "empowered" into paralysis because nobody gave them enough of the picture to make a real call.
Accountability for outcomes rather than output. Not "did you ship it" but "did it work, and how do you know."
Any one of those without the others fails, and it fails in a way that's specific enough to diagnose. Authority without context produces paralysis. Context without authority produces resentment; the team can see exactly what should happen and has no ability to do it. Accountability without either one is just blame with a nicer vocabulary.
Which brings me to the part that reinforces everything I've written about how organizations work. The absence of empowered teams is a leadership behavior problem sitting one part up in the system, and no amount of better framework at the team level will reach it. A team running any framework you like, under a leader who keeps handing down solutions, is a feature factory with better meetings.
David Marquet has the cleanest one-line restatement of Cagan's authority condition I know of: move authority to information, rather than moving information to authority. That's the whole thing. The information about what the customer needs lives closest to the team. Every escalation, every approval gate, every "run it by me first" is a decision to move that information upward instead, and each one is small enough to feel reasonable in the moment.
So look at your own last three conversations
I want to give you something you can do this week rather than a principle to agree with.
In your next product review, count the questions. How many were about what shipped, and how many were about what changed for a customer? Don't estimate it, actually count. That ratio will tell you more about where your organization sits than any maturity assessment you could buy.
Then pick one team and check it against the three conditions. Do they have authority over the how, context deep enough to use it, and accountability for an outcome? Not two of the three. Two of the three is where most organizations live, and it's the version that lets everyone believe the work is done.
And go back through your last three product conversations and ask how many times you described the solution versus described the problem. I've asked leaders to do this and the answers have surprised them, including the ones who came in confident. It's not a character test. It's a habit that forms because describing the solution is faster, and because you usually do have a good one.
The teams you're describing solutions to are learning something from that. They're learning that the thinking happens somewhere else.
One part of five
Product thinking is one of five parts of the Adaptive Organization Operating Model, and I think the reason so many of these efforts stall is that leaders pick one part, work it hard, and treat the other four as somebody else's problem. Strategy and outcomes. Product thinking and discovery. Flow of work and delivery. Team and org design. Leadership and culture. Each one gets built the same way, through leader behavior, because the environment leaders create is the operating model.
The shift in each of them is smaller than people expect. It's the questions you ask in a review, the things you celebrate in front of everyone, and the decisions you stop making. Small changes that create the space for teams to be successful.
Perri will tell you what's wrong and Cagan will tell you what good looks like. You're the one who has to catch yourself before you hand down another solution. Real product thinking starts with you.
This is part of a series on the voices behind Assembled. Aligned. Adaptive. The full treatment of product thinking lives in Part Two, and the reading list for these chapters is at adaptbook.co/go.