How to Use a One-Page Project Brief

Start with one or two sentences that describe the outcome. Avoid internal jargon if possible.

If the goal is hard to explain simply, the project may still be unclear.

A good goal says what will be different when the project is done:

- "Publish a simple content website with articles, category pages, and trust pages." - "Create a weekly planning routine that can be completed in 20 minutes." - "Prepare a contact page that gives visitors a working way to reach the site owner."

Avoid goals that only describe activity:

- "Work on the website." - "Improve productivity." - "Research options."

Activity can continue forever. A project brief needs an outcome.

A project is easier to shape when you know who it serves and how success will be recognized.

Write:

```text Audience: Success looks like: ```

For example, the audience might be first-time visitors, internal teammates, paying customers, or future you. Success might be a published page, a working workflow, an approved application, or a decision made with enough information.

This keeps the project from drifting toward features that do not serve the audience.

Scope is easier to protect when exclusions are explicit. Write what the project will not include in the current version.

This prevents small projects from quietly becoming large projects.

Out-of-scope notes are not negative. They protect focus.

Examples:

- In scope: static article pages and category pages. - Out of scope: user accounts, comments, newsletter, and custom CMS.

Or:

- In scope: choose an email contact method for launch. - Out of scope: build a full support system.

The brief can also include "later" ideas. This gives good ideas a place to wait without letting them invade the current version.

A useful brief should show what might go wrong and what you are assuming. Risks are not a sign of failure. They are a sign that the plan is honest.

Assumptions are especially important because they are often invisible until they break.

Common risks include:

- timeline is too optimistic - content is not ready - dependency on another person or service - unclear decision owner - technical constraint - budget or time limit

Common assumptions include:

- the current tool is enough - the audience wants this format - the site can stay static for now - a manual process is acceptable for launch

Write risks in plain language. Then add a mitigation if one is obvious.

Small projects generate decisions that are easy to forget. Add a short section for decisions:

```text Decisions: - Use Markdown files for article content. - Keep launch static. - Use Gmail contact address for now. ```

This saves time later. When someone asks why the project took a certain direction, the answer is in the brief instead of scattered across chats and notes.

The brief should lead to action. Add the next three steps, owners if relevant, and any dates that matter.

If a brief does not change what happens next, it is probably too vague.

Good next steps are specific:

- Draft the first 10 articles. - Review privacy policy for ad-related language. - Run production build. - Test the contact page on mobile.

Weak next steps are vague:

- Continue. - Improve site. - Think about content.

If the next step is unclear, the brief needs more work before execution.

The one-page limit is useful. It forces decisions. If the project needs detailed research, technical notes, or design sketches, link them from the brief instead of expanding the brief endlessly.

The brief is the map, not the whole territory. It should be easy to read before a meeting, coding session, or review.

```text Project name: Goal: Audience: Success looks like: In scope: Out of scope: Risks: Assumptions: Key decisions: Next steps: ```

Use the template lightly. The value is not the form. The value is forcing the project to become understandable.