Deployed Works Guide
For organisationsHow To Write A Capability Brief
Describe the finished outcome, current problem, constraints, timing and budget without choosing the solution too early.
Audience
For organisations
Buyers, founders, operators and capability buyers
Time
2 minute read
Outcome
Describe the finished outcome, current problem, constraints, timing and budget without choosing the solution too early.
Share this guide
PDF guide
Share this guide with your team.
Download the PDF for meetings or offline use. The web guide has the latest version.
Related guides
Before / after transformation
Turn a provider-shaped request into an outcome brief.
Use this sequence when a need starts as a provider label but the real requirement is a business result.
Start
Outcome
What needs to be different for the business, customer, team or workflow?
Diagnose
Current blocker
What is manual, blocked, risky, slow, expensive or unclear today?
Shape
Useful context
Success signals, non-negotiable constraints, evidence, timeline and budget signal.
Routes
Deployment routes
Derive viable approaches before asking the buyer to choose a person, tool, vendor or service.
Guide summary
What this guide helps you do
Who it is for
Best fit readers
- A founder who needs specialist work done in the next 30-60 days.
The problem
Start with the outcome before choosing a capability route.
Choosing a tool or provider type before the work is understood creates solution bias. A capability brief preserves the outcome, blocker, constraints and evidence of success before route choice.
Step by step
Build the brief around the work.
Start with the outcome
Write what needs to be true when the work is complete.
Describe the current blocker
Explain what is blocked, slow, manual, risky, expensive or unclear today.
Define what good looks like
State the result, handover, measure, decision or visible change that would prove progress.
Add non-negotiable constraints
List only facts that must be true for deployment: security, compliance, integration, data residency, access, location, timeline or procurement boundaries.
Attach useful evidence or signals
Share screenshots, reports, dashboards, current workflow notes, documents, KPIs, examples or process evidence that helps explain the problem.
Stop before choosing the solution
Do not choose AI, human, SaaS, vendor, agency or sector in the first brief unless it is a hard constraint.
Example
Loose request into a stronger brief
Example: “Checkout failures are creating support tickets and abandoned orders. We need failed payments reduced, the causes visible in a weekly dashboard and a clear handover for the internal team.
Template
Capability brief template
Outcome name: What needs to be different: Why this matters / current blocker: What good would look like: Non-negotiable constraints: Useful evidence or signals:
Common mistakes
Avoid these traps
- Starting with a provider label instead of the work.
- Choosing AI, SaaS, vendor or a person before the outcome is clear.
- Listing every possible skill as a hard requirement.
Checklist
Ready to publish when
- The outcome is clear in the first paragraph.
- The current blocker is understandable to someone outside the company.
- Success signals or what good looks like are explicit.
- Non-negotiable constraints are facts, not preferences.
FAQ
Questions this guide usually raises
When should I choose a solution route?
After the outcome, blocker, constraints and success signals are clear enough to compare the available capability routes.
Do I need to know the exact provider type?
No. Describe the outcome and context first.
Take it with you
Share this guide with your team.
Download the PDF for meetings or offline use. The web guide has the latest version.
Share this guide
Use the canonical page link. No social scripts or tracking widgets are loaded.
Use the guide
Turn the work into a capability brief.
Describe the finished outcome, current problem, constraints, timing and budget without choosing the solution too early.
Read the companion blog post
