Writing a Research Brief Before You Start

It's tempting to open a notebook and start exploring the moment an idea occurs to you — pull some data, plot something, see what turns up. That approach feels productive but tends to drift: an hour into "let's see if earnings surprises predict returns" becomes an unfocused tour through five loosely related questions, none of them answered cleanly, because nothing was pinned down before the exploring started. A research brief is a short document, often less than a page, written before touching data, that forces the question into a shape precise enough to actually test.

What goes in a brief

A good brief states the specific question being asked — not "does sentiment matter" but "does a spike in negative news mentions predict a stock's return over the next five trading days." It states why the question is worth answering: what would change if the answer were yes, and is this a genuinely new question or one the team has already looked at. It states, in advance, what result would count as interesting enough to pursue further, so the researcher isn't left rationalizing a marginal result after the fact. And it sketches the data and rough approach, mainly so a second pair of eyes can flag an obvious problem — a lookahead bias, a dataset that doesn't exist far enough back — before time is spent building on it.

Worked example

A researcher wants to explore whether a factor built from supply-chain relationships predicts returns. A brief written first states: the question (does a customer's stock return predict its supplier's return over the next week, beyond what's already captured by the supplier's own momentum), why it matters (if real, it's a genuinely new source of signal not already priced into existing factors), and the bar for success (a statistically significant effect after controlling for the supplier's own momentum, tested out of sample). Writing that down before opening any data took twenty minutes and immediately surfaced that "beyond existing momentum" needed to be part of the test from the start, not bolted on afterward once a promising-looking raw correlation had already been found and gotten attached to.

What this means in practice

A brief costs little time to write and saves much more time later, mostly by catching design problems — an unclear success bar, a missing control, a question that's already been answered — before they're baked into hours of exploratory work. It also creates a natural artefact for a manager or teammate to sanity-check a project's direction early, when redirecting it is cheap, rather than after a week of work when redirecting it feels like waste.