How to brief a dev team so the first demo isn't a miss

Why demos miss

Teams usually build exactly what the brief says. The trouble is that the brief often describes a solution, such as "a dashboard with five charts", when what the business needed was an answer, such as "which clients are about to leave".

When the brief is a list of screens, the team builds those screens. Nobody asks whether they solve the problem.

The one-page brief

The problem. In two or three sentences: what's going wrong today, for whom, and what it costs. Use real numbers if you have them.

The user. Who will use this, how often, and in what situation. A person on their phone between meetings needs something different from an analyst at a desk.

What success looks like. One or two measurable outcomes. "Cut invoice processing from three days to one." "Let a new hire complete onboarding without help."

What exists already. Systems it must connect to, data it can use, constraints such as compliance, security and deadlines.

What's out of scope. Write down what you don't want in the first version. This protects the schedule more than any other line.

What you'll decide and what they will. You own the problem and the priorities. They own the technical approach. Say who signs off on what.

Ask for a small first demo

Request a thin working slice in the first two weeks: real data moving through one path, however rough. It shows quickly whether you're aligned.

What to do this week

1. Write the brief on one page. If it won't fit, the problem isn't clear yet.
2. Add one success number.
3. List three things that are out of scope.
4. Share real samples. Documents, data, screenshots of the current process.
5. Agree the date of the first demo before anyone starts building.