How do I write a project brief when the goal is clear but the solution is not?
Quick answer
State the outcome, who it is for, why it matters, and any confirmed constraints. Then identify which methods remain undecided and what the project needs to learn before choosing one. A useful brief gives people enough direction to explore options without turning an early suggestion into a requirement. Mark assumptions and unknowns clearly, and name the next decision the brief should help people make.
The question, the details, the next step.
I know what I want this project to achieve, but I don’t know what the solution should be. How do I write a brief without making it vague?
Be specific about the destination, not prematurely specific about the route. Describe the intended outcome, who it is for, the context, and any confirmed constraints. Leave the method open if it has not been decided.
Keep three things distinct:
- Goal: the outcome or change the project should support.
- Possible solution: an idea to explore, not a settled requirement.
- Open question: something to investigate before choosing an approach.
For example, “Help new members find the right information” is a goal. “Build an app” is one possible solution. Unless the app is already a firm constraint, label it as an idea.
What should I put in the brief so the team can start exploring?
Include enough context for people to propose suitable approaches. This structure separates what is known from what is still open:
Project brief
- Situation: [What is happening now?]
- People affected: [Who is the project for?]
- Goal: [What outcome should improve, and for whom?]
- Why it matters: [Why is this worth addressing?]
- Known constraints: [Confirmed dates, resources, approvals, or other boundaries.]
- What is open: [Methods, formats, tools, or choices not yet made.]
- Questions to explore: [What should be understood or compared first?]
- How proposals will be assessed: [What would make an approach a good fit?]
- Next decision: [What needs deciding, by whom, and when?]
If something is unknown, say “to be confirmed” and, where useful, name who will clarify it. That is more useful than presenting an assumption as fact.
Could you show me how that works with an example? I’m thinking about helping new members understand our group’s activities.
Here’s an illustrative example. Replace the bracketed details with information about your group; they are not established facts.
Situation: New members may have difficulty finding an overview of the group’s activities. [Confirm whether this is happening.]
People affected: New members, especially during their first [time period].
Goal: Help new members understand what the group does and identify a suitable next step.
Why it matters: We want members to know where to begin. [Replace this with the group’s actual reason.]
Known constraints: [List only confirmed constraints.]
What is open: The format, channel, and content of any support. A guide, an introduction session, or clearer existing information are possibilities, not decisions.
Questions to explore: What do new members need to know first? Where do they currently look? What is confusing or missing? Which options fit the confirmed constraints?
How proposals will be assessed: Each proposal should address the goal, suit the intended members, and explain what it requires. Agree any additional criteria with the people responsible for the project.
This brief describes an outcome and questions to investigate without making “create a guide” the answer in advance.
How do I stop an early suggestion from turning into a requirement as people discuss the brief?
Label suggestions visibly and keep them apart from confirmed boundaries. For example, write “Ideas to explore: a short guide; an introduction session; improving existing information” rather than listing one of them as a requirement.
Name the decision the brief should enable: for instance, “Compare approaches and recommend one” or “Identify what we need to learn before selecting an approach.” If something has already been decided, state it as a constraint and identify who confirmed it. If it has not, mark it “open for discussion.”
How can I tell whether I’ve left too much open?
Ask whether someone proposing an approach can tell what outcome matters, who the work is for, and which boundaries must be respected. If not, add the missing context or say who will clarify it. If those points are clear but several methods remain possible, the brief may be open in the right way.
Have the project owner confirm that the goal and constraints reflect actual decisions. Keep genuinely undecided choices labeled as open. The brief is a shared starting point for exploring options, not a promise that any one option will succeed.
A practical checklist
Describe the outcome without presenting a preferred solution as settled.
Identify who the outcome is intended to help.
Separate confirmed constraints from assumptions and unknowns.
List questions to explore before choosing an approach.
State how proposals will be assessed and what decision comes next.
A few more useful answers
Can I mention a solution I already have in mind?
Yes. Put it under “ideas to explore” or “initial hypothesis,” and say it is not a requirement unless it has been decided.
What if the goal is clear but the audience or constraints are not?
State what is known, mark what needs confirmation, and assign someone to clarify it. Avoid filling gaps with guesses.
Should a brief include success measures when we do not know the solution?
Describe progress at the outcome level if you can. If a measure is still being considered, label it provisional rather than presenting it as agreed.