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

Перевод: DeepTide TechFlow

Глубокий поток: В Силиконовой долине набирает обороты «пэлантайрование» — стартапы в области ИИ последуют примеру Palantir, отправляя инженеров на площадки клиентов, предлагая высококачественные услуги по индивидуальному заказу и заключая крупные контракты на семь знаков.

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

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

Теперь среди стартапов в BP модно использовать фразу:«По сути, мы являемся Palantir в области X».

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

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

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

Эта статья пытается определить, какие части модели Palantir действительно переносимы, а какие уникальны и не могут быть воспроизведены, а также предоставить более реалистичное руководство для основателей, которые хотят объединить корпоративное ПО с высококонтактными услугами.

Что такое "Палантиризация"

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

Фронтэнд-инженерия

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

Интеграционная платформа с высоким уровнем утверждений

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

Высокотехнологичная и высококонтактная модель продаж

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

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

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

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

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

Сходятся три силы:

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

Огромная часть проектов ИИ застревает до того, как они попадают в эксплуатацию, обычно из-за путаницы с данными, проблем с интеграцией и отсутствия внутреннего лидера. Хотя спрос остается жарким (в правлении и на уровне C-Executives существует реальное вертикальное давление «нужно купить ИИ»), фактическое развертывание и окупаемость инвестиций часто требует огромного объема ручной работы.

2. Инженер по фронтенду, похоже, представляет собой пропавший мост

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

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

Если для получения заказа на сумму более 1 млн. долларов от компании из списка Fortune 500 или государственного органа инженеру нужно сесть на самолёт и приехать на площадку, то многие стартапы на ранних стадиях готовы обменять маржу на динамику. Инвесторы также всё чаще принимают более низкую маржу, поскольку новые AI-опыты часто требуют значительных затрат на вычисления. Ставка в том, что вы получите позицию и доверие у руководства клиента, доставите «результат» и затем сможете установить цену на основе этого.

И повествование превратилось в: «Мы сделаем то, что делал Palantir. Мы отправим элитную группу, создадим что-то волшебное, а затем со временем превратим это в платформу».

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

Хочу продавать «результаты» с самого первого дня

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

Palantir имеет ряд ключевых продуктов:

• Палантир Готэм: Платформа обороны и разведки, помогающая военным, разведывательным и правоохранительным органам интегрировать и анализировать распределенные данные для планирования операций и расследований.
• Палантир АполлонПлатформа для развертывания и управления программным обеспечением, автономно и безопасно отправляющая обновления и новые функции в любую среду (многооблачная, локальная, автономная).
• Palantir FoundryМежотраслевая платформа для работы с данными, объединяющая данные, модели и аналитику, которая обеспечивает принятие решений в бизнесе.
• Палантир онтологияДинамическая манипуляция цифровыми моделями, организующими реальные сущности, отношения и логику, обеспечивающими приложения и принятие решений в Foundry.
• Palantir AIP(Платформа ИИ): связывает модели ИИ (например, крупные языковые модели) с данными и операциями организации через онтологию, создавая производственные ИИ-потоки и агенты.

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

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

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

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

Если вы продаете продукт среднему SaaS-предприятию и оптимизируете его бизнес-процессы на 8%, вы не сможете позволить себе такое же уровень индивидуального внедрения. Пространство возврата на инвестиции вовсе не выдержит месяцы работы инженеров на месте.

Большинству клиентов не хочется быть вашей лабораторией по разработке и исследованию

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

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

Плотность кадров и культура не могут быть универсальными

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

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

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

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

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

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

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

К тому времени вы не будете «Палантир в области X». Вы будете «Эрнест энд Янг в области 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 находится в отдельном отделе «Профессиональные услуги», вы теряете этот цикл обратной связи и скатываетесь в сторону чисто сервисной компании.

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

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

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

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

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

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

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

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

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

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

Более полезным вопросом для основателей является не «Как мы можем стать Палантир?», а:

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

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