a16z: За всім, що стоїть за Palantir, — це приречена на провал імітація

Автор: Marc Andrusko

Переклад: Deep潮 TechFlow

Deep潮 Вступ: Кремнієва долина зараз піднімає хвилю «Palantir-ізації» — AI-стартапи масово наслідують Palantir,派 інженерів на місце до клієнтів, надають високорозроблені послуги, підписують багатомільйонні контракти.

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

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

Зараз у BP стартапів популярне висловлювання: «Ми фактично — Palantir у галузі X.»

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

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

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

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

Що означає «Palantir-ізація»

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

Передова інтегрована інженерія

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

Високо орієнтована платформа для інтеграції

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

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

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

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

Дохід формується з багаторічних контрактів, прив’язаних до результату, — поєднання софту, послуг і постійної оптимізації. Одиночний контракт може сягати десятків мільйонів доларів на рік.

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

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

Чому зараз всі прагнуть копіювати Palantir

Збираються три сили:

1. Проблема «реалізації» AI у бізнесі

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

2. Інженери передової лінії — наче зниклий міст

Медіа та вакансії показують, що попит на FDE стрімко зростає — у різних джерелах зростання від 800% до 1000%. AI-стартапи використовують залучення інженерів, щоб зробити впровадження реальним.

3. Швидке зростання стало нормою (більші контракти — легше швидко масштабуватись)

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

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

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

Де не працює аналогія

З перших днів прагнути продавати «результат»

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

Palantir має низку ключових продуктів:

Palantir Gotham: платформа для оборони і розвідки, допомагає військовим, розвідкам і правоохоронним органам інтегрувати та аналізувати розрізнені дані для планування місій і розслідувань.

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

Palantir Foundry: міжгалузева платформа для управління даними, інтегрує дані, моделі та аналітику для підтримки бізнес-рішень.

Palantir Ontology: динамічна модель, що організовує реальні об’єкти, зв’язки і логіку, забезпечуючи роботу застосунків і рішень у Foundry.

Palantir AIP (платформа штучного інтелекту): через Ontology з’єднує AI-моделі (наприклад, великі мовні моделі) з даними і операціями організації, створюючи виробничі AI-робочі процеси і агентів.

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

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

Не кожна проблема — «рівень Palantir»

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

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

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

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

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

Культура і рівень талантів — не для масштабування

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

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

Перейменування передпродажних інженерів у «FDE»

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

Керівництво ніколи не бачило безпосередньо впроваджень Palantir, але любить цей стиль

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

Пастка сервісів — реальна

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

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

Тоді ви не будете «X-галузевим Palantir», а — «X-галузевим Ейзенштейном», просто з більш красивим фасадом.

Що Palantir зробив правильно

Якщо зняти міфологію, є кілька важливих елементів:

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

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

2. Чітке уявлення про «як має» працювати

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

3. Довгострокова перспектива і капітал

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

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

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

Інакше кажучи, Palantir — це не просто «софтверна компанія + консалтинг». Це «софтверна компанія + консалтинг + політичні проекти + дуже терплячий капітал».

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

Більш реалістична модель: коли «Palantir-ізація» стає доцільною

Замість питати «Як зробити нас схожими на Palantir», краще поставити собі кілька ключових питань:

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

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

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

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

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

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

4. Регуляторика і «гравітація» даних

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

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

Що варто вчитися

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

1. Вважайте передову інженерію «каркасом», а не «будинком»

Можна так робити:

— залучати інженерів у співпрацю з ранніми партнерами у ролі embedded

— будь-якою ціною запускати перші 3-5 клієнтів у виробництво

— використовувати цю співпрацю для тестування своїх базових елементів і абстракцій

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

— обмежений час впровадження (наприклад, «90 днів до запуску»)

— ясне співвідношення (наприклад, «на кожен мільйон доларів ARR у одному клієнті — не більше X інженерів»)

— щоквартально перетворювати кастомний код у повторювані конфігурації або шаблони

Інакше «ми згодом зробимо продукт» перетвориться у «ми так і не зробили».

2. Створюйте на основі сильних базових елементів, а не кастомних робочих процесів

Головний урок Palantir — це архітектура продукту:

— уніфікована модель даних і рівень доступу

— універсальні движки робочих процесів і UI-елементи

— максимально використовуйте конфігурацію замість коду

Передова команда має зосередитися на «виборі» і «перевірці» цих базових елементів, а не створювати щось нове для кожного клієнта. Нове — для інженерів.

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

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

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

4. Будьте чесними щодо своєї маржі

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

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

Як я б протестував «Palantir-ізовану» стартап-компанію

Коли засновник каже мені: «Ми — Palantir у галузі X», у мене в нотатнику з’являються такі питання:

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

— Проведіть мене через таймлайн впровадження. Скільки інженер-місяців потрібно від підписання контракту до першого запуску? Що має бути кастомним?

— Який рівень маржі у зрілого клієнта на третій рік? Чи зменшується вклад FDE з часом? Якщо ні — чому?

— Якщо наступного року підпишете 50 клієнтів, де буде «злам»? Найм? Навчання нових? Продукт? Підтримка? Хочу побачити, де модель тріщить.

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

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

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

Заключення

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

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

— проблеми не настільки критичні

— клієнти дуже фрагментовані

— талантова модель не масштабована

— економіка руйнується у сервісний бік

Для засновників важливіше ставити питання: «Що потрібно, щоб подолати AI-розрив у нашій галузі? Скільки Palantir-ізованих передових команд нам потрібно і як швидко перетворити їх у справжній платформений бізнес?»

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