Ship, Block, or Defer: The Decision Queue Every Head of Product Needs

The "Everything Is In Progress" Problem

Heads of Product at Series A and B companies share the same hidden failure mode: the roadmap has no decisions in it — only intentions.

• Items are "prioritized" but never formally approved for engineering
• Low-priority items are "deprioritized" but never removed — they linger
• Blocked items sit in limbo with no owner responsible for unblocking them
• New requests arrive weekly and get added without anything being dropped
• The backlog grows but never shrinks

The result: engineering works on 12 things simultaneously. Nothing finishes. The founder asks "why are we so slow?" and the Head of Product shows a board full of items that are all "in progress."

What Is a Decision Queue?

A Decision Queue is a structured gating system that forces an explicit decision on every roadmap item before it enters engineering. It has three states:

Ship

The item has passed all gating criteria. Engineering is authorized to start.

SHIP criteria:
✓ Accountable owner assigned
✓ Target delivery date set
✓ Evidence above "opinion" level
✓ Measurable success metric defined
✓ Kill criteria specified
✓ Acceptance criteria documented

Block

The item cannot proceed because a prerequisite is missing. Engineering must not start until the block is resolved.

Common BLOCK reasons:
✗ No owner assigned
✗ Conviction below threshold (still at "opinion")
✗ No target date
✗ Unresolved dependency on another team
✗ Missing acceptance criteria
✗ Scope too vague to estimate

Defer

The item is explicitly removed from active scope for this planning cycle. It is not abandoned — it is parked with a review date.

Common DEFER reasons:
✗ Low business impact relative to engineering cost
✗ Not aligned with this quarter's goals
✗ Duplicates another active bet
✗ Cannot be validated at current scope
✗ Better served by a completely different approach

Why Heads of Product Need This (Not Just Founders)

At seed stage, the founder is the decision system. They're in every meeting, know every customer, and hold the full context. Decisions happen in their head.

At Series A and B, the Head of Product inherits a different situation:

• 3–8 engineers are building simultaneously across multiple workstreams
• The founder is increasingly unavailable for daily product decisions
• Feature requests come from sales, support, investors, and the founder — all with different priorities
• Items enter the roadmap but nothing formally exits
• There's no shared language for "this isn't ready" or "we're choosing not to do this"

The Decision Queue gives the Head of Product a shared language and a forcing function that makes every roadmap decision explicit, accountable, and reversible.

The 8 Gating Criteria: What Makes an Item "Ship-Ready"

Before an item moves to Ship, it must pass these eight checks:

1. Owner: Is there one accountable person who will see this through delivery?
2. Target date: Is there a delivery date that makes sequencing possible?
3. Conviction: Is the evidence above "opinion" — is there observation, behavior, commitment, or proof?
4. Success metric: How will we know this worked? What number changes?
5. Kill criteria: If X doesn't happen within Y days, do we stop or shrink the bet?
6. Acceptance criteria: What must be true? What must NOT happen?
7. Dependencies: Are dependencies identified and dated?
8. Concentration fit: Does this fit within the portfolio balance, or does it increase risk?

Real Walkthrough: Sorting a 40-Item Roadmap in 60 Minutes

Here's how a Head of Product at a 35-person Series B company would run a Decision Queue session for the first time.

Step 1: Full Inventory (10 minutes)

List every item that is currently "in progress," "planned," "under consideration," or "requested." Every single one. Don't filter yet.

Result: 43 items across 6 themes
Acquisition: 18 items
Retention: 8 items
Monetization: 3 items
Trust: 5 items
Efficiency: 6 items
Unclassified: 3 items

Step 2: Apply Gating Criteria (30 minutes)

For each item, check the 8 gating criteria. You don't need perfection — you need a clear signal on whether the item is Ship, Block, or Defer.

Example: "Launch new referral program"
✓ Owner: Sarah (Growth PM)
✓ Target date: April 15
✗ Conviction: Opinion only — no evidence users would refer
✗ Success metric: None defined
✗ Kill criteria: None
✓ Acceptance criteria: Basic flow documented
✗ Dependencies: Needs payment team support (not confirmed)
✓ Concentration: Fits acquisition theme

Verdict: BLOCK
Block reason: Conviction below threshold + no success metric + unconfirmed dependency
Resolution owner: Sarah
Resolution due: March 28

Example: "Improve checkout conversion flow"
✓ Owner: James (Product Lead)
✓ Target date: March 30
✓ Conviction: High — support tickets + funnel data show 22% drop-off at checkout
✓ Success metric: Checkout completion rate from 48% → 60%
✓ Kill criteria: If completion doesn't reach 55% within 14 days, roll back
✓ Acceptance criteria: Documented with edge cases
✓ Dependencies: None
✓ Concentration: Monetization — underfunded theme, adds balance

Verdict: SHIP

Example: "Build admin dashboard for enterprise"
✗ Owner: Unassigned
✗ Target date: None
✗ Conviction: One sales prospect mentioned it
✗ Success metric: None
✗ Kill criteria: None
✗ Acceptance criteria: None
✗ Dependencies: Unknown
✗ Concentration: Would add to already-heavy acquisition theme

Verdict: DEFER
Reason: Single data point, no owner, no evidence, increases concentration risk
Review date: June planning cycle

Step 3: Sort and Summarize (15 minutes)

Decision Queue Summary — Week of March 16

SHIP (12 items)
  → Engineering authorized. Owners confirmed. Metrics tracked.

BLOCK (18 items)
  → 7 blocked on missing owner
  → 5 blocked on conviction below threshold
  → 4 blocked on missing acceptance criteria
  → 2 blocked on unresolved dependencies

DEFER (13 items)
  → 8 low ROI for this quarter
  → 3 duplicate another active bet
  → 2 single data point, no validation

Active engineering scope: 12 items (was 43)
Items with explicit decisions: 43/43 (was 0/43)

Step 4: Announce the Queue (5 minutes)

Share the Decision Queue with engineering, founders, and stakeholders. Be explicit:

• Ship items are what we are building this cycle
• Block items are paused. Here's what's missing and who is fixing it
• Defer items are off the active scope. We'll re-evaluate at the next review

Transparency eliminates "why aren't we working on X?" conversations. The answer is always in the queue.

The 15-Minute Weekly Decision Queue Review

The Decision Queue isn't a one-time exercise. It's a weekly operating cadence. Schedule 15 minutes every week:

1. Review new requests — apply gating criteria. Sort into Ship / Block / Defer.
2. Check blocked items — have prerequisites been resolved? Move to Ship or Defer.
3. Confirm shipped items — are success metrics being tracked? Any items to kill?
4. Reassess 2–3 deferred items — has the market changed? New evidence?
5. Update concentration balance — are we still balanced across themes?

Weekly Review Template:

New requests this week: [count]
  → Shipped: [count]  Blocked: [count]  Deferred: [count]

Blocked items resolved: [count]
  → Moved to Ship: [count]  Moved to Defer: [count]

Active Ship items: [count]
Active Block items: [count]
Concentration: [top theme]% | [second theme]%

5 Decision Queue Anti-Patterns (and How to Fix Them)

1. Everything is Ship

If nothing gets Blocked or Deferred, the queue isn't working. It means you're rubber-stamping items instead of evaluating them.

Fix: Enforce at least 3 of the 8 gating criteria strictly. Most items will naturally fail at least one.

2. Block items have no resolution owner

A Block without an owner and due date is just another "in progress" with a different label.

Fix: Every Block must have a named resolution owner and a clear due date. No exceptions.

3. Defer items pile up and never get reviewed

Defer is not a graveyard. It's a parking lot with a monthly re-evaluation.

Fix: Review 2–3 deferred items at every weekly session. Close or revive based on changed conditions.

4. Ship decisions are made without success metrics

Shipping without a success metric means you'll never know if the bet worked. You'll ship and move on, which is how waste compounds.

Fix: "What number changes?" is a mandatory question for every Ship decision.

5. New requests bypass the queue

The founder or a sales leader adds something "urgent" directly to engineering, skipping the Decision Queue entirely.

Fix: All requests enter the queue. Urgent items can be fast-tracked through the gating criteria, but they don't skip them. The queue is the single source of truth.

The Power of Block: Why Saying "Not Yet" Is Your Most Important Tool

Most Heads of Product are comfortable with Ship and Defer. The hard one is Block — because it requires telling a stakeholder "this isn't ready" and assigning someone to fix the gap.

But Block is where the most waste is prevented. Every blocked item that gets resolved before entering engineering saves:

• Rework from unclear specs → because acceptance criteria must exist before Ship
• Wrong bets from low conviction → because evidence must improve before Ship
• Coordination chaos → because dependencies must be confirmed before Ship
• Accountability gaps → because an owner must be named before Ship

How ProdMoh Creates the Decision Queue From Your Product Canvas

ProdMoh's Product Canvas doesn't just visualize your roadmap — it generates the Decision Queue automatically by evaluating every PRD against structured signals:

• Conviction Scoring — each PRD gets a conviction score based on clarity, evidence, and verifiability. Low conviction = Block candidate.
• Concentration Risk — Product Canvas flags when themes are over- or under-funded. New items in saturated themes become Defer candidates.
• Ownership Coverage — unassigned PRDs are automatically flagged as Block until an owner is assigned.
• Timeline Coverage — undated PRDs can't be sequenced. They're Block candidates until target dates are set.
• Silo Risk — PRDs with unresolved cross-team dependencies are flagged as Block until dependency dates are confirmed.

The result: every PRD in your Product Canvas has a clear recommendation — Ship, Block with a specific reason, or Defer — so the Head of Product's weekly review is a 15-minute decision session, not a 2-hour debate.

ProdMoh Decision Queue Output:

BLOCK: Ownership
  Pause net-new roadmap intake until PRD ownership is assigned.
  Owner: Head of Product • Due: March 28
  Metric: Unassigned PRDs ≤ 10%

BLOCK: Conviction
  Roadmap conviction is 51/100. Block net-new bets until evidence improves.
  Owner: Head of Product • Due: March 28
  Metric: Conviction ≥ 70 with high evidence signal

SHIP: Checkout Conversion Fix
  Owner: James • Due: March 30
  Metric: Checkout completion 48% → 60%
  Kill: Roll back if < 55% within 14 days

Frequently Asked Questions

What is a Decision Queue in product management?

A Decision Queue is a structured gating system that sorts every roadmap item into Ship (ready for engineering), Block (paused until a prerequisite is resolved), or Defer (removed from active scope). It replaces the default "in progress" state with explicit, accountable decisions.

Why do Heads of Product need a Decision Queue?

At 20–50 person companies, the Head of Product typically manages 40+ roadmap items. Without structured gating, everything stays in progress, nothing gets killed, and engineering spreads effort across too many items. The Decision Queue forces a clear decision on every item before it enters engineering.

What makes an item "Ship-ready"?

A Ship-ready item has an accountable owner, a target date, evidence above opinion level, a measurable success metric, kill criteria, documented acceptance criteria, identified dependencies, and fits within the portfolio's concentration balance.

How is this different from a prioritized backlog?

A backlog is a list of things you might build. A Decision Queue forces a binary decision on every item: proceed, pause, or remove. Backlogs grow endlessly. Decision Queues enforce accountability, evidence requirements, and focus by design.

How often should the Decision Queue be reviewed?

Weekly. A 15-minute review keeps the queue current: check blocked items for resolution, sort new requests, confirm shipped items are tracking metrics, and reassess a few deferred items for changed conditions.

What if the founder adds urgent items that bypass the queue?

Urgent items can be fast-tracked through the gating criteria, but they should not skip them. Apply the 8 checks quickly — if 6 of 8 pass, Ship it. If critical items fail, Block at high priority with same-day resolution. The queue is the single source of truth.

Won't blocking items slow us down?

Blocking items that aren't ready actually speeds you up. Engineering stops working on ambiguous bets that cause rework, and focuses entirely on items that have clarity, evidence, and measurable outcomes. You ship fewer things but ship the right things.

Conclusion: Decide, Then Build

The fastest product teams are not the ones that ship the most features. They're the ones that make the best decisions about what to ship.

The Decision Queue — Ship, Block, or Defer — is the simplest system for turning a chaotic roadmap into a set of explicit, accountable, evidence-backed decisions. It works at 20 people. It works at 200.

If your roadmap currently has 40 items "in progress" and none of them have been explicitly decided, you don't have a roadmap problem. You have a decision problem.