A Markdown project brief you can actually use
A project brief should help someone begin the work and make sensible decisions while doing it.
That sounds obvious until you open a brief full of phrases such as “create impact” and “deliver excellence.” They sound encouraging. They leave the person doing the work with quite a few questions.
Start with the questions. Here is a small Markdown template you can copy into a new file.
# Project brief: [name]
## Goal
What should this work help someone understand or do?
## Audience
Who is this for, and what do they already know?
## Deliverables
- [Item to produce]
- [Required format or destination]
## Requirements
- [Something the work must include]
- [A constraint that affects the work]
## Open decisions
- [Question] — [person responsible for answering]
## Review
Reviewer: [name]
Feedback needed by: [date]
Ready means: [specific review criteria]
## Next action
[The next concrete step]Delete anything that does not help your project. You can add a section later when you have a reason.
Give the goal a visible result
“Create a great guide” leaves a lot open. “Help a new team member submit their first expense report” tells you what the guide must accomplish.
That goal changes the writing. You need the submission steps, the required information, and a way to tell whether the process worked. A long history of the expense policy probably does not belong near the beginning.
A useful goal also makes review easier. Someone can follow the guide and see where they get stuck.
Separate a requirement from a suggestion
When every item appears in one long list, people have to guess which ones are mandatory.
For example:
## Requirements
- Include the submission deadline.
- Show where receipts are uploaded.
- Use the current form.
## Possible additions
- A short example of a completed submission.The possible addition may be valuable. Keeping it separate makes the decision visible. You have preserved the idea without silently expanding the assignment.
If you are briefing someone else, this is a useful courtesy. They should not need to interpret the strength of every sentence before starting.
Make unresolved decisions easy to find
A brief can be useful before every question is answered. It becomes misleading when it hides the gaps.
Write “Confirm whether contractors use the same form” under Open decisions. Name who can answer it. If the decision blocks part of the work, say which part.
That is better than guessing or scattering question marks throughout the document. It gives the next conversation a clear agenda.
When the question is resolved, move the answer into the relevant section and keep a short record of the decision if the reason may matter later.
Define the review before the deadline
“Send for feedback” is only part of a review plan. What should the reviewer check?
For the expense guide, the criteria could be: the steps match the current process, the example contains no real personal information, and a new employee can find the upload location.
Those criteria are more useful than asking whether the reviewer likes it. They connect the review to the goal.
Leave a clear next step
A good brief should end the period of wondering what to do next.
“Confirm the submission deadline with the office manager, then draft the steps” is a usable action. “Work on the guide” is something you can keep writing for several days without changing the project very much.
Save the brief where the people doing the work can find it. Revisit it when the scope changes. The template gives the conversation a shape; keeping the answers current is what makes it useful.
Keep exploring
Read the Markdown templates for more examples.