Demand Requests: The Intake Ticket That Decides What Your Team Actually Builds
Before a project exists, there's an idea — a hallway conversation, a stakeholder email, a "can we just...". A demand request is the structured container that catches it, evaluates it, and decides whether it earns a place on the roadmap.
3 min read
The Idea Arrives Before the Project Does
Every project starts life as something much messier: a Slack message from the head of sales, a compliance deadline someone just noticed, a half-formed "what if we rebuilt onboarding?" in a Tuesday standup. These aren't tasks. They don't have owners, estimates, or acceptance criteria. They're demand — raw, unvalidated appetite for change. And if you have no place to put demand, it goes where it always goes: into somebody's inbox, into a spreadsheet nobody opens, or straight onto the backlog where it quietly rots next to forty other good ideas.
A demand request is the high-level intake ticket that catches that raw idea before it becomes work. It's deliberately coarse. It doesn't ask for a work breakdown structure or a sprint plan. It asks: what are you trying to achieve, who cares, what happens if we don't, and roughly how big is this? Its entire job is to make an idea legible enough to be compared against other ideas — and then either promoted into a real project or declined with a reason on record.
What Actually Belongs in a Demand Request
The temptation is to make the form exhaustive. Resist it. A demand request that takes ninety minutes to fill in will be bypassed by anyone with political capital, and you'll end up with shadow intake anyway. A good one captures maybe six things:
The business outcome — not the solution. "Reduce onboarding drop-off" beats "build a new signup wizard."
The requester and the sponsor — who asked, and who is willing to defend this when it competes for budget.
Drivers and urgency — revenue, risk, regulation, cost, customer commitment. Dates that are real versus dates that are aspirational.
Rough size — t-shirt sizing is fine. Precision here is false comfort.
Impacted systems or teams — the early signal for dependencies and hidden cost.
The cost of doing nothing — the single most clarifying question on any intake form.
That's enough to triage. Everything else — scope, architecture, sequencing, RACI — belongs after the decision to proceed, not before it.
From Intake to Execution Without Losing the Thread
The failure mode isn't capturing demand; it's the gap between capture and delivery. An idea gets approved in a steering meeting, someone spins up a project, and three months later nobody can reconstruct why it was prioritized over the alternative. The original request has evaporated. This is where a connected intake queue earns its keep: in Casperry, work arrives as structured Requests and can be converted into a project in one click, and each project keeps a Source view showing the requests and events that led to it — a straight audit trail from "someone asked" to "it shipped." Once the project exists, the vagueness has to end: every task carries a full RACI matrix with exactly one Accountable enforced, so the ambiguity that was acceptable at intake doesn't survive into delivery.
The Counterpoint: When Formal Demand Intake Slows You Down
It's worth saying plainly — demand management is overhead, and overhead has a break-even point. A seven-person startup that funnels every idea through a fortnightly demand review board isn't governing, it's cosplaying enterprise. If your team can hold the whole roadmap in their heads and decide in a ten-minute conversation, a formal intake ticket adds latency without adding clarity. The honest test is this: do you decline things? If every request gets approved, your process isn't a filter, it's a queue with extra paperwork. Formal demand intake pays off when demand genuinely exceeds capacity, when requests come from multiple competing stakeholders, or when you need to justify decisions to someone who wasn't in the room. Below that threshold, keep it light — a shared queue and a habit of writing down why you said no may be all the governance you need.
Make the Decision Visible
The real output of a demand request isn't a project. It's a decision with a reason attached — approved, deferred, declined, merged into something else. Teams that get this right stop relitigating the same ideas every quarter, because the answer and its rationale are already written down. Teams that don't spend their planning cycles rediscovering conclusions they already reached.
If you're trying to close the gap between the ideas landing in your inbox and the work actually shipping, Casperry is built around exactly that path — structured intake, one-click conversion into projects, and a visible trail connecting the two. Worth a look if your demand currently lives in an email thread.