Why I Built Delivery Sheet

I built Delivery Sheet because the same failure kept happening on every programme I worked: a vague leadership ask became a commitment before anyone knew the scope, the owner or the outcome — and the bill arrived weeks later as rework. After 18 years of watching it, I stopped treating it as bad luck and started treating it as a missing tool. Delivery Sheet is that tool — the one I wished existed on all those programmes: capture a raw ask and shape it into a decision-ready one-pager before you commit a single person. It's the clearest example of my operating system in action — a real, recurring problem I'd hit hundreds of times, turned into a focused product.

The problem I kept hitting

It always started the same way. A leader drops a one-line ask into a channel — "can we add exposure reporting by entity?" — and someone says "sure, we can do that." That nod, three weeks later, is a commitment: a date in someone's head, attached to a scope nobody wrote down, owned by no one in particular. Then the real cost shows up — as rework, a scope fight, a slipped date — and none of it traces cleanly back to that first thirty seconds where the ask was never shaped.

I saw this on programme after programme. It's not an execution problem; it's a shaping problem, and it happens before delivery even starts.

The insight

The cheapest, highest-leverage moment in any piece of work is the one everyone skips: shaping the ask before committing to it. A one-liner has to become a few clear things — problem, outcome, scope, owner, open questions — before a team can honestly commit to it or decline it. That shaping takes minutes and saves weeks. But it rarely happens, because it feels like friction in the moment and there's no tool that makes it fast.

That gap — a five-minute shaping step that saves a six-week wrong build, with nothing to support it — is the whole product.

How it works

Delivery Sheet captures a raw request and drafts it into structured fields — problem, outcome, scope — surfacing the gaps and open questions. Then it forces one of four honest decisions: commit, shape further, pause, or decline. The output isn't "it's on the backlog"; it's a decision made with eyes open. AI does the fast drafting; the human makes the call — exactly the line I hold on every product.

Why it's a product, not a template

Anyone can make a form with those fields. What makes it a product is that it makes the shaping fast enough to actually do in the moment — the point where discipline usually loses to urgency. It turns "we'll pick it up" from a reflex into a genuine choice, and "no" from something that happens by neglect into something you decide on purpose. That's the difference between a checklist people ignore and a tool people reach for.

Who it's for, and why now

It's for engineering and product leaders — the people between a vague ask and a team's committed time. And it's a product now because AI finally makes the shaping instant: drafting a decision-ready one-pager from a raw message used to be the friction that killed the discipline. Remove that friction, and shaping-before-committing becomes something you'll actually do.

I built Delivery Sheet because I was tired of watching good teams commit to sentences and discover what they meant in production. If that's your world too, that's what it's for.

Part of Building AI Products. See also the project intake process and my product operating system. The newsletter sends one practical build lesson every two weeks.