Deployed Works Guide
Platform & trustCapability Brief Or Technical Scope?
Use a capability brief while the route is open, then a technical scope when the outcome and delivery constraints justify one.
Capability Brief Or Technical Scope? guide trailer
A short walkthrough for this guide will appear here.
Audience
Platform & trust
Founders, operators, capability buyers, technical owners and finance-conscious leads
Time
2 minute read
Outcome
Use a capability brief while the route is open, then a technical scope when the outcome and delivery constraints justify one.
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
Brief Comparison Matrix
Choose the document that matches the work.
Use this comparison to choose an outcome-led capability brief, a detailed technical scope or a short clarification exercise.
Capability brief
Best when the route is open
- The outcome is clear
- Several delivery forms could work
- A first result can be described
- Budget and timing have useful signals
- The buyer wants route recommendations
Technical scope
Best for delivery detail
- Systems, data or dependencies need detail
- Acceptance signals need to be defined
- The team needs to explain constraints before a provider call
- Requirements are useful but not yet procurement-ready
- The detail can strengthen a capability brief
Clarify first
Best when essentials are missing
- The outcome is still broad
- No internal owner is named
- Success cannot yet be measured
- Access or decision boundaries are unknown
- A short diagnostic would create useful signal
Guide summary
What this guide helps you do
Who it is for
Best fit readers
- A founder deciding how to express a live operational need.
The problem
Shared platform language needs clear boundaries.
Teams lose time when an unclear outcome is forced into a detailed specification too early, or when technical work is shared without enough constraints for a provider to assess it. The right starting format depends on what is already known.
Step by step
Use the platform reference clearly.
Start with the finished outcome
Name what should be different, what is blocking progress and how success will be recognised.
Choose a capability brief when the route is open
Use a capability brief when there is a real outcome, a timeline, a budget signal and a need for useful capability, but several delivery forms could work.
Choose a technical scope when delivery detail is known
Use a technical scope when systems, data, dependencies, security boundaries and acceptance criteria are material to deciding fit.
Clarify before matching when essentials are missing
Pause route acceptance when nobody owns the outcome, success cannot be measured or key access and constraints are unknown.
Keep one outcome lineage
Whichever format you use, preserve the same outcome, blocker, success signals and constraints so later route choice, matching, proposal and completion records remain connected.
Example
One outcome, two useful levels of detail
Capability brief: Our sales-to-onboarding handoff is creating delays. We need account setup completed within one working day, with fewer manual checks and clear ownership.
Template
Route choice worksheet
Work need: What progress is needed in the next 30-60 days? What capability is missing internally? What systems, data or constraints matter? What would good look like after the first phase? Best starting format: - Capability brief:
Common mistakes
Avoid these traps
- Choosing a provider type before the outcome is understood.
- Listing tools and seniority without explaining the outcome.
- Writing a detailed technical scope before the success signal is clear.
Checklist
Ready to publish when
- The first useful outcome is written in plain English.
- The internal owner is named.
- Technical systems, constraints and acceptance signals are captured if relevant.
- The chosen format preserves the outcome lineage.
FAQ
Questions this guide usually raises
Is a capability brief always enough?
No. A technical scope is useful when systems, dependencies, data and acceptance criteria materially affect provider fit or delivery risk.
What if we cannot define success yet?
Use a short clarification exercise. Do not accept a capability route or begin matching until the outcome and decision boundary are understandable.
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
Use the platform reference in practice.
Use a capability brief while the route is open, then a technical scope when the outcome and delivery constraints justify one.