# Why I Built Delivery Sheet

Source: https://gravam.com/blog/why-i-built-delivery-sheet
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-02
Summary: Why I built Delivery Sheet: on every programme, vague leadership asks became commitments before anyone knew scope, owner or outcome. Shape before you commit.

**The standard advice is to nail down requirements before you commit to a date. Everyone nods at it; almost nobody does it.** I built [Delivery Sheet](https://gravam.com/products/delivery-sheet) because I spent 18 years watching the exact failure that advice is meant to prevent: 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. At some point I stopped filing it under bad luck and started filing it under missing tool. Delivery Sheet is that tool — the one I wished existed on every programme: 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](https://gravam.com/blog/my-product-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 answers "sure, we can do that." Three weeks later that nod has hardened into a commitment: a date living in someone's head, attached to a scope nobody wrote down, owned by no one in particular. Then the real cost arrives — [rework, a scope fight, a slipped date](https://gravam.com/blog/05-commit-before-clear) — and none of it traces cleanly back to the thirty seconds where the ask was never shaped.

I watched it play out on programme after programme. It isn't 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](https://gravam.com/blog/06-slack-request-to-initiative). A one-liner has to become a few clear things — problem, outcome, scope, owner, open questions — before a team can honestly commit or decline. That shaping takes minutes and saves weeks. It rarely happens, because in the moment it reads as friction, and there was never a tool that made 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 takes a raw request and drafts it into structured fields — [problem, outcome, scope](https://gravam.com/blog/project-intake-process-for-finance-and-engineering-teams) — and surfaces the gaps and open questions. Then it forces one of four honest decisions: [commit, shape further, pause, or decline](https://gravam.com/blog/why-delivery-sheet-has-four-decisions). The output isn't "it's on the backlog"; it's a decision made with eyes open. The AI does the fast drafting; the human makes the call — the [line I hold on every product](https://gravam.com/blog/how-i-use-ai-without-letting-ai-decide).

## Why it's a product, not a template

Anyone can build 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 exact 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 they reach for.

## Who it's for, and why now

It's for [engineering and product leaders](https://gravam.com/products/delivery-sheet) — the people standing 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; take that friction out 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 find out what they meant in production. If that's your world too, [that's what it's for](https://gravam.com/products/delivery-sheet).

***

_See also [the project intake process](https://gravam.com/blog/project-intake-process-for-finance-and-engineering-teams) and [my product operating system](https://gravam.com/blog/my-product-operating-system)._

## Questions this article answers

**Q: What problem does Delivery Sheet solve?**

Delivery Sheet solves the failure that starts most delivery problems: a vague leadership ask becomes a commitment before anyone knows the scope, the owner or what success looks like. Teams dig requirements out of scattered messages and commit to a date before the work is actually understood, and the bill arrives weeks later as rework and scope fights. Delivery Sheet takes a raw request and shapes it into a decision-ready one-pager — problem, outcome, scope, owner, open questions — so you decide with eyes open before you commit people.

**Q: Who is Delivery Sheet for?**

Engineering and product leaders — the managers and directors who receive demands, shape them into work, and report upward. Anyone who regularly gets a one-line ask ('can we add X?') and has to turn it into something a team can actually commit to, or honestly decline, without losing weeks discovering what it meant. It's built for the person standing between a vague request and a team's committed time.

**Q: How does Delivery Sheet work?**

You capture a raw request — a Slack message, an email, a hallway ask — and it drafts that into structured fields: title, problem, outcome, scope. It surfaces the gaps and open questions, so instead of committing to a sentence you shape it into a decision-ready one-pager and then make one of four honest calls: commit, shape further, pause or decline. The point is to make the shaping fast and the decision explicit, so 'yes' is a choice rather than a reflex.