An idea often arrives as a proposed solution: a new newsletter, a redesigned page or a better internal tool. Before expanding the plan, write a short brief that explains why the work should exist. One page is a useful constraint because it exposes what is still unclear without demanding a finished strategy.
Describe the situation
Name the person who experiences the problem and describe a concrete moment when it occurs. “New customers cannot find the setup instructions after purchase” is more actionable than “Our onboarding needs improvement.” Include what you know and how you know it, then distinguish assumptions that still need checking.
Keep the language understandable outside your own role. If the brief depends on internal abbreviations, explain them. The document should allow a collaborator to challenge the idea, not require them to pretend they understand a specialist description.
State the change you want
Describe the intended result from the audience’s perspective. A proposed setup page might help a customer identify the first action and locate support. That is a more useful outcome than “publish three pages,” which measures production rather than usefulness. You can still list outputs later, once the purpose is clear.
The Atlassian project-poster approach similarly encourages teams to examine the problem, potential solutions and desired result. Our one-page format below is an editorial working suggestion, not a reproduction of that template or a guarantee of project success.
Draw the boundary
Write what is included in the first attempt and what is deliberately outside it. A setup page might cover the first three common actions while leaving account migration for a separate project. Boundaries help collaborators evaluate the same thing and prevent every useful suggestion from becoming an immediate requirement.
Name a decision owner and the people who must contribute. Include timing that reflects actual availability. A project with no clear approver can accumulate work indefinitely; a project with an impossible date can encourage people to conceal uncertainty. Make both issues visible while the scope is still small.
Identify the assumption worth testing
Ask what would have to be true for the idea to help. Perhaps customers need clearer instructions, but perhaps they cannot access the product at all. Building more instructions would not solve the second problem. Choose a test that can distinguish the possibilities before committing to the full solution.
A test could be a conversation, observation of a current workflow or a rough prototype used for one realistic task. Define what you would learn and how it would change the next decision. “Get feedback” is too broad; “Check whether people can identify where to start” provides a useful focus.
Write the brief in plain sections
Use these prompts: situation, audience, intended change, first scope, exclusions, evidence, open assumptions, owner and next review. Fill them with short paragraphs or bullets. Leave uncertainty visible rather than filling every field with confident-sounding language. An honest question is more useful than a fabricated answer.
Share the draft with the people responsible for the next step. Ask where their understanding differs and revise the brief before treating it as an agreement. Keep a dated version when a meaningful scope decision changes; otherwise, a living document may silently rewrite the project’s history.
The brief is ready when someone can explain the problem, recognise the boundary and name the next action. Use the guide to testing an idea before building to turn the most important assumption into a small, observable experiment.
Work through a modest example
Suppose a small team wants a resource page for new collaborators. The audience is people joining their first project. The problem is that those people ask the same access and file-location questions. The first scope could be a single page with the current contacts, project index and access instructions. A full training programme remains outside the initial scope.
The first test is whether a new collaborator can locate the correct working document without a separate explanation. That result does not establish whether the entire onboarding process works. It answers a narrower question that the team can use immediately. A brief that preserves this distinction helps keep a useful small project small.