Автор: Marc Andrusko

Компиляция: Deep Tide TechFlow

Введение от Deep Tide: В Кремниевой долине набирает обороты тренд «Palantir-изации» — стартапы в области ИИ один за другим подражают Palantir, отправляя инженеров к клиентам, предоставляя высококастомизированные услуги и заключая контракты на семь цифр.

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

Содержание:

Сейчас в бизнес-планах стартапов流行一句话:«Мы, по сути, Palantir в области X.»

Основатели с энтузиазмом рассказывают об отправке «инженеров передового развёртывания» (Forward-Deployed Engineers, FDE) к клиентам, создании глубоко кастомизированных рабочих процессов и работе как спецподразделение, а не как традиционная софтверная компания. В этом году количество вакансий для «инженеров передового развёртывания» взлетело на сотни процентов — все копируют модель, которую Palantir开创 в начале 2010-х.

Я понимаю, почему этот подход привлекателен. Корпоративные клиенты сейчас ломают голову над тем, «какое ПО купить» — всё называет себя ИИ, и никогда ещё не было так сложно отделить сигнал от шума. Метод продаж Palantir заманчив: десантировать небольшую команду в хаотичную среду, соединить разрозненные, самодельные системы и за несколько месяцев交付定制ную рабочую платформу. Для стартапа, желающего заключить свой первый контракт на семь цифр, обещание «мы пошлём наших инженеров в вашу организацию, чтобы всё уладить» — это мощный аргумент.

Но я сомневаюсь, что «Palantir-изацию» можно推广作为 универсальной методологии. Palantir — это «категория в себе» (Category of One) — просто посмотрите, как торгуются её акции! Большинство компаний, копирующих лишь внешние атрибуты, в конечном итоге превратятся в дорогие сервисные компании с мультипликаторами оценки софтверного бизнеса, но без каких-либо сложных конкурентных преимуществ. Это напоминает мне 2010-е годы, когда каждый стартап называл себя «платформой», но настоящих платформенных компаний было极 мало, потому что их очень сложно построить.

Эта статья призвана прояснить, какие части модели Palantir действительно можно移植, а какие настолько уникальны, что их нельзя скопировать, а также предоставить более прагматичный路线图 основателям, желающим сочетать корпоративное ПО с услугами, требующими высокого уровня вовлечённости.

Что на самом деле означает «Palantir-изация»

«Palantir-изация» стала обозначать несколько взаимосвязанных вещей:

Встроенное инженерное обеспечение на передовой

Инженеры передового развёртывания (внутри Palantir их называют «Delta» и «Echo») внедряются в организацию клиента (обычно на несколько месяцев), изучают бизнес-сценарии, соединяют различные системы и создают定制ные рабочие процессы на платформе Foundry (или на платформе Gotham в высокозащищённых средах). Поскольку ценообразование фиксированное и традиционно нет «SKU», инженеры отвечают за создание и поддержку этих возможностей.

Высоко-предписывающая интеграционная платформа

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

Элитная, высококонтактная модель продаж

«Palantir-изация» также описывает стиль продаж: длинные, высококонтактные циклы продаж, целевые клиенты — среды с критически важными задачами (оборона, правоохранительные органы, разведка и т.д.). Сложность регулирования и величина «ставок» в отрасли — это особенность, а не ошибка.

Продажа результата, а не лицензий

Доход поступает от многолетних контрактов, привязанных к результатам, где смешаны ПО, услуги и постоянная оптимизация. Контракты с отдельными клиентами могут достигать десятков миллионов долларов в год.

Недавний анализ определил Palantir как «категорию в себе», потому что она одновременно做到了 три вещи на высочайшем уровне: (a) построила интегрированную продуктовую платформу, (b) внедрила элитных инженеров в операции клиентов, (c) доказала свою состоятельность в критически важных правительственных и оборонных средах. Большинство компаний могут сделать одну или две из этих вещей, но невозможно сделать все три одновременно.

Но к 2025 году все хотят примазаться к ореолу этой модели.

Почему сейчас все хотят копировать Palantir

Собираются три силы:

1. У корпоративного ИИ есть проблема «внедрения»

Значительная часть проектов ИИ застревает до попадания в производственную среду, обычно из-за хаотичных данных, головной боли интеграции, отсутствия внутреннего ответственного лица. Хотя желание закупать по-прежнему狂热ное (на уровне советов директоров и топ-менеджмента есть реальное давление «сверху вниз» — «必须买 ИИ»), фактическое развёртывание и ROI часто требуют大量 ручной работы.

2. Инженеры передового развёртывания выглядят как недостающий мост

Сообщения в СМИ и данные о найме показывают взрывной рост вакансий FDE в этом году — по разным источникам, от 800% до 1000% — стартапы в области ИИ внедряют инженеров, чтобы обеспечить реальное развёртывание.

3. Быстрый рост стал нормой (заключить контракт на семь цифр проще, чем на пять, для быстрого масштабирования)

Если отправка инженеров в командировки к клиенту — это цена за заключение контракта на сумму более 1 миллиона долларов с компанией из списка Fortune 500 или государственным учреждением, многие ранние компании готовы пожертвовать валовой прибылью ради импульса. Инвесторы также всё более接受更低的 валовую прибыль, поскольку новые возможности ИИ часто требуют значительных затрат на инференс. Ставка такова: вы сможете завоевать расположение и доверие руководства клиента,交付 «результат», а затем установить цену исходя из этого.

Таким образом, нарратив становится таким: «Мы сделаем то, что делал Palantir. Мы пошлём элитный отряд, создадим нечто волшебное, а со временем превратим это в платформу.»

Эта история может сработать в очень специфических обстоятельствах. Но есть некоторые жёсткие ограничения, которые основатели часто обходят стороной.

Где аналогия даёт сбой

С первого дня хотят продавать «результат»

Флагманский продукт Palantir, Foundry, — это комбинация сотен микросервисов, работающих вместе для достижения результата. Эти микросервисы формируют продуктизированные, принципиальные решения общих проблем предприятий в различных областях. За последние два года я встретил сотни основателей приложений ИИ, и я могу сказать, где аналогия разрывается: стартапы приходят и представляют一堆 грандиозных целей, основанных на результате, в то время как Palantir сначала осознанно строит микросервисы, которые формируют краеугольные камни её основных возможностей. Именно это отличает Palantir от обычной консалтинговой компании (и именно поэтому она торгуется с оценкой в 77 раз больше выручки следующего года).

У Palantir есть ряд核心 продуктов:

• Palantir Gotham: Платформа для обороны и разведки, помогающая военным, разведывательным и правоохранительным органам интегрировать и анализировать разрозненные данные для планирования операций и расследований.
• Palantir Apollo: Платформа для развёртывания и управления ПО, которая автономно и безопасно推送 обновления и новые функции в любую среду (мультиоблако, локальная, отключённая среда).
• Palantir Foundry: Кросс-отраслевая платформа для операций с данными, интегрирующая данные, модели и аналитику для управления операционными решениями предприятий.
• Palantir Ontology: Динамическая, действенная цифровая модель сущностей, отношений и логики реального мира, которая питает приложения и решения внутри Foundry.
• Palantir AIP (Искусственный интеллект платформа): Соединяет модели ИИ (такие как большие языковые модели) с данными и операциями организации через Ontology, создавая производимые рабочие процессы и агенты, управляемые ИИ.

Цитируя тот отчет Everest: «Контракты Palantir начинаются с малого. Первое взаимодействие может быть просто коротким учебным курсом и ограниченными лицензиями. Если ценность подтверждается, затем добавляется больше случаев использования, рабочих процессов и областей данных. Со временем структура доходов смещается от услуг к подписке на ПО. В отличие от консалтинговых компаний, услуги являются средством продвижения продукта, а не основным источником дохода. В отличие от большинства поставщиков ПО, Palantir готова авансом вкладывать своё инженерное время, чтобы заполучить значимых клиентов.»

С одной стороны, компании-приложения ИИ, которые я вижу сейчас, часто могут сразу перейти к контрактам на семь цифр. Но с другой стороны, это в основном потому, что они находятся в режиме полной кастомизации — они решают любые проблемы, которые бросают им ранние клиенты, надеясь потом обнаружить в этом темы для построения核心 возможностей или «SKU».

Не каждая проблема — это проблема «уровня Palantir»

Области раннего развёртывания Palantir — это те, где альтернатива — «ничто не работает»: борьба с терроризмом, обнаружение мошенничества, логистика на поле боя, высокорисковые медицинские операции. Ценность решения проблемы измеряется в миллиардах долларов, количестве спасённых жизней или геополитических последствиях, а не в приростной эффективности.

Если вы продаёте средней SaaS-компании, помогая оптимизировать её sales-процесс на 8%, вы не можете позволить себе аналогичный уровень定制ного развёртывания. Пространство для ROI просто не выдерживает месяцев работы встроенных инженеров.

Большинство клиентов не хотят вечно вашей R&D лабораторией

Клиенты Palantir по умолчанию принимают совместную эволюцию продукта; они многое терпят, потому что ставки высоки, а альтернатив有限.

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

Плотность талантов и культура не поддаются обобщению

Palantir потратила более десяти лет на招募 и обучение исключительно сильных инженеров-универсалов, которые могут писать продакшен-код, ориентироваться в бюрократии и сидеть в одной комнате с полковниками, CIO и регуляторами. Ушедшие с этой должности сформировали целую группу основателей и executives «банды Palantir». Многие из них уровня единорога, потому что они одновременно высокотехнологичны и чрезвычайно эффективны перед клиентом.

Большинство стартапов не могут假设, что наймут сотни таких людей. На практике «мы создадим команду FDE в стиле Palantir» часто вырождается в:

• Пре-сейл инженеры-решения, переименованные в «FDE»
• Младших универсалов, от которых требуют одновременно заниматься продуктом, внедрением и управлением клиентами
• Руководство, которое никогда близко не видело развёртывания Palantir, но любит этот образ

Надо чётко сказать, что есть множество очень талантливых людей, и такие инструменты, как Cursor, позволяют нетехническим сотрудникам писать код. Но чтобы масштабировать модель Palantir, требуется чрезвычайно дефицитное слияние бизнес- и технических талантов, и опыт работы в Palantir очень помогает, потому что это очень уникальная компания. Но количество этих людей ограничено!

Сервисная ловушка реальна

Palantir работает, потому что под кастомизированной работой лежит настоящая платформа. Если вы копируете только часть с внедрением инженеров, в конечном итоге у вас будут тысячи定制ных развёртываний, которые невозможно поддерживать или обновлять. Даже в мире, где инструменты ИИ позволяют компаниям достигать软件级 валовой прибыли в такой модели, те, кто слишком сильно склоняется к передовому развёртыванию без сильного продуктового позвоночника, могут не генерировать возрастающую отдачу от масштаба и устойчивое конкурентное преимущество.

Недискриминирующие инвесторы могут увидеть хоккейную клюшку роста контрактной стоимости с 0 до 10 миллионов долларов и броситься участвовать. Но вопрос, который я всегда задаю, таков: что произойдёт, когда десятки (или даже сотни) таких 10-миллионных стартапов начнут сталкиваться друг с другом с одинаковыми питчами?

К тому времени вы не «Palantir в области X». Вы «Accenture в области X», только с более красивым интерфейсом.

Что Palantir сделала действительно правильно

Если отбросить мифологию, есть несколько элементов, заслуживающих внимательного изучения:

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

Команды передового развёртывания Palantir строят на основе небольшого набора переиспользуемых примитивов (модели данных, контроль доступа, движки рабочих процессов, компоненты визуализации), а не пишут полностью定制ные системы для каждого клиента.

2. Чёткое представление о том, как работа «должна» выполняться

Эта компания не просто автоматизирует существующие процессы; она часто подталкивает клиентов к новым способам работы, и само ПО воплощает эти принципы. Для поставщика это редкая смелость, и она делает возможным повторное использование.

3. Долгосрочное видение и капитал

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

4. Очень специфическое сочетание рынков

Раннее присутствие в сферах разведки и обороны — это особенность, а не ошибка: высокая готовность платить, высокие затраты на переход, высокие ставки и очень небольшое количество очень крупных клиентов. Не говоря уже о устаревших конкурентах, которые десятилетиями几乎 не сталкивались с конкуренцией при заключении сделок.

Другими словами, Palantir — это не просто «софтверная компания + консалтинг». Это «софтверная компания + консалтинг + политический проект + чрезвычайно терпеливый капитал».

Это не то, что можно随便 привить к вертикальному SaaS-продукту и обобщить.

Более реалистичная框架: когда «Palantir-изация» оправдана

Вместо вопроса «Как нам стать похожими на Palantir» лучше задать серию пороговых вопросов:

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

Является ли эта проблема «критически важной» (жизни, национальная безопасность, миллиарды долларов) или «приятным дополнением» (10-20% повышение эффективности)? Чем выше ставки, тем более оправдан режим передового развёртывания.

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

Вы продаёте десяткам очень крупных клиентов или тысячам мелких? Встроенное инженерное дело лучше масштабируется в集中нной, с высоким ACV (годовая стоимость контракта) клиентской базе.

3. Степень фрагментированности области

Похожи ли рабочие процессы между клиентами, используют ли они одинаковое ПО, или каждое развёртывание fundamentally разное? Если каждый клиент — это снежинка, сложно построить последовательную платформу. Помогает некоторая степень однородности.

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

Работаете ли вы в высоко регулируемых областях с выраженными болевыми точками интеграции данных (оборона, здравоохранение, финансовая преступность, критическая инфраструктура)? Именно там интеграционная работа в стиле Palantir может создать реальную ценность.

Если вы в основном находитесь в левом нижнем углу этих измерений (низкая критичность, фрагментированные клиенты, относительно простая интеграция), полная «Palantir-изация» — это почти наверняка неправильная модель. В этом случае больше подходит подход снизу вверх, PLG (Product-Led Growth).

Чему стоит поучиться

Хотя я сомневаюсь, что каждая ранняя компания сможет успешно развернуть модель Palantir, в этом подходе есть несколько моментов, которые стоит рассмотреть:

1. Используйте передовое развёртывание как строительные леса, а не как дом

Совершенно правильно делать следующее:

• Заставлять инженеров работать встроенно с ранними партнёрами по дизайну
• Делать всё возможное, чтобы первые 3-5 клиентов вышли в продуктив
• Использовать это сотрудничество для стресс-тестирования ваших примитивов и абстракций

Но нужны чёткие ограничения:

• Ограниченные по времени развёртывания (например, «90-дневный спринт до продакшена»)
• Чёткое соотношение (например, «максимум X человеко-инженеров на одного клиента на каждые 1 миллион долларов ARR»)
• Цель ежеквартально преобразовывать定制ный код в переиспользуемые конфигурации или шаблоны

Иначе «мы потом продуктизируем» превратится в «мы так и не дошли до этого».

2. Стройте на основе сильных примитивов, а не定制ных рабочих процессов

Настоящий урок Palantir заключается в продуктовой архитектуре:

• Унифицированная модель данных и уровень разрешений
• Универсальные движки рабочих процессов и UI-примитивы
• По возможности использовать конфигурацию, а не код

Команды передового развёртывания должны тратить время на «выбор» и «проверку» того, какие примитивы собрать, а не на создание совершенно новых вещей для каждого клиента. Создание с нуля оставьте инженерам.

3. Сделайте FDE частью продукта, а не просто доставки

В мире Palantir инженеры передового развёртывания глубоко вовлечены в обнаружение и итерацию продукта, а не только во внедрение. Сильная продуктовая организация и команды платформы питаются тем, что FDE узнают на передовой.

Если ваши FDE сидят в отдельном отделе «профессиональных услуг», вы теряете эту обратную связь и скатываетесь к чисто сервисной компании.

4. Будьте честны в отношении структуры валовой прибыли

Если ваш питч предполагает 80%+ валовой прибыли по программному обеспечению и 150% удержания чистого дохода, но ваша модель продаж фактически требует долгосрочных проектов с размещением на месте, будьте прозрачны в отношении компромиссов — по крайней мере, внутри компании.

Для некоторых категорий структурно более низкая валовая прибыль и более высокий ACV — это完全 рациональная модель. Проблема в том, чтобы притворяться SaaS, будучи на самом деле сервисной компанией с платформой. Инвесторы обычно смотрят на путь к максимальной величине валовой прибыли в абсолютном выражении, и один из способов достичь этого — это контракты на порядок большего размера плюс более значительные COGS (себестоимость проданных товаров).

Как бы я стресс-тестировал стартап, занимающийся «Palantir-изацией»

Когда основатели говорят мне «Мы — Palantir в области X», вопросы в моём блокноте примерно такие:

1. Покажите мне границу принципиальной платформы. Где заканчивается общий продукт и начинается клиентский特定ный код? Как быстро движется эта граница?
2. Проведите меня по временной шкале развёртывания. Сколько человеко-месяцев инженеров требуется от подписания контракта до первого использования в продакшене? Что должно быть定制ным?
3. Какова валовая прибыль зрелого клиента на третий год? Существенно ли со временем снижаются затраты на передовое развёртывание? Если нет, то почему?
4. Если в следующем году вы подпишете 50 клиентов, что сломается? Найм? Обучение новичков? Продукт? Поддержка? Я хочу увидеть, где модель треснет.
5. Как вы решаете «не» кастомизировать? Готовность сказать «нет»定制ной работе часто является ключом к различаю продуктовую компанию и «сервисную компанию с красивым демо».

Если эти ответы ясны, основаны на реальных развёртываниях, архитектурно последовательны, то определённая степень передового развёртывания в стиле Palantir может быть настоящим преимуществом.

Если ответы расплывчаты или очевидно, что каждое сотрудничество полностью уникально, нам трудно поручиться за повторяемость или真正 потенциал масштабирования.

Заключение

Успех Palantir создал мощный ореол, который доминирует в духе венчурного стартап-сообщества: элитные инженерные отряды десантируются в сложную среду, связывают воедино хаотичные данные и交付 системы, меняющие способ принятия решений в организации.

Легко поверить, что каждая компания в области ИИ или данных должна выглядеть так. Но для большинства категорий полная «Palantir-изация» — это опасная фантазия:

• Проблема недостаточно критична
• Клиенты слишком фрагментированы
• Модель талантов не масштабируется
• Экономика незаметно проваливается в сервисную компанию

Для основателей более полезный вопрос не «Как нам стать Palantir», а:

«Сколько передового развёртывания в стиле Palantir нам нужно, чтобы преодолеть разрыв в принятии ИИ в нашей категории — и как быстро мы сможем превратить это в настоящий платформенный бизнес?»

Сделав это правильно, вы сможете позаимствовать действительно важные части этого подхода, не унаследовав те, которые вас задавят.