Empowerment Without Anarchy
Leaders place the bets; teams figure out how to win them. Neither top-down nor bottom-up.
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 93%
Cagan resolves the most common misunderstanding about empowered product teams: empowerment does not mean teams choose what to work on. Leaders own product strategy and place the bets; teams own solving the problems inside those bets. Both a feature roadmap (leaders over-specifying the solution) and self-directed teams (leaders abdicating strategy) are failure modes. The correct frame is not top-down vs bottom-up but 'each group doing its job'.
Origin
Marty Cagan (SVPG). Prompted in this episode by Lenny's interview with Meta's CTO, who described Meta as far more top-down than outsiders assume; Cagan reframes that description as leaders and teams each doing their proper job.
Core principles
- 01Product teams do not do product strategy — product leaders do.
- 02Handing a team a roadmap of features is the most top-down act there is.
- 03Letting 50 teams decide what to work on gives you 50 unrelated things — anarchy.
- 04Latitude is granted at the solution layer, not the problem-selection layer.
- 05It is not enough for teams to do their job; leadership must do theirs — and vice versa.
How to run it
- 1
Leaders produce a real product strategy
Product leaders decide which problems matter — the bets the company is placing this cycle. This is the leadership job and it cannot be delegated to the teams or to product ops.
Pro tip Most companies do this in annual planning; the test is whether the output is a set of problems/bets or a list of features.
Watch out If leaders skip this and call it 'empowerment', teams will fill the vacuum with disconnected local bets.
- 2
Hand each team problems, not solutions
Give each team one or two hard customer or business problems per quarter (on top of keep-the-lights-on work), stated as problems with a measure attached — not as a designed feature with a date.
Watch out A 'problem' that names the solution in its title is a feature in disguise.
- 3
Give real latitude on the solution
Let the cross-functional team (PM, designer, tech lead) do discovery and determine the best way to solve the problem. This requires the team to actually have the competencies — otherwise latitude produces poor solutions and leaders take the authority back.
Pro tip Cagan's read of Facebook: strong cross-functional teams with serious engineers, PMs and designers who could solve very hard problems — that is what made them good.
- 4
Measure the outcome, not the shipment
Hold the team to whether the problem moved. Instrument the release so the outcome can be demonstrated rather than argued about.
- 5
Coach, don't police
The product leader's second job is coaching the people in the team. If the only lever leadership uses is the roadmap, you have reverted to a feature team regardless of what you call it.
In the wild
Lenny had assumed Meta was bottom-up; its CTO described it as top-down — Zuck and the execs set strategy and big bets. Cagan says this is exactly what strong product companies do, and refuses the top-down label: the leaders placed the bets, and the teams were given real latitude to figure out how to solve them.
→ The apparent paradox dissolves — strategy from the top, solutions from the teams, and neither label (top-down or bottom-up) describes it.
When a team lacks a product manager who carries the business constraints — compliance, legal, sales, monetization — but is nominally 'empowered', its way of making a decision is to call a meeting with twenty stakeholders.
→ Cagan's verdict: you have reverted to design by committee. Empowerment without the competencies is not empowerment.
Common mistakes
Reading empowerment as 'teams pick their own work'
That produces 50 teams doing 50 unrelated things. Empowerment means the leaders come up with the bets and the teams are able to figure out the best way to solve those problems.
Agile coaches misdefining who owns strategy
Cagan blames a widespread misunderstanding, propagated by agile coaching, that product teams should generate product strategy. They should not; product leaders must.
Empowering teams that lack the four competencies
Latitude handed to a team without a real PM, designer, and tech lead yields either guessing or committee design, which then discredits empowerment itself.
Is it for you?
Best for
Heads of product and executives who have declared teams 'empowered' but are getting either chaos or disguised feature roadmaps
Not ideal for
Early startups where the founder is legitimately the product person and there is no strategy layer to separate
From the transcript
“product teams don't do product strategy product leaders do product strategy”
“empowerment does not mean you set up this product team and they go decide what to work on”
“handing a team a road map of features that's very top down”
“I frame that as product leaders doing their job and product teams doing their job”
“what they usually do is they call meetings with 20 stakeholders all in a room to try to decide these things and now you've reverted…”
From the episode
Product management theater
Marty Cagan (Silicon Valley Product Group)