The project brief
On this page
A brief is how you decide what your final project answers, before you build anything. The question comes first, because a project that answers the wrong question well is worth less than one that answers the right question roughly.
Why a brief exists at all#
You can write good code against a bad question and get an answer nobody can use. That failure is invisible from inside the work, because everything runs and every number appears. The only thing that catches it early is somebody else reading what you intend to ask before you spend two weeks asking it.
So the brief has two jobs. It makes your question concrete enough to be wrong, and it gives a reader something specific to push back on.
What goes in the brief#
Fill these in order. Each one constrains the next, and a gap in an early part shows up as a much larger gap later.
1. Problem#
What question are you answering, and for whom?
Name a real person or group whose question it is: your manager, a team you worked on, a club, a family business, a public body. The owner can be someone you will never speak to during this course. What matters is that the question belongs to somebody and that you can state what they would do with the answer.
A problem statement that names no owner produces a project with no criterion for being finished.
2. Hypothesis#
What do you think the answer is?
Write it down before you look. A hypothesis is a statement that would change your mind if it turned out to be false, so it has to be specific enough to be false. "Customer behavior varies by region" cannot be false. "Our three western regions reorder at least twice as often as the eastern ones" can be.
You are allowed to be wrong here. A hypothesis you wrote down early is cheap to revise. One you never wrote down is expensive to notice.
3. Metrics#
How would you measure whether the hypothesis holds?
Name the number. Name what one row of the data behind it represents, which is the grain. Name the window, which is the period it covers, and the comparison, which is what it is measured against.
Then answer the question this course keeps returning to:
What would that number have to do for my hypothesis to be wrong?
Write the answer into the brief. If you cannot state what result would refute you, the analysis cannot be wrong, which means it cannot be right either. The final memo faces this same test. It is in the brief because this is where changing your mind is still cheap.
4. Evidence method#
How will you collect the evidence?
The evidence can be data you already have, data you pull from an API, a database you build, a backtest against a period where you already know what happened, or a prediction checked against data you held back. Name which. Then state why it fits this question. A list of what is available to you is no answer to that.
If your method is a prediction, the holdout is part of the method, so it has to go in this section. State what you will hold back and what result would make you distrust the model.
5. Results#
What did the analysis show, and how confident are you?
You cannot fill this in when you write the brief, and that is the point of leaving it in the template. It tells you what shape the answer will take before you go looking for it. Write one sentence describing the form of the result you expect, for example "a ranked list of about a dozen suppliers with a concentration figure for each".
If you cannot describe the shape, the question is still too vague.
6. Conclusion#
What does this mean for the original question, and what is the next question?
Leave this one blank in the brief. It exists so you remember that the brief is a loop. The answer you get will move the question, and the next version of the question is a result too.
Getting it reviewed#
A reviewer plays the stakeholder whose question it is. The reviewer's job is narrow and it is the whole point:
- Read the brief and repeat back what you think is being asked. If the writer has to correct you, the problem statement needs work.
- Ask what one row of the metric represents. A metric whose grain the writer cannot state is not yet a metric.
- Ask what result would prove the hypothesis wrong. Accept no answer that could not actually happen.
- State which of the candidate questions you would fund, and why.
Encouragement is not the job. A brief that only ever gets a friendly reading has not been reviewed.
The candidates you set aside#
For a candidate you reject, write what the question was and what killed it. Real reasons look like these.
- The data does not exist, or reaching it needs access you do not have.
- The grain does not support it. The question asks about customers and the data is one row per order with no way back.
- No decision hangs on the answer. Somebody would read it, agree, and do nothing.
- It cannot be wrong. Every possible result confirms it.
"Less interesting" is not a reason. State what specifically made it undeliverable. A rejection written for a candidate that was never seriously considered reads as one, and it costs about as much effort as a real one.
The harder case is several candidates that all survive this list. Ranking them is its own skill, and the work that isn't code has moves for it.
Last updated: Sunday, 11/1/2026