Реальна потреба ще не створює ринок: як обирати сегмент у defence tech

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Мене звати Катерина Безсудна, з 2023 року я активно розвиваю defence tech в Україні, працювала у Brave1, виступила співзасновницею українського стартапу Buntar Aerospace, що займається виготовленням розвідувальних дронів та ПЗ до них, а також співзасновницею та CEO Defence Builder — акселератора оборонних стартапів (нині операційно не залучена в діяльність компаній). З вересня 2025 року очолюю офіс виробника дронів TEKEVER в Україні.

Я бачила український оборонний ринок зсередини чотирьох різних структур: стартапу, акселератора, державної екосистеми та міжнародної компанії. І помітила у всіх спільну помилку — команда знаходить реальну проблему, створює прототип, отримує позитивний відгук від військових і вирішує, що ринок уже підтверджений.

Насправді між потребою та ринком є кілька обов’язкових ланок. Військовий може потребувати рішення щодня. Гроші при цьому перебувають у розпорядженні іншої інституції, контракт підписує третя, техніку приймає на баланс четверта, а за навчання, ремонт і списання відповідає п’ята. Кожна сторона має власні критерії, ризики та горизонт планування.

Тому замість питання «наскільки велика наша технологічна категорія?» я ставлю інше: «у якому конкретному сегменті критична потреба вже має джерело фінансування, доступний шлях закупівлі та вимоги, які ми здатні виконати?»

Домен — ще не сегмент

Команди часто називають своїм ринком «дрони», «наземні роботи», «РЕБ» або «військовий зв’язок», але це технічні домени. Вони показують середовище застосування рішення та майже нічого не кажуть про комерційну можливість.

В одному домені можуть співіснувати продукти з різною місією, користувачем, ціною, закупівельником і циклом продажу. Тактичний розвідувальний БпЛА для підрозділу та оперативна система спостереження для державного замовника належать до повітряного домену, однак фактично працюють на різних ринках. У них різні вимоги до дальності та стійкості зв’язку, різний рівень інтеграції із системами управління, різні процедури випробувань, навчання й сервісу.

Практична межа сегмента проходить там, де продукти:

• вирішують одну й ту саму місію або дають зіставний операційний ефект;
• претендують на те саме джерело бюджету;
• проходять подібний шлях закупівлі;
• порівнюються з тим самим набором альтернатив.

Останній пункт особливо важливий, оскільки конкурентом може бути інший виробник, дешевший цивільний продукт, ручний процес, внутрішня розробка підрозділу або рішення «нічого не змінювати». Якщо команда не може пояснити, з чим її продукт реально порівнює закупівельник, межі сегмента ще не визначені.

Спочатку відновіть повний ланцюг рішення

Перш ніж оцінювати мільярдні ринки, варто намалювати шлях одного майбутнього контракту. Для оборонного продукту я перевіряю щонайменше п’ять ролей.

• Користувач. Хто безпосередньо застосовує систему: оператор, екіпаж, технічна служба, штаб або навчальний центр? Саме користувач найкраще описує умови місії та реальні відмови продукту.
• Платник. Звідки надходять кошти: державний бюджет України, партнерська держава, міжнародна програма, фонд, бюджет підрозділу чи приватна компанія? Наявність потреби без визначеного платника залишає команду з підтримкою користувачів, але без прогнозованої виручки.
• Закупівельник. Яка юридична особа має право провести процедуру й підписати договір? Її вимоги можуть суттєво відрізнятися від очікувань оператора.
• Балансоутримувач. Хто прийме техніку, вестиме облік і відповідатиме за її рух? Ця ланка впливає на документи, комплектацію, приймання та подальше списання.
• Відповідальний за експлуатацію. Хто організує навчання, ремонт, оновлення програмного забезпечення, постачання запчастин і зворотний зв’язок? Без цього навіть успішна перша поставка може не перетворитися на повторне замовлення.

Для кожної ролі потрібні три відповіді: конкретна сторона, доказ її участі та умова, за якої ця сторона погодить наступний крок. Формулювання «Міноборони купить» або «військові хочуть» надто загальні. Команда має знати, хто ініціює потребу, хто погоджує бюджет, хто формує технічні вимоги, хто підписує контракт і хто приймає результат.

Корисно одразу позначити найслабшу ланку

В одному випадку нею буде відсутність бюджетної програми, в іншому — невідповідність вимогам закупівельника, брак кодифікації, виробничої готовності або сервісної моделі. Саме слабка ланка, а не загальний інтерес до технології, найчастіше визначає швидкість виходу на ринок.

Перш ніж назвати цифру, уточніть, що саме вона вимірює

Оборонний ринок легко переоцінити, якщо складати показники з різною економічною природою. У публічних дискусіях словом «ринок» позначають обсяг виробленої продукції, виробничий потенціал, фінансування закупівель та інвестиції в компанії.

Наприклад, KSE Institute у спільному з Brave1 і Defence Builder дослідженні оцінив сукупний обсяг трьох українських високотехнологічних сегментів у 2025 році у $6,8 млрд. Йдеться про БпЛА, наземні роботизовані комплекси та засоби РЕБ. Близько $6,3 млрд із цієї суми припало на БпЛА, $252 млн на НРК, $220 млн на РЕБ. Оцінка охоплює саме ці три сегменти, але не описує всю українську оборонну промисловість.

Те саме дослідження наводить $6,1 млрд іноземного фінансування українського ОПК у 2025 році. Ця цифра описує джерело коштів для виробництва й закупівель. Її не можна додавати до $6,8 млрд як окрему частину ринку: частина профінансованої партнерами продукції вже відображається в обсязі виробництва.

Ще один показник — приблизно $129 млн інвестицій і грантів, залучених українськими defence tech-компаніями у 2025 році. Це капітал для досліджень і розробок (R&D), найму, обладнання та масштабування. Поставлена на фронт продукція оплачується з інших джерел.

Окремо існує виробничий потенціал. У червні 2025 року Президент України повідомляв, що загальний потенціал оборонного виробництва перевищив $35 млрд і охоплював широкий спектр — від артилерії та бронетехніки до дронів і ракет. За цією ж заявою, близько 40% цього потенціалу на той момент залишалися без належного фінансування.

Оцінку у $35 млрд методологічно некоректно безпосередньо порівнювати з $6,8 млрд трьох високотехнологічних сегментів, бо різняться і межі сектору, і тип показника. Водночас сам факт незавантажених потужностей підсвічує системну проблему — виробнича спроможність може зростати швидше, ніж фінансований попит.

На рівні окремої компанії до цих визначень варто додати ще три:

• TAM — усі витрати на відповідну місію або категорію у вибраній географії;
• SAM — частина TAM, якій продукт відповідає за стандартами, характеристиками, географією та закупівельним каналом;
• SOM — обсяг, який команда реально здатна отримати у визначений період з урахуванням доступу до замовника, готовності продукту, виробничої спроможності й конкуренції.

Великий TAM корисний для розуміння довгострокового потенціалу. Для плану продажів і потреби в капіталі значно важливіший доказовий SOM. Саме на цьому рівні стає видно, скільки контрактів компанія здатна виграти і який обсяг замовлень виготовити, поставити та підтримати.

Неповний ринок оцінюють діапазоном

У defence tech повної статистики майже не буває. Частина контрактів закрита, суми не розкриваються, закупівельні канали фрагментовані, а частина виробництва безпосередньо у підрозділах узагалі не проходить через формальні ринкові операції. Але відсутність повних даних не звільняє команду від оцінки. Виходячи з цього, робоча оцінка має містити діапазон, ключові припущення та рівень упевненості. Я використовую тріангуляцію з трьох груп даних.

Top-down: від бюджету й програм закупівель

Команда бере доступний оборонний бюджет або обсяг конкретної програми й визначає частку, що може припадати на потрібну місію. Цей підхід дає верхню рамку. Але треба розуміти, що згадка категорії в бюджеті ще не означає, що вся сума доступна конкретному продукту. Частину можуть забрати інші класи систем, чинні рамкові угоди, сервіс, боєприпаси або пріоритетні постачальники.

Top-down оцінка має відповідати на запитання: який бюджет теоретично обслуговує цю місію, яка його частина доступна нашому класу продуктів і через який канал вона витрачається?

Bottom-up: від реального сценарію розгортання

Тут оцінку будують знизу: кількість потенційних користувачів або підрозділів множиться на кількість систем, потрібних одному користувачу, частоту заміни чи оновлення та повну вартість контракту. Для складного продукту до ціни платформи додаються навчання, запасні частини, наземне обладнання, програмне забезпечення, інтеграція й сервіс.

Bottom-up модель швидко показує, які припущення найбільше впливають на результат. Часто головна невизначеність ховається не в кількості потенційних користувачів, а в нормі забезпечення, циклі заміни, ціні інтеграції або реальній частоті повторної закупівлі.

Непрямі сигнали: підтвердження напряму руху

Корисними сигналами можуть бути кількість закупівель і випробувань, публічні пріоритети замовників, нові виробничі майданчики конкурентів, вакансії, партнерства, строки постачання критичних компонентів, грантові програми та поява відповідної категорії у бюджетах союзників.

Кожен сигнал має альтернативне пояснення. Зростання вакансій може означати новий контракт, заміну команди або запуск нового напряму досліджень і розробок. Участь у міжнародній виставці свідчить про активний розвиток партнерств і продажів, але не гарантує угоди. Черга на компонент може бути наслідком загального попиту або проблеми одного постачальника.

Тому один сигнал не є доказом. Я шукаю щонайменше два-три незалежні джерела, які вказують в один бік. Підсумок має звучати приблизно так: «Оцінюємо доступний сегмент у діапазоні від X до Y; top-down і bottom-up моделі збігаються в межах Z%; рівень упевненості — середній; найбільша невизначеність — частота повторних закупівель».

Позначки High, Medium і Low confidence корисні лише разом із поясненням. Офіційний бюджет може мати високий рівень довіри як факт, але низький рівень придатності для оцінки частки конкретного продукту. Кілька інтерв’ю дають якісне розуміння проблеми, проте не доводять масштаб платоспроможного попиту.

Перетворення технологічної категорії на сегмент

Щоб описати сегмент достатньо точно, я використовую карту з восьми осей.

1. Місія та ефект. Яку операційну задачу вирішує продукт і який вимірюваний результат покращує: час виявлення, дальність спостереження, імовірність виконання місії, зниження ризику для людей, вартість одного ефекту?

2. Користувач. Хто працює із системою, у яких умовах, з якою підготовкою та якими обмеженнями? Вимоги оператора на передовій, аналітика у штабі й техніка ремонтного підрозділу можуть конфліктувати, тому «військовий» — недостатньо точний портрет користувача.

3. Платник. Яке джерело грошей фінансує саме цю місію? Потрібно знати назву інституції, бюджетний цикл, програму, обмеження та передбачуваність фінансування.

4. Закупівельник. Хто юридично укладає договір, визначає кваліфікаційні умови й приймає фінансовий ризик? Саме тут з’являються вимоги до документів, гарантій, локалізації, комплаєнсу та строків.

5. Домен. У якому фізичному або цифровому середовищі працює рішення: повітря, земля, море, кіберпростір, електромагнітний спектр, космічні дані? Домен потрібен для технічної рамки, але самостійно сегмент не визначає.

6. Продуктовий шар. Компанія продає платформу, компонент, корисне навантаження (payload), програмне забезпечення, дані, сервіс, навчання чи комплекс «під ключ»? Компонент і готова система мають різних покупців, маржу, цикл інтеграції та відповідальність за результат.

7. Географія та стандарти. Де продукт можна законно й технічно застосовувати? Для України, країн НАТО та цивільного ринку відрізнятимуться кодифікація, сертифікація, експортний контроль, вимоги до безпеки даних і сумісності.

8. Шлях закупівлі та зрілість. Як рішення потрапить до замовника: через тестування, грант, прямий контракт, рамкову угоду, міжурядову програму чи інтеграцію з великим виробником? Чи відповідають цьому шляху рівень технологічної готовності (TRL), доказ бойового застосування та виробнича готовність?

Після заповнення карти ставлю собі контрольне запитання: «Хто забере цей бюджет, якщо замовник не обере нас?» Якщо відповідь містить десятки несхожих технологій, сегмент залишається надто широким. Якщо є три-п’ять реальних альтернатив з подібною місією та шляхом закупівлі, межі вже придатні для роботи.

Найбільший сегмент рідко є найкращим для першого виходу

Перший сегмент варто оцінювати за ймовірністю пройти весь шлях до контракту й повторних поставок. Максимальна місткість на слайді тут другорядна. Одну й ту саму безпілотну платформу можна позиціонувати для тактичної розвідки, охорони кордону, експорту до союзної держави або цивільного моніторингу інфраструктури. Апарат може залишатися схожим, але продуктова пропозиція зміниться: інше корисне навантаження, інтеграція, сертифікація, навчання, сервіс, ціна й доказ цінності.

Я порівнюю потенційні сегменти за сімома критеріями:

• критичність місії та наслідки невирішеної проблеми;
• наявність підтвердженого бюджету й закупівельного механізму;
• доступ команди до користувача, платника та закупівельника;
• тривалість циклу від першого контакту до контракту;
• обсяг додаткових випробувань, інтеграції та сертифікації;
• економіка повного життєвого циклу, включно із сервісом;
• перевага команди: дані, технологія, ланцюг постачання, партнерство або досвід місії.

Кожен критерій можна оцінити за п’ятибальною шкалою, але бал має спиратися на доказ. «Маємо контакти» означає доступ до конкретних ролей у ланцюгу рішення. «Є бюджет» означає відому програму, закупівельний план, оплачений пілот або контрактний механізм. «Високий попит» означає повторювану поведінку закупівельників. Позитивних відгуків користувачів для цього недостатньо.

Перший сегмент може згодом стати основою для виходу в інші. Його завдання дати компанії найкоротший доказовий цикл: застосування, вимірюваний результат, контракт, повторна поставка та дані для наступного ринку. Спроба одночасно адаптувати продукт до чотирьох сегментів зазвичай розпорошує продуктовий план і залишає кожному замовнику напівготове рішення.

Тренд має змінювати продуктовий план лише через місійний доказ

Оборонний ринок змінюється швидше, ніж тривають звичні продуктові цикли. Через це продуктовий план легко перетворити на перелік хайпових слів. Щоб цього не сталось, тренд варто розкласти на послідовний ланцюг: сигнал → причина → вплив на місію → продуктове рішення → спосіб перевірки.

Візьмімо стійкість до РЕБ. Поява нової технології зв’язку сама собою ще не означає, що треба змінювати архітектуру продукту. Спочатку потрібно з’ясувати, де й за яких умов чинний канал підводить команду та зриває виконання місії. Потім — оцінити, як альтернатива вплине на вагу, дальність, логістику й вартість системи. Тільки тоді можна ухвалювати продуктове рішення та визначати, як його перевірити.

Так само з автономністю. Цим словом часто описують системи, у яких людина досі ухвалює критичні рішення. Тому продуктовому менеджеру важливо розуміти реальний рівень автоматизації: що система робить самостійно, коли відмовляє, яких даних потребує, як поводиться під впливом РЕБ і за різних погодних умов, за що відповідає оператор. Без чітко визначених меж застосування слово «автономність» лише завищує очікування і створює хибні критерії приймання.

Інтероперабельність теж легко заявити, але значно складніше підтвердити. Інтеграція повітряних і наземних платформ із системами командування та управління залежить від протоколів, форматів даних, прав доступу, кібербезпеки й процедур тестування. Про реальну екосистемність можна говорити тоді, коли інтерфейси задокументовані, а інтраційні випробування дають стабільний і відтворюваний результат.

Ще один важливий урок із моєї практики стосується надійності та постачання. Сумісність зі старим парком компонентів може здаватися перевагою. Проте для серійного виробу важливі також ресурс, ремонтопридатність і доступність комплектуючих.

Зрештою, головний критерій продуктового рішення зводиться до того, чи буде система готова виконувати місію протягом усього життєвого циклу. Зручність окремої інтеграції цього не гарантує.

Як перевірити сегмент до великих інвестицій

Перша ринкова теза може вміститися на одній сторінці. У ній мають бути сім блоків.

1. Одне речення про сегмент. Для кого, у якій місії, у якій географії та через який закупівельний шлях працює продукт.
2. Ланцюг рішення. Користувач, платник, закупівельник, балансоутримувач і відповідальний за експлуатацію. Для кожного — відомий контакт або спосіб отримати перевірені дані.
3. Карта восьми осей. Вона фіксує межі продукту й показує, які адаптації справді потрібні.
4. Оцінка ринку. Top-down і bottom-up моделі, діапазон, рівень упевненості та три припущення, які найбільше впливають на результат.
5. Конкурентний набір. Прямі продукти, інші технологічні способи виконати місію та варіант «нічого не змінювати».
6. План доказів. Інтерв’ю з представниками всіх ролей, дані про попередні закупівлі, технічні випробування, підтвердження бюджету, вимоги до приймання та оцінка сервісного навантаження.
7. Критерії рішення. Які факти дозволять інвестувати в сегмент, які вимагатимуть змінити пропозицію, а які стануть підставою відмовитися від напряму.

Інтерв’ю варто будувати навколо минулої поведінки та реальної процедури. Запитуйте, як замовник востаннє розв’язував цю проблему, хто ініціював закупівлю, з якого бюджету її оплачували, що заблокувало або прискорило договір, як оцінювали результат і хто обслуговував систему. Відповідь «ми б купили» має невелику вагу без кількості, строку, джерела коштів і повноважень співрозмовника.

П’ять умов реального ринку

Ринок для defence tech-продукту виникає там, де сходяться п’ять умов: критична місія, визначений користувач, підтверджене джерело фінансування, легальний і прохідний шлях закупівлі та продукт, який команда здатна серійно поставляти й підтримувати.

Якщо однієї з умов бракує, перед командою залишається ринкова гіпотеза. Це нормальний стан для нового продукту. Ризик починається тоді, коли гіпотезу закладають у виробничий план, оцінку компанії та прогноз продажів як підтверджений попит.

Сильна defence tech-команда швидко створює технологію, точно визначає місію, бачить увесь ланцюг рішення, чесно працює з невизначеністю й збирає докази в правильному порядку. За цієї послідовності реальна потреба перетворюється на контракт, контракт — на повторюване виробництво, а окремий продукт — на стійку компанію.