Две трети нашей работы по внедрению теперь выполняется автономно нашим собственным продуктом (через Duet).
Этот пост — о том, почему так вышло, о нашей философии создания продукта и подхода к внедрению, а также о том, как это менялось со временем.
То, на что мы раньше смотрели свысока, теперь стало ответом по умолчанию
«Forward deployed engineer» (FDE — инженер, работающий на стороне заказчика) стал ответом почти на любой сложный вопрос в сфере вывода AI-продуктов на рынок. Внедрения болезненны? Нанимайте FDE. Клиенты не могут пользоваться продуктом сами? FDE. Продукт не готов? FDE. И Anthropic, и OpenAI создали корпоративные подразделения внедрения, явно смоделированные по образцу Palantir, и у каждой компании на посевной стадии, с которой я общаюсь, теперь есть вакансия FDE. По сообщениям, количество таких вакансий за последний год выросло на несколько сотен процентов.
Что странно, так это то, что до самого недавнего времени за это критиковали. Развертывание инженеров у клиентов считалось признаком того, что у вас нет настоящего продукта: выручка менее качественная, а маржа структурно ограничена. В базовой экономике ничего не изменилось.
Ключевое в FDE — то, что они приносят результат. В эпоху AI это замечательно, потому что предприятия могут не знать точного пути к результату, но очевидно, что AI дает убедительные результаты.
В то же время эту роль начинают эксплуатировать сверх меры, и она не должна становиться костылем, скрывающим структурную проблему.
«FDE поглощают боль и выдают продукт»
Palantir (откуда пришел мой сооснователь @AshwinSreenivas) популяризировала эту роль в середине 2000-х, продавая Gotham в ЦРУ, АНБ и армейские разведывательные подразделения. И долго терпела критику. Джо Лонсдейл, один из сооснователей, писал, что на протяжении почти двух десятилетий Palantir в глазах большинства была по сути консалтинговой конторой, а не настоящей технологической компанией, — и что этот взгляд основывался на верном наблюдении: многие их инженеры проводили много времени, сидя рядом с клиентами.
Но у Шьяма Санкара, технического директора Palantir, была фраза, которую он постоянно повторял: FDE поглощают боль и выдают продукт.
Ранние внедрения Gotham в Palantir были глубоко кастомизированными — их создавали, чтобы ответить на один разведывательный вопрос для одного подразделения. Palantir превращала увиденные проблемы в примитивы платформы: онтологию, объектные модели, разграничение прав, движки рабочих процессов, отслеживание происхождения данных. Эти примитивы стали Foundry. Foundry стала тем, что можно продавать коммерчески. Apollo и AIP пошли тем же путем.
Ничего из этого не существовало бы без инженеров, которые сначала поглощали боль в поле. Боль была входными данными для продукта, а не стоимостью продажи.
По мере взросления Foundry стандартизированные внедрения резко снизили потребность в кастомной работе, валовая маржа выросла до 80 с лишним процентов, и Palantir отошла от модели, в которой главную роль играли FDE, к продажам на основе аккаунтов. Многие из тех FDE перешли в ключевую инженерную команду. Они также, как известно, отказывались от контрактов, где заказчик просто хотел Accenture с более качественным софтом.
Команда FDE не была бизнес-моделью. Это был способ создать правильный продукт.
Почему некоторым AI-стартапам действительно нужны FDE прямо сейчас
Если бы вы строили SaaS-CRM в 2015 году, вам не нужно было бы открывать рабочий процесс заново. Двадцать лет люди уже продумали, что такое воронка, что такое этап, как выглядит передача лида.
Если вы создаете AI-агента для бухгалтерии в 2026 году, устоявшегося рабочего процесса не существует, потому что буквально никто никогда таким не пользовался. Никто не знает, как выглядит пользовательский путь — ни вы, и, что важно, ни ваш заказчик. Они не могут сказать вам, чего хотят, потому что то, чего они могли бы захотеть, еще не обрело форму.
Это та же ситуация, в которой начинала Palantir. Лонсдейл описывал это так: они пошли в forward deployment по необходимости — у них были сильные технологии и никакого представления о том, как на самом деле работают их ранние оборонные и разведывательные заказчики.
Так что да, отправляйте инженеров. Сидите в одной комнате. Смотрите, как ваш продукт ломается так, как ваши тесты и представить не могли. В по-настоящему новой категории последняя миля — это не проблема доставки, а проблема исследования, и присутствию на месте нет замены.
Ловушка не в том, чтобы начать. А в том, чтобы не остановиться
Как только вы узнали, каковы на самом деле пользовательские пути, вам стоит начать выводить FDE из процесса.
Вам не захочется этого делать. Не потому, что кто-то принимает плохие решения, а потому, что оставить их проще в каждом отдельном спринте.
FDE позволяют избегать каждого сложного продуктового компромисса. Вам никогда не приходится решать, что делает продукт, какая из двух заявок клиента побеждает или где заканчивается пространство конфигурации. Ощущение, что это бесплатно. Никому не приходится никому отказывать. Не принимается ни одного болезненного архитектурного решения. Клиент в восторге.
И вот у вас есть все недостатки модели и ни одного преимущества исследования. Стоимость обслуживания не снижается. Маржа остается ограниченной. Рост ограничен наймом. Каждый кастомный фикс на месте — это продуктовое решение, которое вы решили не принимать. Каждое внедрение должно делать следующее проще.
Вдобавок, очень немногие стартапы способны с ходу закрывать сделки на восьмизначные суммы, как Palantir, из-за чего экономику еще сложнее поддерживать.
Еще одна вещь, которую не стоит путать
FDE — это также не то же самое, что implementation (внедрение). «Сделай эту интеграцию с их тикет-системой» — это настоящая, необходимая работа, но это исполнение по известному ТЗ, а не исследование неизвестного. Объединяя эти две вещи под одним названием, компании убеждают себя, что растущая сервисная организация — это инвестиция в продукт.
Модели теперь пишут код достаточно хорошо, поэтому многое из того, что команда внедрения делала в 2023 году, становится тем, что продукт делает сам. В конечном итоге вы сможете создать агента, который выполнит всю работу на последней миле от начала до конца. Он сможет наблюдать за рабочими процессами и даже опрашивать клиентов.
Что вместо этого сделали мы
В нашем конкретном случае с @DecagonAI мы принципиально убеждены, что ответ — это продуктовый подход, а не сервисный и не ведомый FDE. Поддержка клиентов — высокообъемная, повторяемая и декомпозируемая, и когда мы общаемся с предприятиями, две вещи всегда неизменны:
- Скорость итераций — ключевое. Запуск AI-агента — это не разовое событие. Его постоянно нужно настраивать и обновлять. Если каждая правка требует работы инженеров, масштабирование будет слишком медленным и дорогим.
- Привязка к вендору и суверенность. Учитывая опыт организаций с SaaS, никто не хочет быть привязанным к вендору и зависеть от его ресурсов.
В первые дни мы с Ашвином лично просто создавали все, о чем просили клиенты. Когда продукт встал на ноги, мы приняли осознанное решение, что нашим основным ценностным предложением будет лучший продукт.
Чтобы было понятно: мы по-прежнему в партнерстве с клиентом обеспечиваем результат от начала до конца. Однако даже в этом процессе мы владеем разработкой, обучая их команду работе с нашим продуктом и передавая им ключи. По мере взросления продукта объем кастомизированной работы под конкретного клиента, которую выполняла наша инженерная команда, резко сократился.
У этого решения были свои компромиссы. Оно означало не собирать что-то на коленке на месте, даже когда это было бы быстрее. Оно означало превращать эскалации в требования, а не в патчи, а это занимает время в краткосрочной перспективе.
Результат:
- Две трети работы по внедрению теперь выполняется автономно через Duet: конфигурация, итерации, длинный хвост настройки, который раньше требовал человека в цикле.
- Теперь в среднем нужно всего несколько дней, чтобы запустить первый AOP, даже для крупных банков, авиакомпаний, телекомов и т.д.
Впереди еще много работы, но мы в пути.
Итак: FDE или не FDE?
Идите в forward deployment на раннем этапе. Считайте сигнал. Ставьте своих инженеров перед клиентами постоянно.
Затем задайте настоящие вопросы. Кастомизация — в среде вашего клиента или в пробелах вашего продукта? Последняя миля несократима или просто еще не построена? Ваши FDE что-то исследуют или что-то поглощают? И что было встроено в продукт в прошлый раз, когда один из них вернулся?
Используйте FDE, чтобы понять, что должно существовать в продукте. FDE поглощают боль и выдают продукт. Если ваши поглощают боль и выдают еще больше боли, у вас не команда FDE. У вас сервисный бизнес.
