moving fast is cheap now. knowing what's actually ready to move fast, and protecting everything that isn't, is still the product leader's job.
product teams have two decisions they consistently conflate: should we build this, and how fast can we build it. AI has made the second feel obvious. it has not changed the first.
product pacing zones separates these two decisions and gives teams a shared language for both. zone 1 work moves without ceremony. zone 4 work moves without shortcuts. nothing gets misclassified because the pressure was high.
three gates, one question each.
gate 1 · confidenceis this worth building? four questions, one for each dimension of risk. if any one is shaky, find a zone 1 test, not a production ticket.
gate 2 · pacewhat kind of work is this? classify the surface, name the clearance condition, and set the pace.
gate 3 · proofdid the behavior change we predicted actually happen? shipping is a hypothesis. gate 3 is the proof.
before classifying any work, run the readiness diagnostic. it takes five minutes and tells you whether your team is set up to actually run this.
run the readiness diagnostic →AI has created a leadership expectation problem. executives see what is possible in a sandbox and project that velocity onto the real product with real users and real stakes. resetting that expectation is now part of the product leader's job.
the most practical claim in this framework sits inside zone 1. when a surface has no external dependencies, no compliance exposure, and a clear owner, a PM sketches it in the morning and an engineer ships it the same day. anyone with the skill, AI-assisted or not, can own it end to end.
no committee. no hand-off theatre. no manager approval on a tooltip.
this isn't speed for its own sake. it's what product work looks like when context is clear, stakes are low, and the zone system is trusted enough to stay out of the way. most of the gains from AI-assisted development live here. protecting zone 1 from ceremony is the product leader's most undervalued job right now.
zone 4 is the counterweight. compliance, payment, legal. no design before review, no shortcuts, every step deliberate. the same framework that lets zone 1 move without ceremony refuses to let zone 4 move without clearance. the tension is the point. without both poles held honestly, "move fast" quietly eats the rest of the product.
the vocabulary. each zone is a pace and a clearance -- the condition that must be met before work in that zone ships. the spectrum above maps where each falls on the risk gradient. click a card for the full rule.
no external dependencies. anyone with the skill, AI-assisted or not, can own this end to end. a PM sketches it in the morning, an engineer ships it the same day.
design and engineer in parallel. slow here is a context problem. the context wasn't clear enough to move without stopping to ask. improve the context before diagnosing the workflow.
zone 1 can still have real users. the stakes are just lower and the feedback loop is the safety net.
whoever is shipping it. no committee, no manager approval. the person doing the work owns the clearance.
zone 1 work ships as a labeled preview by default. a preview is not a soft launch. it is a deliberate posture: real users, real feedback, lower stakes than the full surface. if a zone 1 feature goes straight to GA without a preview period, that is a documented choice, not a default.
a technical or contractual blocker: something no one on your team can unilaterally resolve. an API contract not finalized, a system hand-off pending, a data source not yet available.
design the full surface now while you wait. a named reviewer must clear before staging.
if the only thing blocking you is a stakeholder opinion you could force in a meeting, that's zone 1 with a missing decision. if the blocker hasn't resolved in 14 days, re-evaluate for PDVF.
one important constraint: the dependency blocks engineering, not learning. keep running zone 1-style discovery on the questions you can still answer. if research has gone quiet because the build is paused, the dependency is being used as an excuse.
the named reviewer, designated at kickoff. one person, named in advance. not a group sign-off, not whoever is available that day.
vendor or integration unconfirmed. build the container and placeholder states. no internal design decisions, no internal business logic until the dependency resolves.
do not guess how the vendor API will work and build around the guess. you can sketch the edges of the room without furnishing it. just do not start picking paint colors until you know the walls are staying.
the PM or tech lead who owns vendor confirmation. they say "contracted and integrated" -- that is the clearance event. no one else can call it.
compliance, payment, or legal surface. no design before review. every step deliberate and documented. when uncertain, default here.
if work is in a legitimate external review queue (legal, compliance, procurement), that wait is the process working. the clearance event, not a deadline, is what moves it.
legal or compliance. not the PM, not the CPO. the clearance belongs to whoever holds the regulatory accountability. if that person has not signed off, the zone has not changed.
zone 4 isn't a choice to slow down. it's an acknowledgment that the risk already exists. the framework makes it visible so it stops being a surprise.
before anything gets a zone, you need a read on four dimensions of risk. each is a separate confidence call: the problem can be real while your solution is wrong; the solution can be wanted while the business case breaks.
here is the honest part. you cannot fully prove any of these before shipping. Problem and Feasibility can be substantially derisked pre-build through research and spikes. Desirability and Viability can only be approximated. they only surface once people interact with the thing at real stakes.
so gate 1 is not a filter you pass. it is a way to locate your weakest link and shrink it to a level where shipping to learn is cheaper than waiting to be sure. any dimension still shaky becomes a zone 1 experiment, not a production ticket.
the speed default: when any PDVF check is uncertain, the output is not a gate review. it is a zone 1 experiment spec. one question, one owner, one timebox. that is the documented default, not an implied option. a team that holds a meeting every time PDVF is shaky has misread the gate.
gate 1 gives you evidence. gate 3 gives you proof. shipping is how PDVF actually gets tested — the validation toolkit below has the pre-ship tests, mapped by dimension.
answer four questions to classify a surface. compliance and legal exposure is always the first check. if it exists, the zone is 4 regardless of everything else. that risk cannot surface mid-sprint.
if you select "not sure" on any question, the framework defaults to the more conservative zone. the goal is not to stay there; it's to force the conversation that moves you out of it.
who owns each piece, what the inputs and outputs are, where the dependency hand-off happens. if the answer is "not sure," that is the constraint to resolve before classifying.
no external dependencies means no clearances. anyone with the skill to build it can own it: designers with AI coding tools, PMs who can prototype, engineers who can move without ceremony.
this is where the AI speed gains are real. design and engineer in parallel, ship without ceremony, learn in the open.
if you're moving slowly on a zone 1 surface, the first question is context quality, not process. thin context forces the builder to stop and ask. improve the context before diagnosing the workflow.
a technical or contractual blocker is in play: something no one on your team can unilaterally resolve. an API contract not finalized, a system hand-off pending, a data source not yet available.
design the full surface now so you're ready the moment it clears. designate a named reviewer before anything goes to staging.
if the only thing blocking you is a stakeholder opinion you could force in a 30-minute meeting, that's zone 1 with a missing decision, not zone 2. if the dependency hasn't moved in 14 days, re-evaluate for PDVF.
the dependency blocks engineering, not learning. keep running zone 1-style discovery on the questions you can still answer. if research has gone quiet because the build is paused, the dependency is being used as an excuse.
compliance, payment, or legal surface. design does not start before review. every decision is deliberate and documented.
when in doubt, this is always the right zone. legal or compliance sign-off moves this surface down to zone 3 or zone 2 depending on what else is open.
classified your work? check if your org is ready to run this before it hits the team.
pick the next item going into your sprint. run it through the classifier before writing a single ticket. if the zone surprises you, that's the conversation to have before scoping starts.
shipping is a hypothesis. gate 3 is the proof.
work is not finished when it hits production; it is finished when the behavior change predicted at gate 1 actually happens, or conclusively does not. at gate 1, the team names a signal target alongside the predicted change: what evidence would convince them, in what population, at what threshold. gate 3 fires when that target is met, conclusively missed, or the zone cap runs out, whichever comes first.
unlike gates 1 and 2, gate 3 is retrospective. it forces the team to look at shipped work through the lens of impact. if the signal is weak, the work does not just sit in the product. it gets refined, pivoted, or removed.
AI lets teams fill a product with features at record speed. without gate 3, the result is a feature factory: a growing collection of zone 1 ideas that shipped fast and solved nothing. gate 3 is the governor. speed without measurement is just expensive noise.
the right wait depends on the test, not just the zone. a 5-user concierge MVP gives a verdict in days; a preview rollout to 5% of a 30M-user product might genuinely need two weeks to hit statistical confidence. both can be zone 1. the work isn't more or less important; the signal model is just different.
a review is not a meeting. it's a runnable sequence. the loop:
three tiers for what the review turns up, based on how conclusive the signal is. these reuse the same logic from the validation toolkit below, applied after ship instead of before. a "pass" moves the feature to stable core product and standard monitoring.
pick three features that shipped in the last two sprints. for each one, answer: what behavior were we trying to change? did it change? if you can't answer the first question, you skipped gate 1. if you can't answer the second, you skipped gate 3.
zones move when conditions change. some surfaces migrate down once a clearance is met. others permanently live in zone 2, 3, or 4 because that's the work. movement up requires no approval. anyone can name new risk. the asymmetry is intentional.
push work toward zone 1 as far as it goes. whatever stays in zone 2, 3, or 4, stack zone 1 experiments to test the assumptions underneath.
small bets earn the right to make bigger ones. this is where assumptions mapping, testing business ideas, and lean ux live.
think about a surface your team has been stuck on. is it actually blocked, or has the zone just never been named? if no one can say who owns the clearance or what has to happen for it to clear, that's the gap.
copy this into a ticket or doc to classify a surface in context.
| signal | zone |
|---|---|
| no external dependencies. self-contained. anyone with the skill can build it. | zone 1 |
| depends on upstream data or another team, but no compliance exposure. | zone 2 |
| vendor unconfirmed. integration design unknown. shell is safe, internals are not. | zone 3 |
| touches payment, fair housing, adverse action, legal disclosure, or consent. | zone 4 |
| uncertain. could touch compliance. | zone 4 until confirmed |
the zone is driven by signals, not surface type. use these as calibration. the same work can classify differently depending on what is actually true about your context right now.
moving up requires no approval. any team member can name the risk. moving down requires a named clearance event and documentation.
escalate on risk signals, not on discomfort. if everything is landing in zone 4, the problem is culture, not classification.
assign a person. if the zone card says "named reviewer" and no one in the room can name the reviewer, the clearance does not exist yet. a role is a placeholder. a person is accountable.
who made the call, what they cleared, and when. one person makes the call. it gets documented. it is not a group default and not assumed.
as a surface matures, adjacent risk accumulates: pricing logic, consent flows, downstream dependencies.
re-classify when the surface changes, not when something breaks. re-classification is a 30-second logic check, not a meeting. it protects zone 1's speed by keeping zone 4 risk from quietly accumulating inside it.
re-triage is triggered by: a ticket that adds scope not in the original classification, a new dependency (team, system, or vendor), any data write that wasn't in the original surface, or 30 days of active development without a re-check.
the compliance review is zone 4. the UI shell around it may not be. identify which parts of the surface carry the risk; only those pieces move at zone 4 pace. the rest does not have to wait.
the connection points between fast and slow scopes default to the higher zone.
if a zone 2 dependency has not resolved in 14 days, re-evaluate for PDVF. a dependency that never closes is a signal, not a clearance.
either the work lost urgency or the problem was never as clear as it looked. either way, the zone should be questioned, not extended.
a dependency that stops your build does not stop your discovery. while you wait, keep running zone 1-style experiments on the questions you can still answer: user behavior, concept tests, low-fi prototypes, assumption checks.
if research has gone quiet because engineering is paused, that is not the dependency's fault. do not let waiting become passive.
if authority overrides the classification, document who made the call, which check was skipped, and why.
forced classification is a deliberate choice, not a shortcut. the gap it creates does not disappear; it just moves to later, when it costs more.
every ticket that clears gate 2 gets a scheduled gate 3 review. the review date is set by how long it takes to know if the feature worked. some features need 48 hours, others need a full sprint cycle. the cap matches the zone: 14 days for zone 1, 30 for zone 2, 60 for zones 3 and 4.
if a feature fails to meet its outcome target at gate 3, it automatically triggers a re-evaluation of PDVF. the failure is almost always a signal that P wasn't as real as assumed, or D didn't actually address it.
the "did it work?" review also updates seam. run /gate3-review and the output tells you what changed and what to update in the shared background. one person reviews and approves before anything is written.
a review that produces nothing to update is a flag. something was learned. if there's nothing to update, explain why in the ticket.
a first redirect resets the gate owner and the 14-day window. a second redirect does the same. a third redirect is not permitted.
after two redirects, the surface triggers a formal go/no-go. bring the full artifact: original classification date, dependency description, gate owner history, zone 1 work completed during the hold, engineer-weeks spent waiting. one output: commit or kill.
if there is no meaningful zone 1 work available while the dependency is unresolved, name that in the escalation. "the team has no high-value path while this waits" is a stronger artifact than "experiments are running."
when a surface moves zones, the clearance event is documented at the moment it happens: who cleared it, what they cleared, and the date. the format is a single line in whatever system the team uses for tickets (linear, jira, notion, github comment):
a clearance that exists only in someone's memory is not a clearance.
bring this to your next planning session with one surface already classified. run it through the zone classifier before the meeting. don't explain the framework first -- just say "i think this is zone 2 because the API contract isn't signed yet. that means we can design the full surface now, but staging waits on their clear." if the zone is right, the conversation moves. if it's wrong, that's the conversation worth having. the framework earns trust one surface at a time, not in a rollout.
PDVF not holding? use this to figure out what to test first. test types drawn from David J. Bland's Testing Business Ideas. required reading, should live on every product manager's desk.
pull up your current roadmap. find the items with no external dependencies, no compliance exposure, and a clear owner. those are zone 1 today. if they are not moving, that is a process problem, not a prioritization problem.
three Claude Code skills that run the three gates. drop them into any project and invoke them with a slash command.
if this framing is useful, quiet branches labs works with teams that want to operate this way.
quiet branches labs