Чи можу я створити корисний продукт для оборонного ринку?

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

Мене звати Галина, я Head of Delivery у Growth Factory. Останні пів року я працюю з освітніми продуктами у сфері DefTech / MilTech — не як дослідниця ззовні, а як людина, яка щодня говорить із фаундерами, військовими, інженерами, юристами, фондами, маркетплейсами й командами, які тільки думають про вхід у цей ринок.

Спочатку мені здавалося, що я просто збираю освітню програму. Але з кожною розмовою ставало зрозуміліше: насправді я збираю карту входу в дуже складний ринок.

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

За цими питаннями я чую одне спільне: «А чи можу саме я створити тут щось корисне?»

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

З чим ви заходите в MilTech

Людина може мати сильну мотивацію, гроші, досвід в IT або доступ до реальних потреб. Але цього ще не завжди достатньо, щоб створити продукт.

Hardware-інженер може самостійно зробити перший зразок, але не розуміти бізнес-модель, продажі чи роботу з користувачами. Військовий може дуже добре знати проблему, але без технічного партнера не дійти до прототипу. Власник IT-компанії може мати команду, процеси й гроші, але не розуміти військовий контекст.

Мотивація в усіх може бути однакова. Стартові позиції — зовсім різні.

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

Чи є технічна спроможність, доступ до користувачів, команда чи бюджет на перші ітерації? Є людина, яка зможе оцінити, чи моя ідея технічно можлива?

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

Для людей із IT тут є хороша новина: наш досвід може бути корисним далеко за межами написання коду. Організувати роботу, тримати фокус, тестувати гіпотези, працювати з клієнтами, документувати процеси — усе це теж потрібно.

Водночас досвід у розробці софту не закриває автоматично питання електроніки, embedded чи виробництва, якщо вони є частиною задуму.

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

Чи справді ця проблема потребує нового продукту

В мілтек не треба штучно вигадувати проблеми. Вони є щодня. Військові, волонтери, фонди, виробники постійно бачать речі, які болять прямо зараз.

Але справжня проблема ще не означає, що навколо неї вдасться побудувати продукт.

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

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

У MilTech мало почути: «нам це потрібно». Потрібно зрозуміти, кому саме, у яких умовах, як часто, чим це зараз замінюють, хто може заплатити, хто впливає на рішення і що має статися, щоб продукт реально дійшов до використання.

Хто користуватиметься продуктом, а хто його купить

Військовий користувач, покупець і платник — це часто різні люди. Цю річ легко недооцінити, якщо раніше ви працювали з продуктами, де шлях від користувача до оплати був коротшим.

У вас може бути військовий, який каже: «Це нам потрібно». Але він не завжди людина, яка ухвалює рішення про закупівлю. Фонд може профінансувати першу партію. Інший виробник — стати партнером або інтегратором. Державна закупівля — бути окремим шляхом.

Тому схвальний відгук ще не відповідає на запитання, як саме продукт потрапить до користувача.

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

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

Чи готові ви змінити свою ідею

Люди рідко приходять у MilTech із порожніми руками. У когось уже є ідея продукту. Хтось приносить технічну концепцію. Хтось давно думає про конкретний пристрій або програмне рішення. Деякі команди вже мають перші компоненти, розрахунки чи прототип.

Це створює відчуття хорошого старту. Є мотивація, напрям і бажання якомога швидше почати розробку.

Але сильна прив’язаність до рішення може стати пасткою.

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

На слайді ідея може виглядати переконливо. У розмові з майбутнім користувачем — розсипатися за кілька хвилин.

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

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

На що має відповісти перший прототип

Багато хто думає: головне — зробити перший зразок. Але перший прототип — це не фінал. Це спосіб отримати чесну відповідь від реальності.

Виріб може працювати на столі. Може працювати в лабораторії. Може один раз нормально спрацювати на полігоні. І все одно бути дуже далеким від продукту.

Бо лабораторія, полігон і реальні умови — це різні світи.

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

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

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

Чи можна довіряти продукту

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

Як команда формулює запит до військових? Що просить показати? Чи пояснює, навіщо збирає інформацію? Чи розуміє, що не все можна записувати, пересилати, публікувати або показувати інвесторам?

Іноді команда може втратити довіру ще до того, як покаже продукт, — через те, як вона поводиться з інформацією.

Ці ж питання переходять і в розробку. Які дані збирає виріб? Де вони зберігаються? Хто має до них доступ? Що буде, якщо пристрій втратять? Чи не створює продукт додатковий ризик для військового? Чи можна безпечно показувати демо?

У MilTech питання не лише в тому, чи працює функція. Питання ще й у тому, чи не робить вона користувача більш вразливим.

Коли просити зворотний зв’язок

Ще одна річ, яку я часто помічала в розмовах із командами, — бажання спочатку щось добре допрацювати, а вже потім показувати іншим.

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

Але саме тут можна втратити багато часу.

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

Тому дедалі більше мені подобається інша логіка: показувати раніше.

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

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

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

У цьому сенсі швидкість у MilTech для мене теж почала означати дещо інше.

Це не тільки про те, як швидко команда зібрала перший прототип. Це ще й про те, як швидко вона отримала достатньо інформації, щоб помітити хибне припущення, відмовитися від нього й піти іншим шляхом.

Що для мене змінилося за ці пів року

Коли я тільки починала занурюватися в цей ринок, питання звучало досить широко: «Чи можу я створити щось корисне для оборони?»

Зараз між цим бажанням і реальним продуктом я бачу набагато більше проміжних кроків.

Там є розмови з військовими й перевірка потреби. Інженерні обмеження й пошук компонентів. Перші прототипи, які можуть не пережити випробування. Питання безпеки, виробництва, грошей і закупівель. Фонди, гранти, маркетплейси, інвестори. І багато моментів, коли відповідь буде «ні».

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

За ці пів року питання «Чи можу я створити корисний продукт для оборонного ринку?» стало для мене набагато конкретнішим.

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

Не обов’язково мати всі відповіді на старті. Але варто бути готовими їх шукати — і змінювати задум, коли реальність із ним не погоджується.

Саме про цю відстань між «хочу зробити щось корисне» і реальним продуктом мені хочеться писати далі.

Окремо хочу розібрати, як IT-компанії заходити в MilTech і не нашкодити основному бізнесу, чому позитивний відгук військового ще не завжди означає ринкову потребу, де шукати технічного партнера, скільки насправді може коштувати шлях до першого робочого прототипу та як зрозуміти, що команда справді рухається до продукту, а не просто багато робить.

Мені хочеться, щоб ця колонка була розмовою. Якщо ви вже пробували створювати продукт для оборони, що виявилося найменш очевидним? А якщо тільки придивляєтеся до MilTech — на яке питання вам зараз найбільше бракує відповіді?