How to Establish an Unmanned Systems Capability: Start With the Mission, Not the Platform

Ask a struggling unmanned systems program how it started, and the answer is usually the same: with a platform. A demonstration impressed someone, a procurement was launched, aircraft or vehicles arrived—and only then did the hard questions surface. Who operates this? For which missions, under which rules? Who maintains it, with which spares? What happens to the data? A capability that starts with a platform inherits every one of those questions as a crisis. A capability that starts with the mission answers them as design inputs.

Why platform-first fails

A platform is perhaps a fifth of a capability. The rest is the mission definition, the operating concept, the people and their training, the maintenance and support system, the data workflow, and the governance that holds it together. Platform-first programs buy the visible fifth and improvise the rest. The improvisation is where budgets and credibility go to die: missions get retrofitted to the equipment, operators are trained on whatever exists rather than what the task needs, and support is discovered to be unaffordable after the fleet is already on the books.

A mission-first framework

1. State the mission need in operational language. Not “we need drones,” but “we need to inspect this asset class at this frequency with this data quality, in these conditions.” If the need cannot be stated without naming a product, it is not yet understood.
2. Write the concept of operations before any procurement document. Who flies or drives, from where, how often, under which approvals, with which handoffs to the rest of the organization. The CONOPS is where imaginary capabilities collide with real constraints—cheaply.
3. Derive requirements from the CONOPS. Range, endurance, payload, environment, data products, security, and supportability requirements all trace to operational statements. Requirements without that traceability are preferences, and preferences inflate cost.
4. Design the operating model with the system. Staffing, training, maintenance levels, spares philosophy, and data handling are capability components, not afterthoughts. Cost them now.
5. Plan in decision-gated phases. A study phase, a pilot phase, and a scale phase, each with explicit criteria for continuing, redirecting, or stopping. Leadership should commit funds against evidence, one gate at a time.
6. Only now evaluate platforms—or decide to build. With requirements and an operating model in hand, market offerings can be scored honestly, and the build-versus-buy question has an objective basis.

Common mistakes

• Letting a vendor demonstration define the mission instead of the mission defining the evaluation.
• Writing requirements as a wish list rather than deriving them from an operating concept.
• Treating training and maintenance as line items to negotiate down rather than capability components to design.
• Scaling before the pilot phase has produced honest evidence—including evidence of what did not work.
• Ignoring regulatory and approval timelines until they surprise the schedule.

A decision checklist before any major commitment

• Can we state the mission need without naming a product?
• Does a written CONOPS exist, and has someone operationally accountable signed it?
• Do requirements trace to the CONOPS, and are they testable?
• Is the operating model—people, training, maintenance, data—costed across the expected life?
• Are there defined decision gates with criteria for stopping as well as continuing?
• Do we know which approvals we need and how long they realistically take?

None of this slows a program down; it removes the rework that platform-first programs mistake for progress. The mission was always going to have the final word. Starting with it is simply cheaper.