All sensitive information has been removed from case study. Due to security processing, all product screenshots are still under review by Kessel Run Security and will not be shown until approval. However, please feel free to ask more questions though!
Background
Dynamic Targeting is an Air Force mission building process involving rapidly identifying and engaging high-priority targets within a matter of minutes. These decisions must be made quickly and collaboratively across distributed roles, each decision with high criticality.
Kessel Run, the Air Force’s software innovation unit, had attempted multiple efforts to create a modern tool for this workflow. Each attempt faced significant challenges: limited user adoption, unclear value, and technical constraints.
The organization needed direction on whether to:
I led the research and strategy effort to recommend an approach that balanced mission value, cost, risk, and feasibility.
TLDR Result
KRADOS lacked the capability to support package planning at scale, initially only supported tagging missions with the same ID in order to show association.
Key Challenges
From initial conversations, we had already noticed some challenges
Limited adoption of prior solutions
Fatigued sentiment of Kessel Run from the numerous attempts
Technical debt and staffing constraints
Lack of clear problem definition
Research
methods
- Interviews with past users and product teams
- Competitive analysis
- Risk, cost, and feasibility analysis
Guiding Questions
- What unmet needs existed?
- Why did prior attempts fail?
- What solution would drive adoption fastest?
Insights
Legacy workflows dominated behavior (interoperability over replacement)
Use case was narrow and episodic, and the doctrinal method was no longer fitting the needs of the operation (value must be embedded in broader workflows)
External tools had strengths, but none were complete (integration-based strategy would yield fastest value)
Proposed Solution
We had two proposed solutions after evaluating the information we received:
Course of action 1 (recommended)
Look into integration with external operating systems. This would be the lowest cost and yield faster results
course of action 2
Revive Chainsaw again. This in theory was easier to do since we had more control in product direction, but in actuality it required more effort due to needing a technical refactor (Chainsaw was created in Golang, but only the ones who programmed knew and they had left the organization, so it would need to be switched to Java for accesibility)
Results
Leadership initially pursued a rebuild (Option 2), which validated our concerns:
- High cost and slow progress
- Significant technical challenges
The organization ultimately pivoted to the recommended integration strategy, resulting in:
- Faster capability deployment
- Reduced redundant development
- Higher adoption via familiar workflows
- Broader shift toward integration-first tracks of work
This work influenced portfolio strategy beyond a single product, accelerating external system integrations that improved mission workflows.
Reflection
This was the first project I did when I entered Kessel Run. Having no knowledge of the military and the domain space we worked in, it took some time to understand how to navigate our problem space. Through overcoming the huge learning curve, I was able to takeaway:
- Modernization in complex domains requires ecosystem thinking, not just feature delivery
- Adoption risk often outweighs technical ambition
- Strategic clarity drives alignment in ambiguous environments
