За последние несколько лет AI-продукты перестали быть просто экспериментами или внутренними pet-project’ами. Крупные компании начали внедрять генеративный ИИ, AI-ассистентов и аналитические AI-системы уже не в формате «посмотреть, что умеет нейросеть», а как полноценные production-решения, влияющие на эффективность бизнеса, производительность сотрудников и экономику процессов.

Но довольно быстро выяснилось, что классический Product Manager далеко не всегда подходит для enterprise AI.

На собеседованиях многие кандидаты хорошо рассказывают про стандартные хардовые компетенции менеджера продукта: CustDev, JTBD, roadmap, MVP, A/B-тесты, продуктовые метрики.

Но когда разговор заходит про реальные enterprise AI-продукты, начинают появляться проблемы. У AI-продакта есть своя специфика, а у продакта в Enterprise - своя, эти 2 области знаний редко пересекаются в одном человеке.

AI Product Manager для enterprise — это вообще не просто «обычный продакт, который работает с нейросетями» и не человек «между бизнесом и разработкой».

У AI-продуктов есть собственная специфика:

• ограничения моделей;

• hallucinations;

• качество данных;

• latency и стоимость inference;

• AI governance;

• необходимость Human-in-the-loop;

• риски безопасности;

• сложные интеграции;

• постоянная донастройка моделей;

• эксплуатация production AI-систем.

А у enterprise B2B-продуктов — своя:

• длинный цикл продаж;

• тендеры и закупки;

• большое количество лиц, принимающих решения;

• сложные согласования;

• требования безопасности;

• on-premise и закрытые контуры;

• SLA и техническая поддержка;

• интеграции с legacy-системами;

• необходимость доказывать бизнес-эффект и ROI;

• сложная монетизация;

• необходимость одновременно строить продукт и выводить его на рынок.

По сути, это роль mini-CEO, где одновременно нужны:

• продуктовое мышление;

• понимание технологий;

• понимание enterprise-архитектуры;

• навыки переговоров;

• понимание B2B продаж;

• понимание экономики продукта;

• умение работать с конфликтами и неопределённостью;

• способность выстраивать внедрение и эксплуатацию;

• и понимание того, как вообще AI-продукт превращается из пилота в масштабируемый бизнес.

За последнее время мне пришлось провести довольно большое количество собеседований Product Manager’ов для AI/B2B продуктов. В этой статье я собрала подход, вопросы, кейсы и red flags, которые использую при оценке кандидатов.

Сразу оговорюсь: это не «единственно правильный» способ проводить интервью. Скорее — практический подход, который у меня сформировался на фоне работы с enterprise AI-продуктами, production-внедрениями и попытками выводить такие продукты на внешний рынок.

Какие компетенции я проверяю

Я стараюсь не превращать интервью в экзамен по теории управления продуктом.

Мне не очень интересно, сможет ли кандидат идеально пересказать определение JTBD или назвать все agile-фреймворки. Большую часть теории сегодня можно достаточно быстро выучить. Намного сложнее — применять её в реальной enterprise-среде, где одновременно существуют:

• ограничения технологий,

• интересы бизнеса,

• сложные внедрения,

• корпоративная политика,

• безопасность,

• продажи,

• поддержка production,

• и постоянная нехватка ресурсов.

Поэтому на собеседовании я в первую очередь пытаюсь понять как человек мыслит и насколько он вообще способен управлять AI-продуктом в реальной корпоративной среде.

Условно для себя я делю интервью на несколько больших блоков.

Генерация идей и понимание рынка AI-продуктов

Этот блок помогает быстро понять широту мышления кандидата и то, насколько он вообще ориентируется в рынке AI.

Например, я могу спрашивать:

• какие AI-продукты он считает перспективными;

• какие тренды видит на российском и мировом рынке;

• как оценивал бы рынок новой AI-ниши;

• что делал бы, если прямых конкурентов вообще нет;

• что является главным конкурентом таких решений на российском рынке в сегменте крупных корпораций;

• как искал бы идеи для продукта;

• за счёт чего вообще может выжить AI-стартап.

Очень часто здесь выясняется, что кандидат хорошо умеет работать с уже существующим backlog’ом, но практически не умеет работать с неопределённостью и поиском новых направлений.

А для AI это критично, потому что рынок сейчас меняется настолько быстро, что многие продуктовые гипотезы буквально устаревают за несколько месяцев.

Отдельно мне важно понять, насколько человек вообще понимает специфику AI-рынка:

• open-source модели;

• конкуренцию платформ на российском рынке;

• проблему монетизации;

• высокую стоимость внедрений;

• сложность масштабирования;

• зависимость качества продукта от данных;

• и то, как AI постепенно превращается из «фичи» в инфраструктурный слой.

Discovery и исследования

Дальше я обычно ухожу в блок исследований.

Здесь мне важно понять:

• умеет ли человек работать с неопределённостью;

• способен ли он получать реальные инсайты;

• понимает ли разницу между B2B и B2C исследованиями;

• умеет ли разговаривать с клиентами из крупного корпоративного бизнеса.

Я часто спрашиваю:

• что такое JTBD;

• что будет являться "персоной", когда мы говорим про Enterprise;

• когда его действительно имеет смысл применять;

• как кандидат готовится к полевому исследованию;

• где он вообще будет искать B2B-респондентов;

• как будет проводить интервью;

• как поймёт, что проблема действительно важна;

• и как после исследования перейдёт к следующему этапу продукта.

На практике именно здесь часто проявляется одна из главных проблем junior/middle продактов: они воспринимают CustDev как «поговорить с пользователями».

Но enterprise B2B исследования — это совсем другая история.

В enterprise у вас почти никогда нет:

• большого объёма пользователей;

• быстрых экспериментов;

• дешёвого трафика;

• мгновенной обратной связи.

Зато есть:

• длинные циклы продаж;

• сложные процессы согласования;

• несколько разных стейкхолдеров;

• политические интересы внутри компании;

• пользователь и лицо принимающее решение - это не один и тот же человек.

Поэтому мне важно понять, способен ли Product Manager работать в среде, где информации мало, а цена ошибки высокая.

Прототипирование и MVP

Следующий блок — прототипирование и MVP.

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

Например:

• зачем вообще нужен прототип;

• на каком этапе жизненного цикла он используется;

• какие инструменты подходят для разных типов продуктов;

• как тестировать прототип;

• какие вопросы задавать пользователям;

• что делать, если MVP сделать слишком дорого или долго.

Для enterprise AI это особенно важно, потому что стоимость ошибки здесь часто значительно выше, чем в классическом B2C.

В AI-продуктах можно очень быстро потратить:

• месяцы разработки;

• большие бюджеты на ML;

• интеграции;

• инфраструктуру;

• GPU-ресурсы;

• и команды внедрения,

а потом выяснить, что:

• продукт не решает реальную проблему;

• пользователи ему не доверяют;

• заказчик не готов менять процесс;

• или экономика внедрения вообще не сходится.

И здесь мне важно увидеть, умеет ли человек думать не только категориями «сделать фичу», а категориями проверки рисков и гипотез.

Почему AI Product Manager должен уметь считать деньги

Наверное, один из самых недооценённых блоков на собеседовании Product Manager’ов — это экономика продукта.

Очень многие кандидаты слабо понимают:

• как и на чем продукт зарабатывает деньги;

• сколько реально стоит его эксплуатация;

• как считается экономика AI-продукта;

• где возникают основные расходы;

• и почему некоторые AI-продукты в принципе невозможно масштабировать экономически.

А для enterprise AI это критично.

Потому что enterprise AI-продукт — это почти всегда дорого:

• инфраструктура;

• GPU;

• inference;

• хранение данных;

• интеграции;

• внедрение;

• поддержка;

• сопровождение;

• кастомизация;

• безопасность;

• on-premise deployment;

• доработка под конкретного клиента.

И каждый из этих пунктов должен "ложиться" в финансовую модель продукта, включая, стоимость внедрения, кастомизации и поддержки. То есть по сути экономика продукта гибридная - в ней есть часть продуктовая / инвестиционная и интеграционная/консультационная. А это две разные финансовые модели, которые нужно "скрестить0."

На интервью я почти всегда отдельно проверяю:

• понимает ли кандидат модели монетизации B2B AI-продуктов;

• умеет ли считать unit-экономику;

• умеет ли оценивать стоимость внедрения;

• понимает ли влияние кастомизации на маржинальность;

• способен ли рассуждать про P&L продукта;

• и вообще думает ли он категориями ROI.

Например, я могу задавать достаточно простые вопросы:

• как вы будете устанавливать цену продукта;

• какие расходы обязательно учитывать;

• какая модель монетизации здесь подходит;

• как оценить маржинальность;

• на каком этапе стоит считать unit-экономику;

• какие показатели будут критичны для enterprise AI.

Потому что в enterprise AI Product Manager почти неизбежно сталкивается с тем, что продукт нужно не только разработать, но ещё и:

• продать;

• внедрить;

• поддерживать;

• масштабировать;

• и при этом сохранить экономику.

Отдельно я обычно смотрю, насколько кандидат понимает специфику enterprise-продаж

Enterprise B2B сильно отличается не только от B2C, но и от модели B2B для малого и даже среднего бизнеса. В крупном корпорате есть:

• длинный цикл сделки;

• тендеры;

• закупки;

• несколько уровней согласования;

• ИБ;

• архитектура;

• юристы;

• инфраструктурные ограничения;

• требования on-premise (не всегда);

• и необходимость доказывать экономический эффект ещё до начала внедрения.

Ключевое: как привсех этих условиях превратить AI-продукт бизнес.

Почему AI Product Manager должен понимать технологии

Я не считаю, что Product Manager AI-продукта должен быть ML-инженером или архитектором. Но я считаю, что он обязан понимать технологические ограничения продукта, которым управляет.

В классическом продукте можно какое-то время жить на уровне пользовательских сценариев, CJM, метрик и backlog’а. В AI-продукте этого недостаточно.

Потому что очень многие продуктовые решения напрямую зависят от технологии:

• какие данные доступны;

• какого качества эти данные;

• где они хранятся;

• можно ли их использовать для обучения или RAG;

• какая модель используется;

• насколько она стабильна;

• какая у неё стоимость inference;

• какая задержка ответа приемлема для пользователя;

• где нужен Human-in-the-loop;

• какие риски hallucinations допустимы, а какие нет;

• как сдавать систему Заказчику, которая отвечает точно на в 100% случаев;

• как продукт будет работать в закрытом контуре;

• как его потом поддерживать в production.

Если Product Manager этого не понимает, он очень быстро начинает обещать рынку и клиентам вещи, которые команда либо не сможет сделать, либо сможет сделать слишком дорого.

В enterprise это особенно опасно.

Здесь нельзя просто сказать: «мы прикрутим нейросеть» или «добавим AI-ассистента». Нужно понимать:

• в какие системы продукт будет интегрироваться;

• какие есть ограничения по безопасности;

• какие данные можно передавать в модель;

• где должны храниться пользовательские данные;

• как будет устроен контур внедрения;

• как будет проверяться качество ответов;

• кто будет отвечать за ошибки;

• как будет организована поддержка;

• и что произойдёт, если модель начнёт отвечать неправильно.

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

Для этого я могу спрашивать:

• какие технические риски могут возникнуть у AI-продукта;

• как кандидат будет предотвращать проблемы с производительностью;

• какие интеграции могут быть критичны;

• как он будет оценивать качество AI-функциональности;

• какие ограничения могут появиться при внедрении в enterprise;

• что делать, если модель даёт нестабильный результат;

• как объяснить бизнесу, что часть задач нельзя автоматизировать полностью.

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

Для меня хороший AI Product Manager — это не человек, понимает, где AI действительно создаёт ценность, а где начинает создавать технические риски, расходы и ложные ожидания.

Полезные кейсы при собеседовании

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

Поэтому довольно быстро я начала смещать фокус интервью именно в сторону практических кейсов.

Один из самых показательных кейсов — конфликт между бизнесом и ML-командой

Я часто даю кандидатам ситуацию, близкую к реальности enterprise AI-команд.

Например:

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

Начинается конфликт, обсуждение срывается, команда замолкает.

После этого я спрашиваю:

• как кандидат отреагирует прямо в этот момент;

• как вернёт фокус обсуждения;

• что будет делать дальше;

• и как предотвратит повторение ситуации.

На первый взгляд кейс кажется довольно простым. Но на практике он очень хорошо показывает зрелость Product Manager’а.

Потому что здесь одновременно проверяется:

• leadership;

• фасилитация;

• эмоциональная устойчивость;

• способность работать с конфликтами;

• понимание интересов бизнеса;

• понимание интересов ML-команды;

• и способность удерживать продуктовый баланс.

Очень часто слабые кандидаты начинают:

• «гасить конфликт» любой ценой;

• занимать сторону бизнеса;

• занимать сторону разработки;

• или уходить в формальные agile-ритуалы.

Но в enterprise AI проблема обычно глубже. ML-команда действительно может быть перегружена research-задачами. Бизнес действительно может давить крупным клиентом. Архитектурные ограничения действительно могут мешать быстро выпускать фичи. И Product Manager должен уметь не «выиграть спор», а удерживать систему в рабочем состоянии.

Второй важный тип кейсов — переговоры с enterprise-клиентом

Ещё один блок, который я считаю очень показательным — это переговорные кейсы.

Например, я даю ситуацию:
крупный enterprise-клиент требует перейти на годовой fixed payment с большой скидкой, хотя для компании критически важна помесячная модель оплаты из-за cash flow и внутренних ограничений.

И дальше я смотрю:

• как кандидат будет вести переговоры;

• уйдёт ли сразу в уступки;

• начнёт ли конфликтовать;

• умеет ли задавать уточняющие вопросы;

• понимает ли внутреннюю экономику продукта;

• способен ли защищать интересы компании;

• и понимает ли вообще, как устроены enterprise B2B продажи.

Потому что в enterprise AI Product Manager очень редко существует в изоляции от продаж. В какой-то момент Product Manager почти неизбежно начинает участвовать:

• в пресейле;

• в переговорах;

• в формировании коммерческих предложений;

• в обсуждении roadmap с клиентом;

• в защите экономики продукта;

• и в объяснении, почему продукт вообще стоит своих денег.

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

Посредством таких коротких кейсов можно увидеть, как кандидат будет действовать в сложной ситуации, а не слушать идеальный пересказ о прошлом.

Пример комплексного продуктового кейса

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

Это одна из самых важных частей интервью.

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

Иногда я прошу кандидата разобрать его собственный продукт. Но на практике это не всегда работает:

• кто-то работал над слишком узкой частью продукта;

• кто-то не может раскрывать детали;

• у кого-то продукт вообще был не AI;

• а иногда кандидат начинает уходить в очень общие формулировки.

Поэтому довольно часто я даю уже подготовленный кейс.

Обычно это B2B AI-продукт с enterprise-спецификой.

Например, один из кейсов, — AI Legal Risk Scout.

Пример кейса — AI Legal Risk Scout

Есть AI-система для enterprise-клиентов, которая:

• анализирует большие массивы договоров;

• ищет потенциальные юридические риски;

• выявляет штрафные санкции и скрытые обязательства;

• предлагает улучшения формулировок с помощью LLM;

• отслеживает изменения законодательства;

• проверяет соответствие договоров новым требованиям.

Продукт интегрируется с:

• DMS (Document Management Systems);

• CRM / ERP;

• корпоративными системами хранения документов.

Целевая аудитория:

• банки;

• страховые компании;

• девелоперы;

• телеком;

• крупные enterprise-клиенты.

Монетизация:

• подписка;

• плюс кастомизация под локальное законодательство и внутренние процессы клиента.

Что я проверяю в этом кейсе

На самом деле мне здесь не так важен «правильный ответ».

Мне важно посмотреть:
как кандидат вообще структурирует задачу.

Например:
с чего он начнёт.

Очень многие сразу начинают говорить:

• про AI;

• модели;

• интерфейсы;

• roadmap;

• функции продукта.

Но сильные Product Manager’ы обычно сначала начинают с другого:

• где возникает ценность;

• какая стоимость ошибки;

• как сейчас решается проблема;

• кто конкуренты (это могут быть и бесплатные сервисы и ручной труд, пока это главные конкуренты);

• насколько дорогая интеграция;

• есть ли вообще "желание платить".

Пользователь и покупатель

Дальше я обычно начинаю углубляться. Например, спрашиваю: кто здесь пользователь? А кто лицо, принимающее решение о покупке? Потому что в enterprise почти всегда есть разница между: пользователем и и человеком / людьми, который принимает решение о покупке.

Например:

• юрист может пользоваться системой;

• директор юридического департамента — принимать решение;

• ИБ — блокировать внедрение;

• а CIO — согласовывать бюджет.

И хороший Product Manager в B2B должен уметь это видеть.

Риски продукта

Другой непростой вопрос: какой основной риск этого продукта? Некоторые начинают отвечать:

• «конкуренция»;

• «сложность AI»;

• «нехватка данных».

Но в enterprise AI риск часто вообще в другом.

Например:

• юристы могут не доверять AI;

• клиент может бояться отправлять документы в модель;

• интеграция может оказаться слишком дорогой;

• внедрение может занимать дольше продажи;

• или стоимость кастомизации под каждого клиента может убить экономику продукта.

Unit-экономика

Сам Unit в B2B и в B2C может сильно отличаться. В B2B юнитом может быть, например:

• компания-клиент;

• отдельный департамент;

• количество сотрудников;

• количество документов;

• объём данных;

• количество AI-запросов;

• число обработанных процессов;

• внедрённый контур;

• или вообще отдельный enterprise-контракт.

Я обычно смотрю:

• понимает ли кандидат стоимость внедрения;

• учитывает ли стоимость GPU;

• понимает ли роль кастомизации;

• думает ли про стоимость поддержки;

• учитывает ли presale;

• закладывает ли стоимость интеграций;

• понимает ли влияние on-premise deployment;

• думает ли про SLA и сопровождение.

Очень многие начинают считать SaaS, но enterprise AI почти никогда не является «идеальным SaaS». Там почти всегда появляются: кастомные доработки, интеграции, внедрение. А еще в большинстве случаев требования безопасности приводят к отказу от облака и внедрению on-prem.

Отдельно я смотрю, как кандидат думает про вывод продукта на рынок

AI-продукт может быть технологически хорошим — и при этом плохо продаваться. И каналы продаж и сама техника продаж здесь сильно отличается от более массовых историй - B2C и средний / малый B2B.

Поэтому я почти всегда спрашиваю:

• какие каналы продвижения кандидат выбрал бы;

• как строил бы B2B воронку;

• как организовал бы пилот;

• как доказывал бы ROI;

• как заходил бы в enterprise;

• через кого продавал бы продукт;

• какие партнёрства строил бы;

• и как вообще превращал бы AI-продукт в масштабируемый бизнес.

Какие красные флаги я вижу чаще всего

Все перечисленные выше теоретические вопросы и кейсы позволяют мне увидеть проблемы, которые являются красным флагом именно в AI-продукте в Enterprise-сегменте.

Ниже — несколько red flags, которые лично для меня стали наиболее показательными:

• кандидат говорит только про фичи, но мало говорит про экономику и монетизацию;

• не понимает, что происходит после продажи;

• не понимает, за счет чего зарабатывает продукт и как в модель монетизации встроить интеграционные и консультационные услуги;

• не понимает технических ограничений ИИ;

• плохо понимает высокую степень неопределенность этого рынка;

• слабые переговорные тактики и стратегии;

• в целом плохо понимает реалии больших компаний с политиками безопасности и т.д.

Это не всегда означает слабого менеджера продукта, но почти всегда означает, что человеку будет очень сложно быстро адаптироваться к enterprise AI-среде.

Выводы

За последние несколько лет вокруг AI-продуктов появилось огромное количество хайпа. Но вместе с этим стало гораздо заметнее, насколько сильно enterprise AI отличается от классического product management.

В enterprise AI Product Manager очень быстро сталкивается с реальностью, где одновременно существуют:

• ограничения технологий;

• сложная экономика;

• внедрение в корпоративный ландшафт;

• продажи;

• безопасность;

• поддержка production;

• кастомизация;

• интеграции;

• внутренние конфликты;

• и необходимость постоянно балансировать между интересами бизнеса и разработки.

Именно поэтому на собеседованиях мне важно понять:

• Реальный опыт с Enterprise и переговорные навыки;

• Понимание технической стороны вопроса и способность оставаться в контексте технологических изменений;

• Способность доводить ИИ-инициативы до production.