Автор: Марк Андруско

Компіляція: DeepTide TechFlow

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

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

Основний текст:

У бізнес-планах стартапів зараз модним є таке твердження:«Ми, суттєво, є Palantir у галузі X.»

Засновники з ентузіазмом говорять про те, щоб направити «інженерів, розгорнутих на передовій» (Forward-Deployed Engineers, FDE), до клієнтів, створити глибоко налаштовані робочі процеси та працювати як спецпідрозділи, а не як традиційна компанія зі звичайним ПЗ. У цьому році кількість вакансій на «інженерів, розгорнутих на передовій» зросла на сотні відсотків, і всі копіюють модель, яку Palantir ввела на початку 2010-х років.

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

Але я сумніваюся, що «палантирізація» може стати загальною методологією. Palantir — це «категорія одного» (Category of One) — просто подивіться, як торгуються його акції! Більшість компаній, які намагаються наслідувати його, в кінцевому підсумку стають дорогими компаніями з послугами, які оцінюються за коефіцієнтом оцінки програмного забезпечення, але не мають ніякої складної конкурентної переваги. Це нагадує мені 2010-і, коли кожна стартап-компанія казала, що вона — «платформа», але справжніх компаній-платформ насправді було дуже мало, бо це надто складно зробити.

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

Що насправді означає "палантирізація"?

«Палантирізація» почала позначати кілька взаємопов’язаних речей:

Фронтенд-інженерія

Інженери, які працюють на фронті (в Palantir їх називають «Delta» і «Echo»), впроваджуються в організацію клієнта (зазвичай на кілька місяців), щоб зрозуміти бізнес-сценарії, з'єднати різні системи та побудувати настійні робочі процеси на платформі Foundry (або на платформі Gotham у високонадійному середовищі). Оскільки ціни фіксовані, звичайно не існує «SKU», інженери відповідальні за створення та підтримку цих здатностей.

Інтегрована платформа з високим ступенем агресивних пропоз

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

Елітна, висококонтактна модель продаж

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

Продаю результати, а не ліцензії

Доходи надходять з багаторічних контрактів, пов'язаних із результатами, зі змішанням програмного забезпечення, послуг та постійної оптимізації. Контракти з окремими клієнтами можуть досягати мільйонів доларів США на рік.

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

Але до 2025 року всі захочуть залучитися до цього модного тренду.

Три сили зливаються:

1. У підприємницькому ІІ є проблема «впровадження»

Велика частина проектів з штучного інтелекту застрягає до того, як вони потраплять у виробництво, зазвичай через хаотичні дані, проблеми з інтеграцією та відсутність внутрішнього лідера. Незважаючи на захопленість закупівель (існує справжній тиск зверху-вниз «треба купити штучний інтелект» на рівні правління та C-рівня), реальне впровадження та окупність часто вимагають значних ручних зусиль.

2. Інженер з фронт-енд розгортання здається пропущеним мостом

Згідно з даними ЗМІ та залучення персоналу, кількість вакансій FDE цього року стрімко зросла — різні джерела вказують збільшення на 800–1000% — AI-стартапи впроваджують інженерів, щоб справжній розгортання стався.

3. Швидке зростання стало нормою (підписання замовлень на сім знаків простіше, ніж на п'ять, щоб швидко збільшити обсяги)

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

Тож розповідь стала такою: «Ми зробимо те, що зробив Palantir. Ми відправимо елітну групу, створимо чудове, неймовірне, а потім згодом перетворимо це на платформу».

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

Продавати «результат» з першого дня

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

У Palantir є цілий ряд основних продуктів:

• Палантир Готам: Платформа оборони та розвідки, яка допомагає військовим, розвідці та правоохоронним органам зінтегрувати аналіз розсіяних даних для планування операцій та розслідувань.
• Palantir ApolloПлатформа для розгортання та керування ПЗ, яка автономно й безпечно надсилає оновлення та нові функції в будь-яке середовище (мультіклауд, локальне, автономне).
• Palantir FoundryПлатформа операційних даних для різних галузей, що інтегрує дані, моделі та аналітики, щоб стимулювати прийняття рішень у компанії.
• Палантир ОнтологіяДинамічна операційна цифрова модель, що організовує сутності реального світу, відношення та логіку, яка забезпечує діяльність та прийняття рішень у Foundry.
• Palantir AIP(Платформа штучного інтелекту): З'єднуйте моделі штучного інтелекту (наприклад, великі мовні моделі) з даними та операціями організації через онтологію, створюйте продуктивні робочі процеси та агентів, що працюють на штучному інтелекті.

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

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

Не кожна проблема є проблемою рівня «Palantir»

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

Якщо ви продаєте рішення середньому SaaS-підприємству і оптимізируєте його процес продажу на 8%, ви не можете собі дозволити настільки ж високий рівень налаштувань. ROI взагалі не витримає кілька місяців роботи інженерів на місці.

Більшість клієнтів не хочуть бути вашим лабораторією з дослідження та розроб

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

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

Щільність кадрів і культура не можуть бути узагальнені

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

Більшість стартапів не можуть припустити, що вони зможуть найняти сотні таких людей. На практиці, «ми створимо команду FDE-типу Palantir» зазвичай перетворюється на:

• Працівник з рішень до продажу тепер називається «FDE»
• На молодого універсала накладають обов'язки з продукту, впровадження та обслуговування клієнта
• Керівництво ніколи не бачило розгортання Palantir на власні очі, але подобається тон

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

Пастка сервісних послуг є реальною

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

Недооцінені інвестори можуть побачити стрімкий зростання вартості контрактів з нуля до 10 мільйонів доларів і поспіхатимуть потрапити в цей тренд. Але я постійно задаю собі питання: що станеться, коли десятки (а можливо, навіть сотні) таких стартапів на 10 мільйонів доларів почнуть зіткнутися один з одним, використовуючи однакові презентації?

Тоді ви не будете «Palantirом у галузі X». Ви будете «Accenture у галузі X», просто з кращим інтерфейсом.

Якщо відкласти в сторону міфологію, то кілька елементів заслуговують на уважне вивчення:

1. Пріоритетна платформа, а не пріоритетний проект

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

2. Чітко висловлюється думка про те, як «повинна» проходити робота

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

3. Довгострокове бачення та капітал

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

4. Дуже специфічний ринковий портфель

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

Іншими словами, Palantir — це не просто «компанія-розробник ПЗ + консультант». Це «компанія-розробник ПЗ + консультант + політичні проекти + дуже терпляче капіталовкладення».

Це не те, що можна узагальнити, просто приєднавши до вертикального SaaS-продукту.

Ніж запитувати «Як ми стаємо схожими на Palantir», краще поставити ряд підставних запитань:

1. Критичність проблеми

Чи це питання має "критичне значення" (життя людей, національна безпека, десятки мільярдів доларів) чи ж "додатковий плюс" (підвищення ефективності на 10-20%)? Чим вищі ставки, тим більш обґрунтованим є використання моделі, встановленої на передовій.

2. Концентрація клієнтів

Ви продаєте десяткам надзвичайно великих клієнтів чи тисячам малих? Вбудовані інженерні проекти краще розширюються серед зосереджених груп клієнтів із високим ACV (річна вартість контракту).

3. Ступінь фрагментації галузі

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

4. Регулювання та гравітація даних

Ви працюєте в галузі з високим рівнем регулювання, де виникають серйозні проблеми з інтеграцією даних (збройні сили, охорона здоров'я, фінансові злочини, критична інфраструктура)? Саме тут інтеграція типу Palantir може дійсно створити цінність.

Якщо ви переважно знаходитесь в лівому нижньому куті цих вимірів (низька критичність, фрагментовані клієнти, відносно проста інтеграція), то повне "палантирівське" рішення майже напевно є неправильним підходом. У такій ситуації краще підходить вертикальний метод PLG (зростання, зумовлене продуктом).

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

1. Використовуйте передову лінію як ескалатор, а не як будинок

Наступна практика може бути повністю правильною:

• Вбудити інженерів та партнерів з етапу раннього проектування
• Усіма силами залучіть перших 3-5 клієнтів до виробництва
• Використовуйте ці співпраці, щоб перевірити ваші примітиви та абстракції на міцність

Але потрібно встановити чіткі обмеження:

• Часові деплойменти (наприклад, «90-денна штурмова робота до виробництва»)
• Чіткі пропорції (наприклад, «яка максимальна кількість інженерів на одного клієнта на кожні 1 мільйон доларів ARR»)
• Мета періодичного перетворення налаштованого коду в перевикористовувані конфігурації або шаблони

Інакше "ми зробимо це пізніше" перетвориться на "ми ніколи не змогли це зробити".

2. Побудовано на потужних примітивних елементах, а не на налаштованих робочих процесах

Наступна справжня вчителька від Palantir стосується архітектури продукту:

• Уніфікована модель даних та рівень дозволів
• Універсальний двигун робочих процесів та примітиви інтерфейсу
• Наскільки це можливо, використовуйте конфігурац

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

3. Зробити FDE частиною продукту, а не просто доставки

У світі Palantir інженери, розгорнуті на фронті, глибоко включаються в процес виявлення продукту та його ітераційний розвиток, а не тільки в його реалізацію. Міцні організації продуктів і команди платформ отримують поживу з того, чого FDE навчилися на фронті.

Якщо ваше FDE розташоване в окремому відділі «Професійні послуги», ви втрачаєте цикл зворотного зв’язку, а потім зсуваєтеся до чистої компанії з послуг.

4. Будьте щирі у своїй структурі прибутку

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

Для деяких категорій моделі з меншою маржею прибутку, але більшою ACV є повністю раціональними. Проблема полягає в тому, що компанії, які насправді є сервісними платформами, прикидаються SaaS. Інвестори зазвичай оцінюють шлях до максимальної абсолютної суми валового прибутку, і один із способів досягти цього — це укладення більш масштабних контрактів та зростання витрат на товари, що реалізуються (COGS).

Коли засновник казав мені: «Ми Palantir у галузі X», у моєму блокноті виникали запитання приблизно такого типу:

1. Покажи мені межу платформи з твердженням. Де закінчується спільний продукт і починається код, специфічний для клієнта? Як швидко зміщується ця межа?
2. Покажи мені хронологію розгортання. Скільки інженерно-місяців потрібно від укладення договору до першого виробничого використання? Що обов'язково має бути налаштовано?
3. Який валовий прибуток на одного зрілого клієнта у третій рік? Чи зменшили вклади на фронтове розгортання з часом «суттєво»? Якщо ні, то чому?
4. Якщо ми підпишемо 50 клієнтів на наступний рік, де виникне проблема? Найом? Інструктаж для нових працівників? Продукт? Підтримка? Я хочу побачити, де розрив.
5. Як ви приймаєте рішення "ні" про виконання замовлення? Волю відмовитися від роботи на замовлення часто відрізняє компанії-виробники від «підприємств, що надають послуги з гарним демо».

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

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

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

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

• Питання не є критичним
• Клієнти занадто розсіяні
• Модель талантов не може бути масштабованою
• Економічні рахунки тихо руїнуються у службові компанії

Більш корисним запитанням для засновників є не «Як ми стаємо Palantir», а:

«Щоб зменшити розрив у застосуванні ІІ в нашій категорії, скільки розгортань типу Palantir нам потрібно — і наскільки швидко ми зможемо перетворити це на справжню платформу?»

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