quiet branches labs
ways of working
pacing

product pacing
zones

moving fast is no longer the hard part. knowing what is actually ready to move fast, and protecting everything that isn't, is the product leader's job now.

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.

4 zones. Zone 1 work moves quick and without ceremony. Zone 4 work moves without shortcuts. Transparency helps everyone ensure nothing gets misclassified because the pressure was high.

two gates. the first checks confidence: is 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. the second checks pace: how fast can you build it, and what has to clear before it ships. run both.

the risk spectrum

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.

greenfield / move fast core product / move slow
zone 1 move fast product, design, eng, analytics. if you hold the context, you can ship it.
zone 2 design first dependencies open, named reviewer required
zone 3 shell only vendor unconfirmed, internals blocked
zone 4 move deliberately compliance, legal, payment. no shortcuts.
the AI expectation trap
sandbox speed is real. but sandbox stakes are zero. the further right on this spectrum, the wider that gap gets. name it early with your leadership team.
where the speed gains are real
Zone 1 is where AI changes the calculus. anyone with the skill (designer, PM, founder) can ship it. the framework's job is to make sure speed is calibrated, not assumed.
gate 1: the PDVF filter

before anything gets a zone, it needs to survive four questions. not gut checks. evidence tests. each one 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. any one failure means you need a test, not a production ticket. run that test in Zone 1. when the signal clears, re-enter the filter. PDVF is a directional confidence check, not a binary gate. early-stage work will have weaker signal; that's expected. what matters is knowing which check is your riskiest assumption and running at it.

P
problem
is the pain real and validated? evidence that users experience this struggle. not an assumption, not a proxy metric.
D
desirable
does your specific solution address that pain? the problem can be real and your solution still wrong. these are separate questions.
V
viable
does the business model hold? a feature users love that can't be monetized or operated at scale is still a failed bet. revenue model, margins, operational capacity, and any legal exposure that could block shipping all need to hold.
F
feasible
can this team build it now? not eventually, not with more resources. with current skills, dependencies, and capacity. "probably" is not a pass.
stronger evidence is evidence that cost the customer something to produce. a quote is easy; a behavior is harder to fake. use the signal tiers as a prompt: if everything you have is frictionless, you probably need more of it.
gate 2: find your zone

answer three 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.

zone classifier

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.

question 1 of 3
does this surface touch payment, legal disclosure, compliance, or adverse action?
question 2 of 3
is the vendor or integration for this surface confirmed and contracted?
question 3 of 4
does this feature rely on data or functionality that another team or system provides?
question 4 of 4
can your engineer explain the data flow for this feature in 60 seconds?

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.

zone 1 move fast
no external dependencies means no gates, and no gates means anyone with the skill to build it can own it. that includes designers with AI coding tools, PMs who can prototype, and 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, ask why.
gate: internal review only
if any PDVF check failed before you ran the classifier: document the override: who authorized it, which check was skipped, and why. the zone is assigned. the gap is not closed.
zone 2 design first
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. 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. designate a named reviewer before anything goes to staging. if the dependency hasn't moved in 14 days, re-evaluate for PDVF.
gate: named reviewer must clear before staging
if any PDVF check failed before you ran the classifier: document the override: who authorized it, which check was skipped, and why. the zone is assigned. the gap is not closed.
zone 3 shell only
vendor or integration not yet confirmed. build the container and placeholder states. make no internal design decisions until the dependency is resolved. when the vendor is confirmed and contracted, this surface moves to Zone 2.
gate: vendor + integration confirmed
run a spike first technical questions are open
before assigning a zone, timebox 1-3 days to answer the hardest technical question. who owns each piece? what are the inputs and outputs? where is the hand-off? if those can't be answered clearly, feasibility has not passed PDVF. do not let the classifier run ahead of the "how."
next step: technical spike before zone is assigned
zone 4 move deliberately
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.
gate: legal or compliance sign-off
how work moves

zones are not permanent. work moves down when gates clear. work gets escalated up when new risk surfaces. the asymmetry is intentional.

1
move fast
2
design first
3
shell only
4
move deliberately
→ escalation is automatic. any team member can name a new risk and move a surface up. no meeting required. when in doubt, go up.
← de-escalation requires a named gate event. who cleared it, what they cleared, and when. one person makes the call, not consensus, not default.
4 → 3 or 2
legal or compliance sign-off obtained. document the reviewer, the date, and the scope of clearance.
3 → 2
vendor contracted and integration design confirmed. shell becomes a real surface.
2 → 1
named reviewer clears. all technical and contractual dependencies resolved. if the blocker has been open more than 14 days without movement, re-evaluate for PDVF before proceeding.
four zones
zone 1
move fast
tap to read
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 process problem, not a safety measure. Zone 1 can still have real users. the stakes are just lower and the feedback loop is the safety net.
gate: internal review only
zone 2
design first
tap to read
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.
gate: named reviewer must clear
zone 3
shell only
tap to read
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.
gate: vendor + integration confirmed
zone 4
move deliberately
tap to read
compliance, payment, or legal surface. no design before review. every step deliberate and documented. when uncertain, default here.
gate: legal or compliance sign-off

Zone 4 surfaces require greater certainty before you build. the way you get there is by reducing risk early. run Zone 1 experiments to validate the problem and the demand before you are deep in a compliance-gated build. by the time the hard work starts, you should already know it is worth doing.

quick reference

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
examples

three surfaces classified. use these as calibration for your own work.

new onboarding tooltip sequence
self-contained. no external dependencies. a PM or designer can own it end to end.
zone 1
if it needs manager approval before it ships, Zone 1 is not actually in use.
adding Apple Pay at checkout
touches payment processing. compliance and legal exposure is direct and non-negotiable.
zone 4
the UI shell can start. the payment logic does not move until legal review clears and is documented.
analytics dashboard (new data source)
depends on a data pipeline owned by another team. no compliance exposure, but blocked on a handoff.
zone 2
a named reviewer must clear before staging. if the dependency has been open 14 days, re-evaluate for PDVF.
operating rules
01
when in doubt, escalate. moving up requires no approval. any team member can name the risk. moving down requires a named gate event and documentation. escalate on risk signals, not on discomfort. if everything is landing in Zone 4, the problem is culture, not classification.
02
Zone 1 moves without ceremony. if a surface is Zone 1, let it move fast. adding process to Zone 1 work is waste, not safety. this requires leadership to protect it. if every Zone 1 ticket needs manager approval, the zone no longer exists.
03
Zone 3 surfaces get containers, not decisions. no internal logic until vendors and integrations are confirmed.
04
Zone 4 does not start without a review gate. if design begins before compliance review, you are explicitly accepting the risk of late-stage rework. that is a choice, not a shortcut.
05
gates are before staging, not after. a reviewer assigned after shipping is not a gate.
06
every gate has a named owner, not a named role. assign a person. a zone without a named person is not a gate.
07
moving down is a documented event. 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.
08
Zone 1 does not stay Zone 1 forever. 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.
09
Zone 4 can be scoped down. 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.
10
Zone 2 gates have a shelf life. 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 gate. either the work lost urgency or the problem was never as clear as it looked. either way, the zone should be questioned, not extended.
11
forcing a zone bypasses PDVF, not the risk. 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.
validation toolkit

PDVF not holding? use this to figure out what to test first. test types drawn from David J. Bland's Testing Business Ideas.

evidence builder
which part of PDVF are you least confident about?
problem validation test the pain before the solution
you need evidence the problem is real and widespread before anything else. pick the test that fits your current access to users.
discovery interviews
talk to 5 people who should have this problem. don't pitch a solution. ask about current behavior, workarounds, and what it costs them. if you can't find the pain without leading, the problem may not be real.
statedsignal: 3 of 5 describe the same pain unprompted
day in the life
observe a user doing the thing you think is broken. watch without intervening. the gap between what people say in interviews and what they actually do is where the real problem lives.
behavioralsignal: you see the workaround happen in real time
problem survey
send a short survey to 20-50 people in your target segment. ask about frequency, severity, and current workarounds. use it to confirm that the pain from interviews is representative, not anecdotal.
statedsignal: 60%+ report the pain as frequent or severe
when the signal holds, PDVF holds. run the zone wizard.
desirability validation test whether users want this solution
the problem can be real and your solution still wrong. watch behavior, not stated preference.
concierge MVP
manually deliver the value proposition before building anything. do the thing by hand for 3-5 real users. if they come back, the solution is wanted. if they don't, you learned something fast and cheap.
behavioralsignal: users return or ask when it will be available again
prototype test
build the simplest version you can show: paper, clickable, or wizard of oz. run 3-5 sessions. watch what they do, not what they say. if they reach for it without prompting, desirability holds.
behavioralsignal: users engage with the core interaction without coaching
fake door test
offer the thing before it exists. a button, a nav item, a sign-up flow that leads to a waitlist. measure who reaches for it and how often. don't build the room until you know people will walk through the door.
behavioralsignal: click-through rate clears your baseline conversion threshold
when the signal holds, PDVF holds. run the zone wizard.
viability validation test whether the business case holds
users wanting something and the business being able to sustain it are different questions. get a demand signal before engineering commits.
pre-sale or letter of intent
ask someone to pay, commit, or sign before you build. a verbal yes is an assumption. a written LOI or a charged card is evidence. the threshold is not perfection. it's a real signal from a real stakeholder.
behavioralsignal: at least one committed buyer or signed LOI
pricing page test
show a real pricing page with real numbers. measure how far people get before they drop. where they stop tells you more than what they say. if no one reaches the buy step, the price or the value prop is broken.
behavioralsignal: conversion rate at your target price point clears internal benchmark
data pull
before building a new surface, check what the existing data says. usage logs, support tickets, churn reasons. if the business case can be confirmed or killed with data you already have, pull it before running a live experiment.
statedsignal: existing data confirms the revenue or retention impact
when the signal holds, PDVF holds. run the zone wizard.
feasibility validation test whether the team can build it now
feasibility is not just technical. it's time, capacity, and dependency. name the hardest constraint and test it directly.
technical spike
timebox it. 1-3 days max. the spike has one job: answer the hardest technical question. if it can't be answered in that box, the constraint is real and needs to surface before scoping begins.
behavioralsignal: clear answer. yes we can, or here is the real constraint
proof of concept
build the minimum working piece, not the feature, just the mechanism. if the core technical claim can be proven in isolation, the build is feasible. if the POC fails, you found the constraint early instead of mid-sprint.
behavioralsignal: the mechanism works end-to-end in a controlled environment
expert interview
talk to someone who has built this before, inside the team or outside it. a 30-minute conversation with the right person can surface constraints that a two-week spike would eventually uncover. use it to calibrate, not to replace the spike.
statedsignal: no new blockers after the conversation, or blockers are now named and scoped
when the signal holds, PDVF holds. run the zone wizard.
try this

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.

product pacing zones
quiet branches labs
move fast move deliberately
zone 1 move fast
zone 2 design first
zone 3 shell only
zone 4 move deliberately
zone 1
move fast
no external dependencies. if you hold the context, you can ship it. design and engineer in parallel.
gate: internal review only
zone 2
design first
technical or contractual blocker in play. design the full surface now. named reviewer clears before staging. re-evaluate for PDVF if the blocker is open past 14 days.
gate: named reviewer sign-off
zone 3
shell only
vendor or integration unconfirmed. build the container. no internal design decisions, no internal business logic until the dependency resolves.
gate: vendor + integration confirmed
zone 4
move deliberately
compliance, payment, or legal surface. every step deliberate and documented. when uncertain, default here.
gate: legal or compliance sign-off
moving up
escalation is automatic. any team member can name a new risk and move a surface up. no meeting required.
moving down
de-escalation requires a named gate event. one person makes the call. it gets documented.
when in doubt, go up. escalate on risk signals, not on discomfort. if everything is Zone 4, the problem is culture, not classification.
gates are before staging, not after. a reviewer assigned after shipping is not a gate.
Zone 1 requires leadership protection. if every Zone 1 ticket needs manager approval, the zone no longer exists.
Zone 1 does not stay Zone 1 forever. re-classify when the surface changes, not when something breaks. re-classification is a 30-second logic check, not a meeting.
Zone 4 can be scoped down. only the parts that carry the risk move at Zone 4 pace. the rest does not have to wait. connection points between fast and slow scopes default to the higher zone.
forced classification does not close the gap. if authority overrides PDVF, document who, what was skipped, and why.
quiet branches labs
quietbrancheslabs.com
cheat sheet
one-page reference for the framework. zones, gates, and key rules on a single page.

not sure if your org is ready to run this? check before you start.

run the readiness diagnostic

if this framing is useful, quiet branches labs works with teams that want to operate this way.

quiet branches labs
© 2026 quiet branches labs
product pacing zones