Demand management is deciding, not collecting

Demand management is the practice of deciding what happens to the work people ask for — shaping raw requests into decidable demands, refusing or parking some on the record, and committing the rest against real capacity. It is not intake: an intake queue collects and orders wishes, and a wish can sit in a queue for a year without anyone being wrong. Demand is managed when every request reaches one of a small set of recorded outcomes — planned, sent to a time-boxed discovery, parked with a review date, or declined with a reason — and no request can simply be ignored. The queue answers "what have people asked for?"; demand management answers "what did we decide?"

Demand management, defined by its exits

Ask a team how they handle incoming work requests and they will show you a queue. A form, a Slack channel, a backlog — somewhere requests go. Ask who decided about the request that arrived in March and the room goes quiet.

That gap is the difference between collecting demand and managing it, and most of what gets called demand management is collection.

A queue records wishes

The intake queue is genuinely useful, but be precise about what it does: it records that a wish exists. Ordering the queue does not change that. Grooming it does not change that. A request can sit in a well-groomed, carefully ordered backlog for a year without anyone being wrong, because nothing about a queue obliges anyone to decide anything.

The queue answers one question — what have people asked for? The question a delivery organisation is actually accountable for is a different one: what did we decide? A queue cannot answer it, however good the tooling, because deciding was never the queue's job.

Management means exits

A demand is managed when it reaches a recorded outcome. The set of outcomes is small, and the smallness is the point:

Plan it — the work is understood and worth taking towards a commitment.
Run a time-boxed discovery — the answer needs real work to find, so that work gets a goal and a deadline instead of an open-ended "we'll look into it".
Park it — not now, with a review date or an explicit decision to park indefinitely. A park with no horizon is a decline that is embarrassed about itself.
Decline it — no, with a reason the requester can read.

Planned work then goes on to be committed against capacity and closed against the promise — but those are later stages. Demand management is the part before: making sure every request gets one of these exits, on the record, with a name attached. The defining property is negative: no request can simply be ignored. "Leave it in the list" is not an exit.

Not project management, and not intake either

Two boundary confusions keep the term muddy. The first: demand management is not project management. Project management runs work that has already been committed to — schedules, status, delivery. Demand management is the layer before, deciding whether a request becomes a commitment at all. The two answer different questions, and the second one is where most missed dates are actually decided: a commitment made with no owner, no capacity figure and unexamined unknowns will slip however well the project is then run.

The second: demand management is not intake. Intake is the door — it collects requests in a readable state. A team can have an excellent form and no demand management at all: requests arrive cleanly and then sit in a well-organised queue where nothing is ever refused, parked or committed on the record. Collection is necessary. It is just not the job.

The door has a floor

Deciding well starts before the queue. A request that cannot be decided on — a bare topic like "reporting", a solution with no stated problem — costs a shaping conversation downstream that one sentence at the door would have avoided. So the door has a floor: a request enters when it states what needs to change, plus at least one of who is affected or what happens if nothing changes. Below the floor, the request is not rejected; it is handed back with the one question that clears it. The full argument is in the intake overview .

A worked example

A platform EM at a 400-person company receives about sixty requests a quarter. Under collection, all sixty went into the backlog, the backlog stood at 340 items, and a quarterly grooming meeting skimmed the top forty and decided nothing. Requesters followed up by escalating, because escalation was the only lever that visibly worked.

Under demand management the same sixty look different. Nine fail the floor and go back with one question; five of those return sharpened. Of the fifty-six that enter, that quarter's record shows fourteen planned, four sent to discovery with target dates, sixteen parked with review dates, and twenty-two declined with reasons. The interesting number is the twenty-two: none escalated. A requester who gets a reasoned no in a week trusts the process more than one holding a twelve-month maybe — and the backlog stopped being a place where requests go to age.

Refusal is the half people skip

Notice that two of the four exits are ways of saying no. That is not an accident. An organisation that cannot refuse on the record cannot commit credibly either, because its yes is diluted by everything it silently failed to decline. Why the no needs an owner, a reason and a date is its own argument .

How DeliverySheet does it

The product is a demand management system in exactly this sense. Capture holds the floor — a stated need plus an impact or a trigger, with no override. Shape turns the request into something decidable. Decide offers the four exits above and nothing else: there is no state in which a demand just sits, and a discovery cannot be opened without a target date on which it must conclude. The short definition lives in the glossary ; the stages after the decision — plan, commit, deliver, learn — each get their own scrutiny elsewhere on this site.