What are the four decisions in Delivery Sheet?

Commit, shape further, pause, and decline. When a request comes in, instead of the default 'sure, we can do that', Delivery Sheet forces an explicit choice: commit (it's clear, owned and worth doing now), shape further (it matters but isn't ready to commit to), pause (a good idea at the wrong time, parked with a revisit date), or decline (the problem isn't real or worth the cost — say no early, with a reason). The point is that every ask gets a deliberate decision instead of a reflexive yes.

Why force four decisions instead of just a backlog?

Because 'add it to the backlog' is really 'yes, eventually' — a soft yes that avoids the honest decision. A backlog fills with everything because nothing was ever actually declined; 'no' happens by neglect months later instead of on purpose now. Forcing one of four explicit decisions makes the team choose deliberately: commit with real scope, shape what's not ready, park what's mistimed, or decline what shouldn't be built. It turns a queue that chose you into a roadmap you chose.

How does this help teams deliver better?

It moves the decision to the cheapest moment — before commitment — and makes it explicit. Most delivery pain comes from committing to vague asks by reflex and discovering the cost later. Four honest decisions force clarity up front: is this clear, owned and worth doing now, or not? Saying 'shape further', 'pause' or 'decline' out loud, early, prevents the rework, scope fights and slipped dates that come from a backlog full of un-decided work.

Why Delivery Sheet Has Four Decisions: Commit, Shape, Pause or Decline

Ask most teams what they say to an incoming request and the honest answer is one word: yes. Delivery Sheet refuses to let you stop there — every ask gets one of four answers, commit, shape further, pause, or decline — because "yes by default, no by neglect" is what quietly sinks delivery. This is a product decision, not a feature list, and it's worth explaining, because those four choices are the whole philosophy of the product in one design move: replace the reflexive yes with a decision someone actually made. Everything else Delivery Sheet does exists to make those four honest and fast.

The problem with one answer

Watch how requests actually get handled. A leader asks; someone says "sure, we can do that," or "I'll add it to the backlog." Both are yes — one now, one deferred. There's no real mechanism for the other answers, so they never happen: nothing gets deliberately shaped, paused, or declined. The backlog swells with everything, because nothing was ever actually said no to. The "no" turns up months later, by neglect, when the un-started work has quietly rotted — which is the most expensive moment to say it.

A one-answer system isn't a decision process. It's a queue that chose you.

The four honest decisions

So Delivery Sheet makes you pick one, on purpose:

Commit — it's clear, owned, and worth doing now. Commit with real scope and a real date.
Shape further — it matters, but it isn't ready; some open question is big enough to change the plan.
Pause — a good idea at the wrong time; park it honestly, with a date to revisit.
Decline — the problem isn't real, isn't worth the cost, or belongs to someone else. Say no early, and say why.

The discipline isn't in the four options — anyone can list four words. It's in being made to choose one out loud, instead of defaulting to yes and finding out the cost in delivery.

Why four, and not fewer

Fewer than four and you lose an honest outcome. Drop "shape" and every not-yet-ready ask becomes a premature commit or a flat no. Drop "pause" and good-but-mistimed ideas get killed or shipped anyway. Drop "decline" and you're straight back to yes-by-default. Each of the four earns its place because a real, distinct thing happens to incoming work — and a tool that can't express one of them nudges the team back toward the reflex. Four is the smallest set that covers how work actually gets decided.

The product decision behind it

This is a plain example of making the product decision yourself instead of defaulting to the obvious build. The obvious build is a nicer backlog — capture the requests, sort them, prioritise them. But a nicer backlog is still a yes-machine; it just arranges the yeses more tidily. What makes Delivery Sheet a product and not a tidier list is the recognition that the missing thing was never organisation — it was the decision. So the four decisions aren't a feature bolted on the side; they're the point the whole product is built around.

If your team commits to sentences and learns what they meant in production, the fix isn't a better backlog — it's four honest decisions, made on purpose.

Part of Building AI Products. See also why I built Delivery Sheet and the project intake process. The newsletter sends one practical build lesson every two weeks.