How to turn a vague founder idea into a project brief
By Alice Huang, Chief of Staff and operator
Turn a founder idea into a project brief with a problem, evidence, outcome, scope, owner and decision gate before committing the team.
"We should build this" is the beginning of a conversation, not a finished project brief.
Atlassian's Project Poster asks teams to clarify the problem, validate assumptions and update the plan as they learn. It is a living document, particularly useful when the work contains unknowns. You can borrow that habit without making every small task a planning exercise.
Ask what problem the idea solves
Who has the problem? What is happening now? What evidence suggests it matters? What would be different if it were solved?
Do not treat the founder's proposed solution as the only possible answer. Write the problem separately so the team can compare options.
Build a brief that makes choices visible
- Problem: the current situation and who it affects.
- Evidence: what is known and what needs checking.
- Outcome: what success would look like.
- Scope: included work and explicit exclusions.
- Owner: who drives it and who makes the decisions.
- Constraints: time, budget, access and dependencies.
- Next gate: what must be learned or approved before proceeding.
This is a suggested outline, not a promise that a page makes a project safe. The work still needs the right authority, resources and approvals.
Use a fictional example
Idea: "We need a new onboarding app." Problem statement: "New customers repeat information because our handoff is incomplete." Before committing to an app, check which information is missing and whether a smaller process change would help.
The example is invented. Its purpose is to show how a solution can become a question you can investigate.
Keep the brief current
Record assumptions as assumptions. Add evidence as it arrives and note decisions when they are actually made. Atlassian's DACI framework helps separate the person driving the work from the decision maker.
When new information changes the plan, bring the change back to the owner. Do not quietly expand the scope because the original idea was vague.
A good brief gives the team enough clarity to take the next step. It does not have to pretend that the whole project is already understood.