There’s a particular kind of work problem I run into all the time: I know what I need to communicate, but the information is everywhere. There might be a few bullets from a meeting, a number I copied down earlier, something someone mentioned in a message, a risk I don’t want to forget, and three half-finished thoughts that made perfect sense when I wrote them.
The problem usually isn’t that I don’t have enough information. It’s that I haven’t figured out what shape the information should take yet.
That’s where a brief can be useful. A good brief doesn’t need to be long, formal, or written in corporate language. It just needs to help another person quickly understand what’s going on, what matters, and what happens next.
Start by collecting, not writing
One of the easiest ways to make this harder is to start polishing sentences too early. If your notes are scattered, your first job is simply to get them into one place.
Copy the bullets. Paste the rough notes. Write down the number you’re trying to remember. Add the concern that keeps coming up. Don’t worry yet about whether something belongs in the introduction or the third section of the final brief.
At this point, messy is fine. You’re gathering ingredients, not plating the meal.
Figure out what the reader actually needs
Once everything is in front of you, think about the person who will receive the brief. What are they trying to understand?
A project team might need to know what changed, what’s blocked, and what they need to do next. A client might care more about what was discussed, what you agreed to, and what you promised to follow up on. Someone making a decision may need the context, available options, risks, and your recommendation.
This is why I think “write a brief” is often too vague an instruction. The structure should follow the job the brief needs to do.
Find the handful of things that matter
Your notes probably contain more information than the final brief needs. That’s normal.
Go through them and look for the pieces that would cause a problem if the reader missed them. Maybe that’s a deadline that moved, a metric that changed, a decision that needs to be made, a risk that is becoming more serious, or a next step someone needs to own.
Those are the anchors of the brief. Everything else can support them.
This doesn’t mean stripping away every useful detail in the name of being concise. It means giving the important information enough room to be noticed.
Give the information a simple structure
Once you know what matters, start putting related information together. You don’t need a complicated template.
For a basic status brief, you might use a short summary followed by what changed, key details, risks or blockers, and next steps. For a decision brief, the sections might instead be the decision that needs to be made, context, options, risks, a recommendation, and what happens afterward.
The section names themselves do a surprising amount of work. They give the reader signposts, and they give you smaller writing problems to solve. “Write the whole project update” can feel intimidating. “What changed this week?” is much easier to answer.
Put the details where they can actually be seen
Numbers, dates, names, decisions, and deadlines have a habit of disappearing inside paragraphs. If something matters on its own, give it some space.
A metric such as “response time dropped from 420ms to 290ms” probably deserves to be a distinct point rather than buried halfway through a long summary. The same goes for a deadline that slipped, a decision that still needs approval, or a person who owns the next action.
A reader should be able to skim the brief and still catch the important parts.
Be clear about risks without making them dramatic
Risks and concerns are useful because they tell the reader where attention may be needed. They don’t have to sound like warnings from an emergency broadcast system.
Instead of writing something vague like “timeline concerns remain,” say what the concern actually is. Maybe a security review has not been scheduled yet, a vendor dependency could delay the next milestone, or the team has less capacity than originally planned.
Specificity makes a risk more useful. It also makes it easier for someone to decide whether anything needs to be done about it.
End with what happens next
A brief feels unfinished when the reader gets to the bottom and still has to ask, “Okay, so now what?”
Your next steps can be simple. Finish the review by Friday. Send the revised proposal. Schedule the client call. Decide between the two options. Follow up with finance.
If there are owners or dates that matter, include them. The goal is to leave the reader with a clear sense of where things go from here.
Then give the whole thing one human pass
Once the structure is there, read the brief from the perspective of someone who wasn’t sitting beside you while all of this happened. That last part matters.
You know what your shorthand means. You know why a certain number is important. You remember the conversation that happened before someone wrote “waiting on approval” in the notes. Your reader may know none of that.
Look for missing context, unexplained acronyms, vague statements, incorrect numbers, and assumptions that only make sense if someone was already in the room. A brief should make things easier for the next person, not hand them a new puzzle.
The goal isn’t perfect writing
I think this is the part worth remembering: a brief doesn’t need to sound impressive. It needs to make useful information easier to understand.
If you already have the facts, the updates, the concerns, and the next steps somewhere in your notes, you’re most of the way there. The work is really about sorting those pieces into a structure that another person can follow.
That’s also the idea behind Briefly. It gives you a place to put the messy version first, choose the kind of brief you’re trying to make, and build a structured starting point that you can edit before it goes anywhere.
Sometimes that little bit of structure is all you need to get past the blank page.