How a frontline signal becomes an engineering task. A column by Defence Builder Accelerator Director Yana Shkvarovska

What do defence tech developers need to understand about the specifics of military testing, and how should they respond to requests from the frontline and feedback from military personnel?

Recently, Defence Builder Accelerator Director Yana Shkvarovska returned from a working trip to the Donetsk region, where she worked with brigade and battalion commanders, operators and workshop managers together with DeepStateUA co-founder Roman Pohorilyi. She shared some of the lessons from the trip in this column for Defender Media.

In 2025, the Ukrainian Armed Forces received more than 500 applications from manufacturers as part of specialised testing programmes. According to the Central Department of Innovation Activity of the Armed Forces, only about half of field tests can be considered successful.

Testing is supposed to identify problems and verify claimed characteristics before a product enters serial production and begins to be used systematically. What is more interesting is the stage at which these problems emerge.

In several cases shared by military personnel, testing of the product’s main function never even began. The system failed to start properly, shut down shortly after launch or lost its connection before completing the test route.

How a product handles transportation, deployment or loss of communications can be checked earlier and at a lower cost. If a team discovers such problems only in the field, one possible reason is that the requirements specified range and payload but did not include a complete operational scenario. Other factors may include build quality, component integration, environmental conditions or user training.

Recently, together with DeepStateUA co-founder and Defence Builder Advisory Board member Roman Pohorilyi, I worked in Donetsk region with brigade and battalion commanders, operators and workshop managers. The details of those conversations will be omitted from this text for security reasons, but not the methodology behind the work.

Why I don’t ask what solution is needed

During this trip, the conversations were open: I primarily listened to what military personnel were willing to share. When working with a request afterwards, I do not start by asking, “What solution do you need?” because that immediately frames the problem around a specific product, while the first step should be understanding the problem itself. It is important to determine what task the unit performs, what outcome needs to be improved, what prevents this from happening, what has already been tried and why the solution did not become a sustainable practice.

The answers gradually reveal who directly encounters the problem, under what scenario it occurs and what questions still need to be checked. The outcome of the first conversation does not always have to be a ready-made technical specification. Often, a more honest result is a structured description of the problem, the required effect, the context and the constraints. Technical requirements come later.

To build a more complete picture, I try to bring together at least three perspectives whenever possible. A brigade or battalion commander is concerned with capability — what outcome is needed, what has the highest priority and where technology can reduce risks to personnel. An operator sees what the system is worth in everyday use and how it performs under conditions other than demonstrations. A workshop manager sees the lifecycle: what breaks after delivery, how much the quality varies between batches, how long repairs take and whether spare parts are available. These perspectives may not coincide, but that does not mean someone is wrong. They describe different parts of the same system, and it is at their intersection that a more realistic engineering task emerges.

The state already collects some of this data. The DOT-Chain Defence rating system is one channel for structured military feedback: authorised users can rate drones and describe their experience with them, including ease of operation, build quality, and resistance to interference. Brave1 Market analytical dashboards provide manufacturers participating in the “Army of Drones.Bonus” programme with statistics on strikes, e-Balls and a product’s position among its counterparts. But these data do not replace information on repairability, batch-to-batch variation, spare parts and the workload placed on workshops. This aspect remains underrepresented in the channels available to us, even though it is essential to understanding a product’s full operational suitability.

When a request becomes a development focus

There is no fixed threshold after which a request becomes a focus area for an accelerator cohort. Under our working framework, as long as a request comes from a single unit or environment, we treat it as a frontline signal and check whether it is repeated elsewhere and whether different people describe the same required effect, even if they use different words. A product developed for a single unit risks limited applicability unless that specialisation was a deliberate design choice from the outset.

We also test whether a recurring request is realistic — whether the solution is technologically achievable and can be tested within the programme. At the same time, we determine whether it duplicates an already available solution.

For some teams, months pass between entering the programme and testing in a relevant environment. Therefore, when defining cohort focus areas, we do not try to predict the future precisely. Instead, we build a portfolio of working hypotheses over a 6- to 12-month horizon. During that time, tactics, enemy countermeasures, component availability and the teams’ technological capabilities all change. But we treat these needs as hypotheses and review them regularly.

More than 110 applications were submitted to the accelerator‘s third cohort, from which we selected 10 teams. Here is one example: a team joined with a different product, but after assessing its engineering expertise, capabilities, and existing developments, we found it could be more useful for a specific military request — improving the protection of an existing platform against a particular class of threats. We recommended changing its focus and supported the team with resources, expert context, partnerships and other support specifically needed for this development. At the time of writing, the team has a working prototype and is moving to testing with the military.

There was no ready-made technical specification at the start, so the task was refined iteratively. Once the necessary details have been clarified, the working brief should describe all aspects important for use: the required effect, integration context, constraints, user workload, expected behaviour in the event of failure and the testing scenario. Without the last two points, it is difficult to define an acceptable outcome and determine what to do in the event of abnormal system behaviour.

Before the first field test

Once the brief has been prepared and the prototype assembled, a separate readiness check is needed before going to the test site. Its purpose is to eliminate all questions that do not require a relevant field environment. For a mobile unmanned or robotic platform, a basic checklist could look like this:

• Can the product withstand transportation to the position in its standard packaging?
• Does it complete the relevant functional cycle — from deployment to return or safe shutdown?
• Does it maintain communications, and how does it behave after losing the connection?
• How much time and how many people are required for deployment?
• Is it compatible with equipment already used by the unit?

In presentations, teams talk about range, autonomy and algorithms, but these advantages may never be tested if the system starts unreliably, requires disproportionately complex deployment or cannot withstand the basic operational scenario.

If a problem does emerge at the test site, it is not a catastrophe — the purpose of the test site is precisely to test assumptions under relevant conditions. A failure becomes useful data when the team records at what stage it occurred, under what conditions, whether it is repeated on other units, and then identifies the source: the design, component, software, settings, integration, environment or, for example, user training.

Such an analysis can lead to updates to both the product and its requirements. Requirements may be expanded to include, for example, expected behaviour after a change in conditions, safe shutdown or the ability to quickly identify the cause of a failure. Specific parameters should remain within the closed testing programme.

The worst thing that can be done after an unsuccessful test is to repeat it without a new hypothesis, changes to the product or refined criteria. The test result may lead to further development, a change in requirements, a reassessment of the concept itself or a decision to stop the project. A negative test is not a verdict on the team, but neither is it an automatic reason to continue without changes.

Waste is when a test site once again discovers something that could have been established earlier and more cheaply. A conversation with a unit and a brief that includes a complete operational scenario are also considered engineering work. They do not guarantee success, but they reduce unnecessary iterations and increase the chances of reaching a useful solution through proper testing.

Yana Shkvarovska

Defence Builder Accelerator Director

• LinkedIn