The one-page brief is one of the most powerful tools in any operator or PM’s kit, and almost nobody uses it. Not because it doesn’t work. Because it’s terrifying.
Writing a clear brief forces you to do something that most people avoid: actually articulate what you want to decide. Not think about deciding. Not have a meeting to discuss potentially making a decision. Actually write down: here is the problem, here are the options, here is what I recommend, and here is what I need from you. In one page. With no hedging.
If you can’t write that clearly on one page, you’re not ready for the meeting. You might think you are. You might even sound ready when you’re talking about it. But once you sit down to write it, you’ll discover you’re actually confused about what you’re asking for. And that’s the moment the tool does its job.
Let’s start with the format because it matters. A one-page brief has five sections, and they go in this order:
Problem. One or two sentences. Not “we need to solve our technical debt” but “our current API can’t handle more than 100 requests per second, and we’re projected to hit that load in Q2.” Specific. Measurable. Real.
Context. A paragraph or so. Why does this problem matter? What’s the impact if we don’t solve it? Who’s affected? “If we don’t solve this, we’ll hit rate limits in our Q2 product launch, which means our new customers will experience degraded performance during our most critical window. This will likely kill our NPS and make the launch fail.”
Options. Here’s where you show your thinking. Usually three options, sometimes more. For the API problem: option one, rewrite the API in Go and redesign the architecture, six months, costs 200K in developer time. Option two, upgrade our infrastructure to handle 500 rps on the current architecture, three months, costs 50K, buys us one year. Option three, build a caching layer in front of the API, two months, costs 30K, solves the immediate problem but doesn’t fix the underlying architecture. Each option gets a brief description of trade-offs. Cost, time, risk, what it actually solves and what it doesn’t.
Recommendation. Now you say what you think we should do and why. “I recommend option two. It solves our immediate problem, buys us time to do proper architecture planning, and costs the least. Option three is faster and cheaper but leaves us vulnerable if we grow faster than expected. Option one is overengineered for what we actually need right now.”
Decision needed. What do you actually need from the people in the room? “Do we go with option two and allocate budget and team capacity for Q1? Or do you want to explore option three as an interim solution?”
That’s it. One page. Clear. Decided.
Here’s what happens when you actually do this: the meeting becomes about something. Not about exploring. Not about thinking out loud. Not about vague alignment. About deciding.
Because you’ve already done the thinking. You’ve already looked at options. You’ve already figured out what makes sense. Now the people in the room have a thing to react to. They can say “I don’t agree with your recommendation, here’s why.” They can say “option one is actually better because of X.” They can ask questions that matter because they’re not starting from nothing. The meeting can be 15 minutes instead of 90, and everyone can leave knowing what’s been decided and why.
But here’s the part that’s terrifying: writing the brief forces you to have an opinion.
When you’re in a meeting, you can be vague. You can say “I think we should probably look at this” or “I’d lean toward the faster option” or “what do you guys think?” You can hedge and suggest and explore. Nobody’s pinning you down on paper. But once you’ve written a brief with a recommendation, you’ve taken a position. If it turns out to be wrong, it’s on you. If someone disagrees with you, they’re disagreeing with something concrete, not with a vague sentiment. You have to own it.
That’s why most people avoid the brief. It’s easier to call a meeting and think out loud and let someone else drive to a decision. That way, if it’s wrong, it wasn’t your call. It was a consensus thing. But here’s what that actually costs: time, clarity, and the ability to move fast.
I’ve worked with product leaders who refused to write briefs. They’d call meetings instead. These meetings would happen over and over, circling the same questions, because there was no artefact forcing clarity. Someone would suggest a direction, someone else would push back, discussion would happen, then the meeting would end and people would leave with different understandings of what was decided. Two weeks later, you’d have another meeting because nobody was sure. The cost of avoiding the brief was much higher than the cost of writing it.
The best operators I know write briefs as a default. Not for every decision, but for anything that’s actually going to require other people’s budget, time, or agreement. They write the brief first. They sit with it. They think about whether they actually believe the recommendation. Sometimes they change their mind and write a new one. Then they schedule a 15-minute meeting to get sign-off.
Here’s the thing: this doesn’t mean you’re being autocratic. You’re not unilaterally deciding and then forcing people to agree. You’re being clear about your thinking and inviting them to push back. But you’re inviting them to push back on something specific, not to think out loud in a void. “Here’s my recommendation and why. If you disagree, tell me what I’m missing.” That’s collaborative.
The shift to remote work should have made briefs the norm. Turns out it made the opposite happen. People leaned harder into meetings because writing felt more formal. But a brief isn’t formal. It’s just thinking. Clear thinking. On a page.
If your organisation is slow at decision-making, the reason is almost always that people are making decisions in meetings instead of in writing. Because in meetings, someone gets to steer. In writing, you have to actually make the case. One forces clarity. The other doesn’t.
Start with one decision. The next time you’re about to call a meeting to decide something, write a page instead. Problem, context, options, recommendation, decision needed. Sit with it. If it feels incomplete, you’re not done thinking. When it feels solid, send it to the relevant people and ask for 15 minutes to discuss. See what happens.
I’m willing to bet the meeting is faster, the decision is clearer, and three weeks later you’re not having the same conversation again because everyone’s still confused about what was agreed.
That’s not because the brief is magic. It’s because thinking is magic, and briefs force you to do it before you waste everyone else’s time.