04 · Delegating Product Decisions¶
The single biggest capacity constraint on a new Product Lead is themselves — specifically, their habit of staying the final decision-maker on everything their old IC role used to touch. This module gives you a concrete tool for fixing that: a decision-rights map that makes explicit what each PM owns outright, what needs your input, and what stays with you.
The four levels of decision delegation¶
Not every decision should be delegated the same way — a useful ladder, from least to most delegated:
| Level | Name | What it means | When to use it |
|---|---|---|---|
| 1 | Tell | You decide, you inform the PM | Rare — reserved for company-mandated or crisis decisions |
| 2 | Sell | You decide, but explain your reasoning and take questions | Early in a new PM's ramp-up, or high-stakes/low-reversibility calls |
| 3 | Consult | PM decides, after getting your input | Most decisions for PMs who are ramped but still building judgment |
| 4 | Delegate | PM decides fully; tells you after (or not at all for small calls) | Default for a PM's core roadmap once they've earned trust |
The goal over time is to move every recurring decision type as far down this ladder as the PM's track record supports — staying at "Tell" or "Sell" for everything is the Bottleneck trap from Module 2.
Decision-rights map template¶
| Decision type | Owner | Decision level | Notes |
|---|---|---|---|
| Feature prioritization within their roadmap | PM | Delegate | Lead reviews roadmap monthly, not per-decision |
| Cutting scope to hit a deadline | PM | Delegate | As long as they flag it in the weekly sync |
| Hiring/firing a squad's engineers | Eng manager, not PM or Lead | N/A | Not a product decision — listed to avoid ambiguity |
| Changing the squad's core metric | PM + Lead | Consult | Metric changes affect how the team's ladder-up story reads |
| New headcount request | Lead | Consult (with Head of Product) | Budget impact goes beyond one squad |
| Killing/pivoting an initiative >1 quarter of work | Lead | Sell | High cost of being wrong; PM should be part of the call, not just informed |
| Pricing or legal/compliance-adjacent decisions | Lead + relevant exec | Tell | Genuinely outside PM/Lead authority in most orgs |
Worked example: building the map for a real team¶
When Amara becomes Product Lead for a 3-PM logistics team, her first sign of the Bottleneck trap is that all three PMs Slack her before changing anything in their sprint scope — even trivial re-sequencing. In her second week, she runs a 45-minute working session with the team and drafts a decision-rights map together (not alone — buy-in matters more than precision here). The two decisions that generate the most discussion: "should PMs be able to unilaterally change their squad's north-star metric?" (the team lands on Consult, since metric changes ripple into how Amara reports up) and "who decides if a squad picks up unplanned urgent work?" (the team lands on Delegate up to 1 day of unplanned work per week, Consult above that). She posts the finished map in the team's shared doc and references it explicitly the next time a PM starts to ask permission for something already marked Delegate — redirecting them back to their own authority is itself part of teaching the delegation.
Cheat sheet — signs you're over- or under-delegating¶
| Signal | Likely means | Fix |
|---|---|---|
| PMs Slack you before small, reversible calls | Under-delegating, or the map isn't visible/known | Publish and reference the decision-rights map |
| You're surprised by a decision after the fact, and it was costly | Over-delegating a decision that needed Consult | Move that decision type up one level |
| A PM says "I didn't know I could just decide that" | Delegation happened in your head, not out loud | Write it down; delegation isn't real until it's explicit |
How It Actually Works¶
Delegation fails or succeeds based on a single design choice most leads never make explicit: what happens when the PM gets it wrong. If a wrong call from a PM results in the lead quietly fixing it and saying nothing, the PM never learns where their judgment miscalibrated, and the lead learns (incorrectly) that this PM "can't be trusted" with that decision type — so the lead delegates less next time, not more. If a wrong call results in visible blame in front of stakeholders, the PM starts escalating everything preemptively to avoid being wrong alone, which collapses delegation from the other direction. The mechanism that actually builds delegation capacity is a safe-to-fail boundary: decisions are explicitly bucketed (by reversibility and blast radius) into "just do it," "do it and tell me," and "check with me first" — and the lead commits, in front of the team, not to relitigate a wrong call that fell in the first two buckets. That commitment is what makes PMs actually take the decisions rather than performatively taking them while still shadow-checking with the lead. Without it, "I've delegated this" and "the PM still runs everything by me first" look identical in a status meeting but are completely different in practice — the tell is whether the PM's Slack messages to the lead are informational ("here's what I decided") or permission-seeking ("is this okay?").
Exercise¶
Build a decision-rights map (using the template above) for a team of 3 PMs — real or hypothetical. Include at least 8 decision types spanning prioritization, scope, hiring-adjacent calls, metrics, and one clearly out-of-scope decision (to practice drawing boundaries, not just delegating). For each, assign an owner and a level (Tell/Sell/Consult/Delegate) and write one sentence justifying the two decisions you found hardest to place.