Forward Deployed PM: почему за ними охотятся AI-гиганты Не успели мы привыкнуть к новой роли Product Builder, как на горизонте замаячила новая волна интереса к роли Forward Deployed Product Manager (FDPM). Разбираю, что это такое. 1. Кто такой FDPM и чем он занимается? Обычный PM сидит в офисе своей компании и отвечает за продукт вообще. FDPM десантируется прямо на сторону клиента. Он погружается в реальный операционный хаос заказчика, сидит с его сотрудниками, разбирает их инфраструктуру и отвечает за бизнес-результат конкретного аккаунта. Посадить продуктовика с ценником FDPM внутрь клиента - дорогой шаг, поэтому FDPM отправляют только в два типа аккаунтов: 1. Tier-1 Enterprise (High-LTV): клиенты с чеком $500k – $1M+ ARR, уход которых критичен для бизнеса. 2. Бета-проходцы новых AI-продуктов: когда запускается сложная модель или интеграция, а рынок еще не понимает, как внедрять софт по стандартным инструкциям. Для малого и среднего бизнеса эта модель не применяется, там работают стандартный Self-Serve и отдел CSM. 2. Что по зарплате и вакансиям * Динамика роста: на платформе The Bench число вакансий с формулировкой Forward Deployed выросло с 1 открытой позиции в январе до 170 активных ролей в 98 компаниях к концу июля. * Кто и где нанимает: основной спрос сосредоточен в США (Bay Area, Нью-Йорк, Вашингтон), Великобритании (Лондон) и европейских хабах вроде Берлина и Амстердама. Нанимают Scale AI, Salesforce, Adobe, Accenture, Cresta и Palantir. * Зарплаты: вилка базового оклада для FDPM в США варьируется от $180,000 до $250,000+ (в Scale AI на Public Sector вилка доходит до $345,000). 3. Примеры открытых вакансий Посмотреть на требования и задачи этой роли на рынке можно на листингах: Tribe AI - Forward Deployed Product Manager : транслировать сложнейшие задачи клиентов в готовые продуктовые AI-решения и вести внедрение вместе с продуктовой командой. Sela AI - Forward Deployed Product Manager: отвечать за внедрение AI-агентов под ключ, пересобирая их под то, как реально работают банковские процессы у клиентов. CruxOCM - Forward Deployed Product Manager: работать с техническими лидами заказчика, использовать AI-инструменты для прототипирования и переводить спецификацию конкретного завода в фичи бэклога. Causal Labs - Forward Deployed Product Manager: вести ключевые запускные проекты для требовательных enterprise-клиентов и замыкать кастомные решения на ядро системы. 4. Окей, открываю позицию FDPM. Как нам не скатиться в заказную разработку? Главный риск для FDPM - уйти в бесконечное пиление кастома под одного громкого заказчика. Чтобы защитить ядро платформы, используют правило триангуляции: 1. Быстрый костыль: решаем проблему конкретного клиента локальным кодом или скриптом прямо сейчас. 2. Валидация: ищем, повторяется ли эта проблема у других 3–5 клиентов платформы. 3. Экстракция в Core: если боль системная, фича уходит в бэклог основной платформы. Если она нужна только одному заказчику, то остается локальным костылем на его стороне. Источник: https://www.mindtheproduct.com/what-is-a-forward-deployed-product-manager-anyway/ @productgames

Онбординг агентов в Enterprise кодовые базы на миллионы LoC Вместе с Максимом Ключниковым (Этихлид) поделились своим опытом о том, как добиться максимум эффективности от AI агентов на больших легаси проектах. Я рассказывал про построение тезауруса и борьбу с тех долгом, а также поделился неочевидными результатами наших бенчмарков, измеряющих эффективность контекстных движков (векторный RAG, графовый RAG). Во второй части Максим рассказал об AI-native инфраструктуре . А в третьей части к нам присоединился Глеб Михеев (Уставший техдир) и мы вместе поотвечали на вопросы зрителей, обсудили тему миграции больших проектов, а также тему объективного измерения эффективности агентов на своей кодовой базе. Запись на YouTube: Конвертируем Enterprise-проект в Dark Factory — Родион Мостовой и Максим Ключников Таймкоды: 00:00 Знакомство со спикерами и начало доклада 02:15 Что такое Dark Factory и что для неё нужно 09:25 Делаем Enterprise-проект понятным агенту 14:20 Тезаурус, инварианты и знания команды 26:05 Исследование подсистем и проблема missing change 29:20 Контекстные движки: поиск и GraphRAG 36:50 Верификация: тесты, AI QA и запуск в CI/VM 56:30 Максим Ключников: замыкаем петлю на инфраструктуру 1:25:25 Воркфлоу для типовых задач 1:28:05 Профиль готовности проекта к агентам 1:31:05 Сколько работы можно отдать агентам 1:42:30 Обсуждение и вопросы участников @ai_driven

Онбординг агентов в Enterprise кодовые базы на миллионы LoC Вместе с Максимом Ключниковым (Этихлид) поделились своим опытом о том, как добиться максимум эффективности от AI агентов на больших легаси проектах. Я рассказывал про построение тезауруса и борьбу с тех долгом, а также поделился неочевидными результатами наших бенчмарков, измеряющих эффективность контекстных движков (векторный RAG, графовый RAG). Во второй части Максим рассказал об AI-native инфраструктуре . А в третьей части к нам присоединился Глеб Михеев (Уставший техдир) и мы вместе поотвечали на вопросы зрителей, обсудили тему миграции больших проектов, а также тему объективного измерения эффективности агентов на своей кодовой базе. Запись на YouTube: Конвертируем Enterprise-проект в Dark Factory — Родион Мостовой и Максим Ключников Таймкоды: 00:00 Знакомство со спикерами и начало доклада 02:15 Что такое Dark Factory и что для неё нужно 09:25 Делаем Enterprise-проект понятным агенту 14:20 Тезаурус, инварианты и знания команды 26:05 Исследование подсистем и проблема missing change 29:20 Контекстные движки: поиск и GraphRAG 36:50 Верификация: тесты, AI QA и запуск в CI/VM 56:30 Максим Ключников: замыкаем петлю на инфраструктуру 1:25:25 Воркфлоу для типовых задач 1:28:05 Профиль готовности проекта к агентам 1:31:05 Сколько работы можно отдать агентам 1:42:30 Обсуждение и вопросы участников @ai_driven

В вашей CRM пять стадий. В реальной enterprise-сделке — пятнадцать Впереди выходные — есть время на лонгрид. Подготовил как раз такой. Разобрал 1,5-часовой выпуск Lenny's Podcast с Дженн Абель (ко-фаундер JJellyfish, отвечает за enterprise-продажи в State Affairs, среди клиентов Walmart, Mastercard и McDonald’s) — она проходит корпоративную сделку по шагам, от первого письма до подписи. И расхождение с реальностью фаундера получается неприятное: в CRM пять стадий, а реальных шагов около пятнадцати. Сделки умирают ровно в тех десяти, которых в воронке нет. Внутри: — почему на первом звонке не должно быть презы вашего продукта; — как промптинг людей помогает при подготовке к демо; — как за пять минут найти того, кто убьёт сделку; — какие 20% продукта выбрать для демонстрации; — почему бесплатные пилоты работают только 48 часов. Отдельно — бенчмарк по win rate: здоровая конверсия из квалифицированного лида в подписанный контракт 25–35%. Если не попадаете, в статье есть бенчмарки для ключевых этапов воронки, чтобы найти где она протекает. Забирайте на выходные: 👉 B2B-продажи для стартапов: 14 шагов сделки, которых нет в вашей CRM Андрей Резинкин | Money For Startup

В 90% случаев в зрелом enterprise B2B позиционирование «переходите на нас, потому что мы дешевле» - это стратегическая иллюзия и запредельно низкая конверсия. Почему? Для ЛПР (особенно в крупных структурах) главная задача - не сэкономить 20% бюджета компании, а сохранить свою позицию, влияние и репутацию. Если ЛПР лично выбирал и внедрял текущее решение, признать его «слишком дорогим» - значит публично расписаться в собственной ошибке и неэффективной трате бюджета. Никто не хочет идти к CEO или совету директоров со словами: «Я два года назад притащил вендора X, потратил полгода на интеграцию, а теперь вы снимете с меня стружку, потому что Y дешевле». Более того при новом внедрении в результате «экономия» на стоимости софта полностью съедается затратами на замену инфраструктуры и человеко-часы. Единственные исключения: когда аргумент «дешевле» срабатывает Смена вендора на более дешевого в enterprise всё же происходит, но почти никогда не по инициативе того ЛПР, который этот софт изначально внедрял. Это происходит только при наличии внешнего триггера: - Приходит новый директор и начинает «чистку авгиевых конюшен». Ему выгодно выбросить решение предшественника, показать срезание костов и завести своего вендора. - Генеральный или CFO дает ультиматум: «Cрезать IT-бюджет на 30% к следующему кварталу, иначе сокращаем штат». Только тогда ЛПР вынужден искать альтернативы - Поставщик поднимает цены x2-x3 в одностороннем порядке или уходит с рынка - Продукт был рассчитан на стадию роста, а компания вошла в стадию плато, и переплачивать за неиспользуемый enterprise-функционал стало бессмысленно Короче строить базовую стратегию продаж и позиционирование в enterprise на тезисе «переключайтесь, у нас дешевле» - это попытка работать с наименее привлекательным сегментом.

Как продавать enterprise на $5 млрд — и при этом намеренно заходить с маленьких сделок Зацепился за подкаст с Роном Габриско, главным по выручке в Databricks — он там 10 лет, с момента когда компания делала меньше миллиона в год. Сейчас $5,4 млрд ARR, рост 65%. Для контекста: Databricks — платформа для работы с данными и AI, продаёт enterprise-клиентам доступ к инфраструктуре, и клиенты платят по мере реального использования — это consumption-модель. Рон рассказал, как у них устроена мотивация продавцов. Там несколько вещей, которые работают на любом масштабе. Они прошли путь в два шага: сначала платили половину за подписание клиента, половину за потребление — потом перешли на 100% за потребление. Сейлз получает основную часть комиссии не когда клиент подписал контракт, а когда реально начал использовать платформу. Т.о. продавцу не выгодно продать то, чем клиент никогда не будет пользоваться. План продаж в Databricks привязан не к выручке, а к показателям конкретных клиентов. Не «сделай продаж на $2M откуда хочешь», а «вот твои клиенты, вот их потребление сейчас, вот прогноз роста — это твой план». Рон говорит, что ранние сейлзы сопротивлялись — приходилось объяснять, что миллион долларов в год можно заработать и на потреблении, просто не через один монстр-контракт в декабре, а через ежедневный рост потребления у клиентов. Ещё момент: Databricks намеренно "входят в клиента" с маленьких сделок — $50–100k на один use case. Цель первого контракта: 1/ Запустить один процесс клиента на Databricks. Например, клиент переносит аналитику продаж с устаревшей системы на Databricks. 2/ Найти одного чемпиона — человека внутри компании-клиента, который верит в ваш продукт и продвигает его изнутри. Для достижения этих целей Databricks упаковывают «fast starts» — пакеты с сервисами, которые помогают клиенту запуститься быстро. Такой пакет включает доступ к платформе + сервисы: консультантов, шаблоны, техническую помощь с настройкой. Пример: банк подписывает контракт на $100k. Databricks говорит: окей, мы даём вам двух наших инженеров на месяц, готовый шаблон для миграции вашего первого процесса, и обучение для вашей команды. Цель — чтобы через 3 недели у вас уже что-то работало на платформе и вы видели реальный результат. Рон подтверждает, что в consumption-модели размер первой сделки почти не важен. Фаст-старты на $100k вырастают в миллион уже в первый год, а потом в десятки миллионов. Всё держится на первом успехе и первом чемпионе внутри. Звучит так, что consumption-модель выглядит идеально для уже большой компании — но работает ли она на ранней стадии, когда у тебя нет ни консультантов, ни готовых шаблонов? У кого-то был похожий опыт? Го в комментарии, обсудим Андрей Резинкин | Money For Startup

ZeroDrift — AI цензура для AI Все, кто когда-либо работал с compliance, знают это особое ощущение: ты просто хочешь отправить письмо клиенту, текст для сайта или скрипт для звонка, а дальше начинается бюрократический квест. Показать legal, потом compliance, потом кто-то занят, кто-то просит уточнить формулировку, потом появляется новый комментарий, и всё уезжает ещё на пару дней. С людьми это напрягает, но как-то работает. Человек не генерирует тысячи сообщений в день. С AI-агентами так уже не получится. Если AI сам отвечает клиентам, пишет письма, ведёт звонки или генерирует маркетинговые тексты, то нельзя каждый раз отправлять это на ручное согласование. Иначе пропадает весь смысл автоматизации. Но и просто выпускать агента наружу в банке, страховой или медицине тоже страшно: он может пообещать лишнее, забыть дисклеймер, нарушить внутреннюю политику или сказать что-то, за что потом прилетит от регулятора. Здесь и появляется сегодняшний стартап ZeroDrift. Они ставят слой между AI-системой компании и внешним миром. Агент что-то написал, сказал или сгенерировал, ZeroDrift проверяет это до отправки. Если всё нормально, сообщение уходит. Если нет, система останавливает его, объясняет проблему и предлагает исправление. Своего рода корпоративная цензура, но в regulated industries это, возможно, единственный способ вообще дать AI право говорить от имени компании. ZeroDrift недавно подняли $10 млн seed round. Среди инвесторов a16z speedrun и ещё несколько фондов. Пишут, что с начала 2026 года у них уже есть интерес со стороны крупных банков, asset managers и страховых компаний, а traction растёт в два раза месяц к месяцу. Старые compliance-системы в основном работали постфактум: архивировали, мониторили, помогали разбираться, кто что отправил и почему это плохо. ZeroDrift хочет быть не камерой наблюдения, а турникетом. Это перекликается с тем, о чём я уже писал в другом посте: AI в бизнесе выходит из режима “ну ошибся, бывает” и попадает в мир, где за ошибку кто-то платит. Только там история была скорее про ответственность за последствия, а здесь про попытку не допустить косяк до того, как он случился. SEC с 2021 года оштрафовала больше 100 компаний на сумму более $2.2 млрд за нарушения в коммуникациях и recordkeeping. И каждый такой штраф случился уже после того, как сообщение было отправлено. Чем автономнее становится AI, тем больше вокруг него нужно скучной инфраструктуры: guardrails, audit logs, insurance, compliance firewalls, policy engines. Всё то, что не очень красиво выглядит на демо, но без чего enterprise просто не выпустит AI к реальным клиентам.

🎩 Six of the top ten emerging AI markets are agent-related. Прикольная табличка из недавнего отчета от CB Insights по агентам в enterprise. Прям с ходу погнали посмотрим. 1/ Смотрим на топ-10 emerging AI markets по Mosaic Score (для справки, это скоринговая модель CB Insights, которая оценивает потенциал частных компаний): ▪️IT Ops AI Agents – 651. ▪️Know Your Agent (KYA) – 650. ▪️CRM & Relationship Intelligence – 636. ▪️Platform as a Service – 629. ▪️Browser Automation Agents – 620. ▪️AI Agent Tool Libraries – 617. ▪️LLM Benchmarking – 616. ▪️AI Agent Browser Infra – 616. ▪️Semiconductor Design AI – 613. ▪️Marketing AI Agents – 598. 2/ Шесть из десяти категорий – это прямо "агенты". Но интереснее не это, а что именно попало в тройку по инфраструктуре и governance: 🔹Know Your Agent (KYA) занимает второе место, сразу за IT Ops. Это категория про identity, permissions, мониторинг и контроль поведения агентов – по сути "паспорт" и "надзиратель" для AI-агента в проде. ▪️Platform as a Service и LLM Benchmarking – тоже в топе, обе инфраструктурные. 3/ Почему это важно: enterprise AI сейчас – это не только "что агент умеет", но и "что нужно, чтобы им безопасно управлять". Чем автономнее становится софт, тем быстрее спрос смещается с applications на governance-слой под ними. KYA – самый яркий пример: рынок буквально формируется вокруг вопроса "как контролировать то, что мы только что задеплоили". 👉 Сам отчет на 15 страниц от CB Insights качайте по ссылке: https://www.cbinsights.com/research/report/the-future-of-the-enterprise-ai-buildout/ @proVenture #ai #research #trends

Клиент не сказал ни одного «да». И это была лучшая встреча за месяц На прошлой неделе собрал звонок: я и двое фаундеров, участники клуба MFS, Саша и Стас. Саша делает базу данных для AI-стартапов — она удешевляет хранение данных и ускоряет поиск. Стас — основатель HR-tech с enterprise-клиентами. Идея простая — прокастдевить Стаса как потенциального клиента Саши. Посмотреть, где болит, и понять, ложится ли туда продукт. Пошло не по плану. Уже к третьей минуте Саша начал рассказывать, какой у него классный продукт, сколько он сэкономит на инфраструктуре и как легко на него переехать. Стас — отвечать возражениями. Сижу и понимаю: это уже не кастдев, это переговоры, на которые Стас вообще-то не приходил. Пришлось вмешаться: ребят, стоп, мы тут ничего не продаём. Саша — «а я и не продаю». Стас — «нет, ты продаёшь». Но в итоге именно из этой перепалки вышло самое ценное. Стас поделился, что у него за последний год прилетели контракты по 350к евро с процедурой закупки по девять месяцев. В сделках такого масштаба IT-блок клиента согласовывает весь стек вендоров — если видит незнакомый продукт, просто говорит «нет», и сделка, за которую боролись почти год, просто слетает. Например, один крупный клиент без ISO 27001 поставил сделку на холд. Поэтому Стасу на текущем этапе развития плевать на экономию токенов и любую оптимизацию, которую предлагал Саша, — единственное, что для него важно, чтобы ничего не угрожало сделкам. Дальше Стас прямо сформулировал, как у него внутри устроено принятие решения: CTO смотрит на технологию, Head of Sales — на возможные угрозы для плана продаж, и ему вообще всё равно, сколько продукт экономит компании. Если хоть один скажет «нет» — сделки не будет. Два покупателя, и говорить с ними нужно на разных языках. В концу разговора Саша сказал, что цель встречи выполнена — узнал ровно то, за чем приходил. Хотя за весь звонок Стас не сказал ни одного «да». Зато накидал десяток возражений, которые для раннего стартапа могут быть ценнее чем продажа. Андрей Резинкин | Money For Startup