Mission-First Capability Matching
Define the operational need before choosing the technology
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 95%
Mission-First Capability Matching reframes procurement around the operational outcome rather than the requested object. Carter illustrates the mechanism with a demand for dramatically more drone coverage: after investigating the mission, his team learned that commanders needed persistent observation over fixed locations, not the mobility unique to drones. Tethered balloons could provide that coverage faster, more cheaply, and with less staffing. The same reasoning supported globally sourcing specialized dogs when electronic detection systems were years away. The framework converts a product request into capability requirements, compares alternatives on deployment time and operational fit, fields the simplest adequate option, and then adapts it through frontline feedback.
Origin
Extracted from Masters in Business through Ash Carter's account of rapidly sourcing surveillance systems, armored vehicles, and detection dogs during the Iraq and Afghanistan wars.
Core principles
- 01Start with the outcome rather than the requested product
- 02Separate essential capabilities from preferred technology
- 03Use the simplest option that satisfies the real need
- 04Prioritize deployment speed when delay has serious consequences
- 05Adapt sourcing to the operating environment
How to run it
- 1
Interrogate the request
Ask why the requested product is needed and what users must accomplish. Do not assume the proposed technology is the requirement.
Pro tip Speak directly with frontline users rather than relying only on procurement paperwork.
Watch out Treating a product name as a fixed requirement can eliminate better options before evaluation begins.
- 2
Define the essential capability
Translate the request into measurable operational needs such as persistence, mobility, range, accuracy, staffing, and deployment speed.
Pro tip Distinguish indispensable capabilities from features that are merely desirable.
Watch out An overly broad specification can recreate the expensive solution you are trying to reconsider.
- 3
Generate asymmetric alternatives
Consider simpler, older, commercial, biological, or globally sourced solutions that can deliver the essential capability.
Pro tip Include options that appear unconventional but can be fielded immediately.
Watch out Do not reject a low-tech option solely because a sophisticated option exists.
- 4
Compare total operational burden
Evaluate cost, lead time, personnel, training, maintenance, survivability, and integration rather than purchase price alone.
Pro tip Give deployment time extra weight when lives or critical operations are at risk.
Watch out A technically superior solution may be operationally inferior if it arrives too late.
- 5
Field and adapt
Deploy the adequate solution, collect feedback, and add countermeasures or refinements as conditions change.
Pro tip Let operators identify practical improvements after real-world use.
Watch out Do not let the search for a perfect future system delay a useful present capability.
In the wild
A commander reported having only a fraction of the requested drone coverage. Carter's team investigated and found that the actual need was persistent surveillance over bases and towns. They deployed tethered helium balloons with cameras, sending the feed directly to local commanders, and later added microphones that could locate attackers firing at the balloons.
→ Persistent surveillance was delivered without multiplying expensive drones and flight crews.
Electronic noses were not ready for wartime use, while domestic kennels could not supply enough trained detection dogs. The department identified different working environments, matched breeds and training to those environments, and sourced thousands of dogs globally.
→ Troops received an immediately usable detection capability instead of waiting years for immature electronics.
Common mistakes
Buying the label instead of the capability
Accepting a request for drones, software, or another named product without investigating the underlying mission can lock the organization into unnecessary cost and delay.
Waiting for the perfect system
A five-year development program may be rational in peacetime but useless when the requirement is urgent and a good-enough option is available.
Ignoring operational overhead
Comparisons fail when they omit staffing, maintenance, training, and deployment complexity.
Is it for you?
Best for
It is best for urgent, high-stakes environments where requirements arrive as predetermined product requests.
Not ideal for
It is not ideal when regulation or safety certification requires a specific validated system with no acceptable substitute.
From the transcript
“what do you what do you need all that coverage for that drone coverage?”
“it wasn't to get the kind of film that only a drone could get.”
“You got a ward a fight now, just gotten by yourself a dog.”
From the episode
Ash Carter Discusses the Business of Defense
Ash Carter