A side project does not need a twenty-page plan before it earns a first work session. It needs a short agreement with yourself about what you are trying to make, who it is for, what will count as proof, and what you are deliberately leaving out.
That is the useful version of a project brief for a side project: one page that turns a vague idea into a bounded piece of work. It is not a pitch deck, a complete task list, or a promise that the idea will succeed. It is a decision surface you can return to when the day job, family, or the next interesting idea pulls your attention somewhere else.
How to write a project brief for a side project
Write six short sections: the outcome, the problem, the first proof, the boundaries, the constraints, and the next decision. If you cannot explain those six things plainly, the project may still be an interest rather than a project. That is useful information. You can either sharpen it or leave it alone without spending weeks preparing to begin.
What a side-project brief is - and is not
A project brief is a compact description of the work that keeps the important decisions visible. A full project plan can contain tasks, dependencies, schedules, roles, budgets, risks, and communication details. A side project may eventually need some of those things, but starting with all of them can turn planning into a more comfortable substitute for making.
A brief is also different from a project proposal. A proposal argues that an idea deserves attention. A brief tells you what you are actually going to test next. It should be specific enough to guide a work session and small enough to revise when you learn something real.
Keep the first version to one page. The limit is not a productivity trick. It forces the project to show its shape.
The six fields that make the brief useful
| Field | Question | Useful output |
|---|---|---|
| Outcome | What will exist? | One visible deliverable |
| Problem | Who is it for and what is difficult now? | One precise situation |
| First proof | What can you show or test? | Evidence, not optimism |
| Boundaries | What is in and out? | A short scope line |
| Constraints | What time, tools, and help are real? | A workable operating condition |
| Next decision | When will you review what happened? | A continue, reduce, change, or stop rule |
1. Name the outcome, not the ambition
Start with a working title and one sentence that describes the thing you intend to finish. Use a form such as: "By [date], I will have [deliverable] for [specific person or use case], so I can observe [specific response or behavior]."
"Build a business around my idea" is an ambition. "Publish a three-page guide that helps first-time clients compare two options" is an outcome. The second sentence gives you something to make, a reader to serve, and a reason to look at the result.
Choose a date for the first proof, not the final version of your imagined future. The first date creates contact with reality.
2. Describe the problem in a single situation
Do not begin with a category such as "productivity," "wellness," or "content." Describe the moment in which the problem appears. Who is trying to do what? What makes the current path slow, confusing, expensive, or easy to abandon?
A specific situation keeps the brief from becoming a container for every possible audience. It also gives you a better test. You can ask whether the first proof helps one person complete one meaningful step, rather than whether the entire market seems interested.
If you are the intended user, say that plainly. Your frustration is still a hypothesis, not universal evidence.
3. Define the first proof
The first proof is the smallest artifact or interaction that can teach you something. It might be a working page, a sample, a short service trial, a conversation using a prototype, or a delivered version of the work. It is not "launch," "go viral," or "make money." Those are outcomes that depend on many conditions outside the first build.
Write down what someone will be able to see, use, read, or respond to. Then name the evidence you will collect. A reader finishing the guide, a real person trying the workflow, or a clear technical limitation can all be useful evidence. A feeling that the project is finally ready is not a measurement.
Make the proof narrow enough that you can finish it without waiting for a complete identity, brand system, or perfect tool stack. A small proof is not a small standard. It is a clean first question.
4. Draw the boundaries before the work expands
Write two lists: in scope and out of scope. Keep each list short. In scope might include one audience, one format, one core workflow, and one review date. Out of scope might include a mobile app, a second audience, paid acquisition, advanced automation, or a full redesign.
These exclusions protect the first proof. If an addition changes the audience, deliverable, or evidence, treat it as a new decision.
Your definition of done should be visible here. The Journal's guide to defining done is useful when the finish line keeps moving. A brief should make the first finish line easier to see, not make the project sound more official.
5. Record the constraints you actually have
Side projects are built inside real lives. Write down the hours you can reliably give the work, the tools already available, the money you are willing to spend, and the people or systems you depend on. Do not write the schedule you would follow in an empty week.
Separate effort from elapsed time. A project may need six focused hours but still take three weeks if those hours arrive in short blocks. If your timing needs more thought, use the Journal's project estimation guide to make a range and name the dependencies.
Constraints also tell you what kind of project this is. A two-hour weekly window calls for a different first proof than a full weekend and a collaborator. The goal is an honest plan that can survive them.
6. Set the next decision before you start
Choose a review date and write the decision it will support. At the review, you might continue, reduce the scope, change the approach, ask for help, or stop. Each option is legitimate. The point is to decide from evidence instead of from the mood of the day.
Use a small set of questions:
- Did the first proof become usable or visible?
- What did a real person do, ask, or fail to do?
- Which assumption changed?
- What is the smallest responsible next step?
- What should be removed before more work is added?
A weekly review that changes next week can keep this decision from disappearing under new tasks. Use a scheduled moment when the project is judged by what happened.
A constructed example
Imagine a side project to create a small portfolio site for people changing careers. The brief might read like this:
- Outcome: Publish one simple site with three project examples and a clear contact path by September 15.
- Problem: Career changers have work to show, but the context and result are difficult to understand from a list of job titles.
- First proof: Three readers from the intended audience can review one case-study page and explain what the person did, what changed, and how to contact them.
- In scope: One page template, three examples, basic mobile checks, and one revision pass.
- Out of scope: A custom content system, a newsletter, a marketplace, and multiple career tracks.
- Constraints: Two focused sessions each week, existing tools only, and no dependence on a new paid service.
- Next decision: On September 16, keep the format, revise the explanation, or stop building until the reader problem is clearer.
This brief does not guarantee a job, an audience, or a business. It creates a fair test. It also gives the builder a clean answer when a new feature appears: does this help the first reader understand the work, or is it a separate project?
When the brief is finished
Read the page once as if you were someone asked to help. Could that person tell what the project is, who it serves, what they could see first, and what you are not doing yet? If not, remove broad language before adding detail.
Then start with the first proof. The brief has done its job when it makes the next work session obvious. It should leave room for teachers, teammates, family, and the people who give useful feedback. Self-made work is still shaped by other people; ownership means making the decisions visible and carrying the next one.
For a focused build block, keep the physical choices simple too. The Standard Issue Crewneck is currently described as a no-hood, heavy-blend fleece layer with ribbed trim and an embroidered white chest mark. It is a uniform choice for the setting, not a promise that the work will be easier.
Keep the brief near the work, return to it at the review date, and let evidence earn the next page. You can find more practical frameworks in The Self Made Journal.
0 comments