If you have ever received a technology proposal that bore no resemblance to what you asked for, the problem almost certainly started with the brief. Vendors and developers build what they are asked to build. If the brief is ambiguous, they will make assumptions — and their assumptions will reflect their default solution, not your specific problem.
A good technology brief is one of the highest-leverage documents a business can produce. It does not need to be long. It needs to be precise.
What a Brief Is Not
A technology brief is not a specification. A specification describes how something should be built — the technical design, the data models, the interface layouts. That is the developer's job.
A brief describes what problem needs to be solved, the constraints around solving it, and how success will be measured. A developer who understands the problem deeply enough can produce a specification. A developer who receives a partial specification and is asked to fill in the gaps will fill them according to their assumptions, which may not match yours.
The brief is the problem description. The specification is the solution design. Keep them separate.
The Components of a Useful Brief
1. The problem statement
Describe the current situation and the specific friction it creates. Not the solution you want — the problem you have. "We need a client portal" is not a problem statement. "Our clients cannot access their project status without emailing their account manager, which creates communication volume that is overwhelming our delivery team and reducing client satisfaction" is a problem statement.
The problem statement should be specific enough that two people reading it independently would agree on whether a proposed solution addresses it.
2. The affected users
Who currently experiences the problem? Who will use the solution? Be specific about roles, not just functions. "The operations team" is not specific enough. "The three operations managers who run weekly client reports and currently spend four hours per report on manual data assembly" is specific enough.
Include the number of people affected and their technical confidence level. A solution designed for technically confident power users is different from one designed for occasional users with limited digital literacy.
3. The current workflow
Describe what happens today, step by step. This surfaces the details that shape the solution: the systems data needs to come from, the approval steps that cannot be removed, the edge cases the process currently handles, the workarounds people have built. A developer who understands the current workflow builds a better solution than one who is working from the abstract.
4. The success criteria
How will you know the solution is working? State this in measurable terms. "Clients can self-serve project status updates" is not measurable. "Client enquiries to account managers about project status decrease by 60% within three months of launch" is measurable.
If you cannot state measurable success criteria, you are not ready to brief a solution. Go back and refine the problem statement until the success criteria become clear.
5. The constraints
What cannot change? This is where you list the integration requirements (the solution must work with your existing CRM), the budget parameters, the timeline, the hosting or security requirements, the user access model. Constraints are not limitations to apologise for — they are design inputs that make the brief more useful.
6. Out of scope
Explicitly stating what the solution does not need to do is as important as stating what it does. "This does not need to replace our existing invoicing system" or "mobile optimisation is out of scope for the first version" prevents scope creep in proposals and in delivery.
How to Test a Brief
Before sending a brief to vendors, read it from their perspective. Can they answer the following questions from the document alone?
- What is the core problem being solved?
- Who will use the solution?
- What does success look like in measurable terms?
- What systems does the solution need to integrate with?
- What is the approximate budget?
If any of these questions require assumptions to answer, the brief needs more work.
The Brief as a Filtering Tool
A well-written brief filters vendor and developer responses usefully. Proposals that do not address the stated problem become easy to disqualify. Proposals that make different trade-offs in how they solve the problem become easy to compare.
The brief also filters which vendors will respond seriously. A precise, well-structured brief signals to vendors that the client understands what they want and will make decisions rationally. This attracts serious proposals and discourages responses that are primarily sales material.
Invest the time in the brief. It is the document that determines whether everything that follows is building the right thing or building the wrong thing efficiently.
Writing a technology brief is a core output of the discovery phase in our custom software engagements. If you want help structuring a brief for a specific project, book a consultation.
