Дві третини нашої роботи з розгортання тепер виконується автономно нашим власним продуктом (через Duet).
Цей пост про те, чому так відбувається, про нашу філософію побудови продукту та підходу до розгортання, і про те, як усе це змінювалося з часом.
Те, на що ми колись дивилися зверхньо, тепер є відповіддю за замовчуванням
«Forward deployed engineer» (інженер передового розгортання, FDE) став відповіддю майже на кожне складне питання у виведенні ШІ на ринок. Розгортання болючі? Наймайте FDE. Клієнти не можуть впоратися самостійно? FDE. Продукт не готовий? FDE. Anthropic і OpenAI обидва створили підрозділи корпоративного розгортання, явно змодельовані на Palantir, і кожна компанія на ранній стадії, з якою я спілкуюся, тепер має вакансію FDE. За повідомленнями, кількість таких вакансій за останній рік зросла на кілька сотень відсотків.
Що дивно, так це те, що ще зовсім нещодавно за це критикували. Відправлення інженерів до клієнтів вважалося ознакою того, що у вас немає справжнього продукту: ваш дохід був нижчої якості, а маржа структурно обмежена. У базовій економіці нічого не змінилося.
Ключова особливість FDE — вони забезпечують результат. Це чудово в епоху ШІ, адже підприємства можуть не знати, яким шляхом іти до результату, але очевидно, що ШІ дає переконливі результати.
Водночас ця роль стає надто вживаною і не має бути милицею, щоб приховати структурну проблему.
«FDE поглинають біль і виділяють продукт»
Palantir (звідки прийшов мій співзасновник @AshwinSreenivas) популяризував цю роль у середині 2000-х, продаючи Gotham у ЦРУ, АНБ та армійські розвідувальні підрозділи. І вони довго терпіли критику. Джо Лонсдейл, один із співзасновників, писав, що протягом більшої частини двох десятиліть мейнстрімне уявлення про Palantir полягало в тому, що це прикрашений консалтинг, а не справжня технологічна компанія, і що це уявлення ґрунтувалося на правдивому спостереженні: багато їхніх інженерів проводили багато часу, сидячи поруч із клієнтами.
Але Шьям Санкар, CTO Palantir, постійно повторював одну фразу: FDE поглинають біль і виділяють продукт.
Ранні розгортання Gotham у Palantir були глибоко індивідуальними: вони створювалися, щоб відповісти на одне розвідувальне питання для одного підрозділу. Palantir закодував проблеми, які вони бачили, як примітиви платформи: онтологія, об'єктні моделі, керування дозволами, рушії робочих процесів, відстеження походження даних. Ці примітиви стали Foundry. Foundry стало продуктом, який можна було продавати комерційно. Apollo та AIP пішли тим самим шляхом.
Нічого з цього не існувало б, якби інженери спершу не поглинали біль, працюючи на місцях у клієнтів. Біль був вхідними даними для продукту, а не витратами на продаж.
Коли Foundry дозрів, стандартизовані розгортання різко скоротили потребу в кастомній роботі, валова маржа піднялася до 80%, і Palantir перейшов від моделі, що спирається на FDE, до продажів, орієнтованих на ключових клієнтів. Багато з тих FDE перейшли в основну інженерію. Вони також, як відомо, відмовлялися від контрактів, де клієнт просто хотів Accenture з кращим програмним забезпеченням.
FDE-команда не була бізнес-моделлю. Вона була способом створити правильний продукт.
Чому деяким ШІ-стартапам дійсно потрібні FDE вже зараз
Якби ви будували SaaS CRM у 2015 році, вам не потрібно було б досліджувати робочий процес. Двадцять років люди вже продумали, що таке воронка продажів, що таке етап, як виглядає передача лідів.
Якщо ви будуєте ШІ-агента для бухгалтерії у 2026 році, усталеного робочого процесу не існує, бо буквально ніхто ніколи не користувався такими інструментами. Ніхто не знає, як виглядає шлях користувача — ні ви, і, що важливо, ні ваш клієнт. Вони не можуть сказати вам, чого хочуть, бо те, чого вони хотіли б, ще не має форми.
Це та сама ситуація, з якої починав Palantir. Лонсдейл описував це так: вони пішли в передове розгортання з необхідності — мали сильну технологію і жодного уявлення про те, як насправді працюють їхні ранні оборонні та розвідувальні клієнти.
Тож так, надсилайте інженерів. Сидіть у тій самій кімнаті. Дивіться, як ваш продукт ламається так, як ваші тести навіть не уявляли. У справді новій категорії остання миля — це не проблема доставки, а проблема дослідження, і перебуванню поруч немає заміни.
Пастка не в тому, щоб почати. Пастка — у тому, щоб не зупинитися.
Щойно ви дізнаєтеся, якими насправді є шляхи користувачів, вам слід починати прибирати FDE.
Вам цього не захочеться. Не тому, що хтось ухвалює погане рішення, а тому, що залишати FDE легше в кожному спринті.
FDE дають змогу уникати кожного складного продуктового компромісу. Вам ніколи не доводиться вирішувати, що робить продукт, який із двох запитів клієнта перемагає, або де закінчується простір налаштувань. Це здається безкоштовним. Нікому не доводиться відмовляти. Жодне болісне архітектурне рішення не ухвалюється. Клієнт у захваті.
І тепер ви маєте всі недоліки цієї моделі, але жодної переваги від дослідження. Ваша вартість обслуговування не знижується. Ваші маржі залишаються під стелею. Ваше зростання обмежене наймом. Кожне кастомне виправлення на місцях у клієнта — це продуктове рішення, яке ви вирішили не ухвалювати. Кожне розгортання має полегшувати наступне.
До того ж дуже мало стартапів можуть закривати угоди на вісім цифр, які Palantir укладав із самого початку, тож економіку стає ще складніше підтримувати.
Ще одне, що не варто плутати
FDE — це також не те саме, що впровадження. «Створіть цю інтеграцію з їхньою тікет-системою» — це реальна необхідна робота, але це виконання за відомою специфікацією, а не дослідження невідомої. Об'єднуючи ці дві ролі під однією назвою, компанії переконують себе, що зростаючий сервісний відділ — це інвестиція в продукт.
ШІ-моделі тепер пишуть код достатньо добре, тож значна частина того, що команда впровадження робила у 2023 році, стає тим, що продукт робить сам. Зрештою, ви зможете створити агента, який виконуватиме всю роботу на останній милі від початку до кінця. Він зможе спостерігати за робочими процесами і навіть інтерв'ювати клієнтів.
Що ми зробили натомість
У нашому конкретному випадку з @DecagonAI ми принципово віримо, що відповідь — це продуктовий підхід, а не сервісний чи підхід, що спирається на FDE. Обслуговування клієнтів — високооб'ємне, повторюване та розкладне на складові завдання, і коли ми говоримо з підприємствами, дві речі завжди незмінні:
- Швидкість ітерацій — ключ до успіху. Запуск ШІ-агента — це не разова подія. Його постійно потрібно налаштовувати й оновлювати. Якщо кожне налаштування потребує інженерної роботи, масштабування буде надто повільним і дорогим.
- Прив'язка до вендора та суверенність даних. З огляду на досвід організацій із SaaS, ніхто не хоче бути прив'язаним до вендора й залежати від його ресурсів.
На ранньому етапі ми з Ашвіном особисто просто будували все, що просили клієнти. Коли продукт став на ноги, ми ухвалили чітке рішення, що наша ключова ціннісна пропозиція — це найкращий продукт.
Для ясності: ми все ще партнеримо з клієнтом, щоб забезпечити результат від початку до кінця. Однак навіть у цьому процесі ми беремо на себе розробку, допомагаючи їхній команді освоїти наш продукт і передаючи їм ключі. У міру того як продукт дозрівав, обсяг специфічної для клієнта роботи, яку виконувала наша інженерна команда, різко скоротився.
Це рішення мало свої компроміси. Воно означало не збирати щось нашвидкуруч у клієнта, коли так було б швидше. Воно означало перетворювати ескалації на вимоги, а не на патчі, що в короткостроковій перспективі забирає час.
Результат:
- Дві третини роботи з розгортання тепер відбувається автономно через Duet: конфігурація, ітерації, довгий хвіст налаштувань, які раніше потребували участі людини в циклі.
- Для запуску першого AOP тепер у середньому потрібно лише кілька днів, навіть для великих банків, авіакомпаній, телеком-операторів тощо.
Ще багато роботи попереду, але ми на цьому шляху.
Тож: FDE чи не FDE?
Ідіть у передове розгортання на ранньому етапі. Впіймайте сигнал. Ставте своїх інженерів перед клієнтами назавжди.
Тоді поставте справжні питання. Чи кастомність криється в середовищі клієнта, чи в прогалинах вашого продукту? Чи остання миля невід'ємна, чи вона просто ще не збудована? Чи ваші FDE щось досліджують, чи просто поглинають біль? І що потрапило в продукт минулого разу, коли один із них повернувся?
Використовуйте FDE, щоб зрозуміти, що має існувати в продукті. FDE поглинають біль і виділяють продукт. Якщо ваші FDE поглинають біль і виділяють ще більше болю, то у вас не FDE-команда. У вас сервісний бізнес.
