Most project briefs we receive describe a solution. "We want an AI assistant that does X, Y, and Z."
The briefs that lead to the best outcomes look different. They describe a problem. They tell us what the team is dealing with, not what the team has decided to build.
Here's why that matters — and a template you can use.
Why problem-first briefs work better
When a brief describes a solution, the builder has two choices: build what's described, or push back.
Building what's described is the path of least resistance. It's also the path most likely to produce something that doesn't quite work, because the solution was designed without full knowledge of what's technically possible or what adjacent approaches might work better.
A problem-first brief creates space for the builder to bring their expertise to the design, not just the implementation.
The template
The context (2–3 sentences) — what does your company do, and what does the team that will use the assistant do?
The problem (3–5 sentences) — what is the specific pain point? What does the current workflow look like, and where does it break down? What does it cost the team in time or money?
The outcome you're looking for (2–3 sentences) — what would success look like in practical terms?
The constraints — what systems does the assistant need to integrate with? What data does it have access to? Are there compliance or privacy constraints?
What you've already tried (optional) — if you've attempted to solve this problem before, what happened?
What to leave out
Don't specify the technology. Don't describe the interface in detail. Don't prescribe the architecture. These are design decisions that should emerge from a good discovery process, not be locked in before it begins.
The brief should make the problem vivid and real. The solution is something you and the builder arrive at together.
If you'd like help working through a brief before approaching any vendor — including us — we're happy to do that in a no-obligation discovery call.