Вы часто слышите на конференциях: «Нужно быть продуктовой компанией!», «Проводите CustDev!», «Замеряйте метрики!». А на совещании звучит: «Почему мы не проводим A/B-тесты?», «Давайте сделаем CustDev с 100 пользователями!». Вы видите, что команда уходит в бессмысленную активность, а руководство требует «быть как Яндекс». В суровой реальности B2B-сделок, кастомных внедрений и длинных циклов продаж "продуктовые советы" часто разбиваются о необходимость сделать сложную интеграцию, соблюсти нефункциональные требования и договориться с комитетом из десяти человек.

Эта статья для CPO/PM и руководителей B2B, у кого сделки длятся 6–12 месяцев, решение покупает комитет, а 70% усилий уходят в интеграции и надёжность. Разбираем, где продуктовые практики дают отдачу, а где решают доменная экспертиза и безупречный delivery. Короче для тех, кто разрывается между «давайте сделаем продукт» и суровой реальностью проектов, кастома и длинных B2B-сделок. Разберёмся, когда CustDev и «быстрые эксперименты» дают ценность, а когда решает именно контекст и предметная экспертиза, чем полезна продуктовая функция, где PM не обязателен, и как управлять в циклах 6–12 месяцев без самообмана и продуктового фетишизма.

Ну и традиционно подписывайтесь на канал StrategicMove, там будет оповещение о новых вебинарах и полезностях.

Продуктовый подход vs Проектный подход: два разных мира

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

• Решение покупает комитет, а не конечный пользователь. Конечный пользователь не принимает решения. Проводить с ним CustDev на этапе продаж все равно что спрашивать у пассажира самолета, какой двигатель ставить на лайнер. Вам нужны инструменты для убеждения комитета (ЛПР).

• Боль скрыта в процессах и регламентах, а не в UX-раздражителях.

• Ключевые риски — это интеграции, безопасность и производительность, а не «где кнопку добавить».

Пирамида контекста: что нужно знать
Прежде чем бежать проводить интервью, соберите этот фундамент:

Интерпретация суммы баллов (макс. 22):

• 0–7 → Experiment-First (рост, быстрые итерации, PLG).

• 8–14 → Гибрид (портфель H1/H2/H3).

• 15–22 → Delivery-First (экспертиза, надёжность, предсказуемость → затем преимущества).

  Классический продуктовый подход работает там, где миллионы транзакций, короткие циклы и дешёвая ошибка. Если ваши сделки длинные, ошибка дорогая, домен сложный (ERP, биллинг, финтех, госсектор), то намного больше веса у воркшопов с экспертами, наблюдений за реальной работой (Gemba) и пилотных Proof of Concept (POC), и меньше — массовых интервью. Это не просто мнение, а вывод, основанный на горьком опыте множества проектов и принципах системного анализа. 

В сложных предметных областях (медицина, юриспруденция, финансы, производство) существует концепция «Явного» (Explicit) и «Неявного» (Tacit) знания.

• Явное знание — это то, что легко формализовать и передать словами: инструкции, мануалы, регламенты. Его можно получить через массовые интервью.

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

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

Вывод: Чем сложнее домен, тем больше в нем неявного знания, которое невозможно получить через опрос «рядовых пользователей». И тогда задача продакт-менеджера быть тем самым человеком, который ищет в разрозненных проектах общие боли и возможности для масштаба, то есть как раз занимается построением «Пирамиды контекста» на макроуровне. Роль продакта в B2B превращается из «создателя фич» в «архитектора ценности» и «поисковика масштаба», который работает в тандеме с BA и SA.

Признаки «BA/SA-зоны» (зоны доминирования бизнес-аналитиков и архитекторов)

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

• Требования диктуются отраслевыми стандартами, методологиями или регуляторикой.

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

• Успех = delivery: соблюдение SLA, безопасность, беспроблемная миграция данных.

• Цикл сделки — 6–12 месяцев с долгими согласованиями.

Примеры: модули для ERP-систем, системы документооборота, KYC/AML-платформы, отраслевые шлюзы.

Здесь классические B2C-приёмы не работают. A/B-тест ничего не решит, когда внедрение длится полгода, а решение принимает технический директор и CFO. Ценность приносят не гипотезы, а сильные аналитики (BA/SA), способные быстро погрузиться в процессы клиента, и инженерная дисциплина, гарантирующая надёжность.

Антипаттерн: нанять продакт-менеджера с мандатом «делай discovery и улучшай метрики» в проекте, где всё решают регламенты и технические риски. Это путь к разочарованию.

Пример ПРОДУКТА (где нужен PM, CustDev и метрики):

• Что это: CRM-система типа Salesforce или HubSpot.

• Почему продукт: Боль (неорганизованные продажи) одинакова у тысяч малого и среднего бизнеса.

• Как работает подход:

  • CustDev: Интервью с 50 менеджерами по продажам из разных отраслей показывают, что всем нужен быстрый доступ к истории звонков по клиенту с телефона.

  • Эксперимент: Команда быстро делает MVP в формате раздела в мобильном приложении и смотрит на метрику Adoption Rate. Она растет — гипотеза подтверждается.

  • Масштаб: Одно решение упаковывается и продается тысячам клиентов через сайт с помощью маркетинга.

Пример ПРОЕКТА / УСЛУГИ (где нужны BA, SA и Delivery):

• Что это: Внедрение системы электронного документооборота (СЭД) в крупном банке.

• Почему проект: Боль специфична: банк должен соблюдать жесткие регуляторные требования ЦБ, его процессы уникальны, документооборот интегрирован с 10+ внутренними системами (ядерный банковский софт, 1С).

• Почему НЕ работает продуктовый подход:

  • Проводить CustDev с рядовыми бухгалтерами бесполезно — они не принимают решение.

  • Решение будет принимать комитет из IT-директора, руководителя департамента безопасности и начальника отдела документооборота.

  • Их ключевые вопросы: "Как вы обеспечите бесперебойность работы 24/7?", "Как интегрируетесь с нашей системой X?", "Дайте гарантии по срокам и SLA".

  • 80% работы — это кастомные интеграции и настройка процессов под регламенты банка.

Когда рулит delivery и экспертиза: Пример

Компания: Студия, специализирующаяся на внедрении 1С на производственных предприятиях.

• Кейс: Внедрение модуля "Управление ремонтами оборудования" на заводе.

• Что было важно:

  1. BA (Бизнес-аналитик) неделю работал в цеху с мастером (Gemba), чтобы понять реальный процесс: как фиксируется поломка, кто принимает заявку, как списываются запчасти.

  2. SA (Системный архитектор) спроектировал интеграцию 1С с системой диспетчеризации цеха и системой складского учета.

  3. Ключевой риск: Не производительность интерфейса, а бесперебойная работа склада во время миграции данных. Остановка склада = миллионные убытки.

  4. Успех был определен: Внедрением в срок, без сбоев работы склада, и положительным актом подписания со стороны клиента. Никакие "метрики engagement" здесь не были нужны.

Где классический продуктовый подход действительно окупается

Продуктовая модель выгодна там, где есть эффект масштаба и низкая цена единичной ошибки.

Признаки, что вы «в продуктовой зоне»:

• Повторяемый спрос: Одна и та же боль у большого сегмента клиентов. Запросы отличаются деталями (настройки), а не сутью.

• Стандартизируемое решение: 60-80% функционала можно упаковать в «ядро», а остальное сделать настройками.

• Реплицируемый канал продаж: Вы можете использовать одно и то же демо, презентацию и месседжи для разных клиентов.

• Улучшающаяся экономика: С ростом клиентской базы ваши удельные затраты (CAC - стоимость привлечения клиента, COGS - стоимость оказания услуги) снижаются.

Именно здесь появляется необходимость в продакт-менеджере. Его ценность в таком контексте:

• Выбор рынка и стратегии масштабирования (от MVP к продукту, от продукта к платформе).

• Стандартизация: чёткое выделение ядра и конфигурируемых частей.

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

• Связка Product × PMM × Sales: выработка единого языка и стратегии выхода на рынок (GTM).

Где продуктовый подход не даёт отдачи

• Рынок разрознен, требования скачут от клиента к клиенту.

• 80% работы — уникальные интеграции и кастом.

• Цикл сделки 6–12 месяцев, закупка многокомитетная, а «быстрые эксперименты» мало что меняют.

4. Мост от проекта к продукту: как продуктизировать услуги

Редко компания сразу становится продуктовой. Чаще это эволюция.

Двигайтесь по ступеням:
Ad-hoc проекты → Стандартизированный процесс внедрения → Пакет услуг → Модульное решение → Платформа

Компания: Разрабатывала разовые модули для автоматизации колл-центров.

1. Ad-hoc: Сделали для первого клиента кастомный скрипт прогнозирования звонков.

2. Стандартизированный процесс: Поняли, что заказчикам нужен не просто скрипт, а комплекс работ: аналитика, внедрение, обучение. Создали чек-листы и шаблоны проектов.

3. Пакет услуг: Упаковали работу в три типовых пакета: "Базовый" (отчеты), "Про" (прогнозирование), "Энтерпрайз" (интеграция с CRM). Для каждого прописали SLA и фиксированную цену.

4. Модульное решение: Выделили "ядро" — движок для сбора и анализа данных о звонках. Интеграция с конкретной CRM и генерация специфичных отчетов стали настраиваемыми модулями.

5. Продукт/Платформа: Запустили cloud-сервис. Клиенты заходят на сайт, подключают API своей телефонии и CRM, и через день получают готовые дашборды. Продажи идут через сайт, а не через персональные встречи.

4) Если цель — всё-таки «продукт» (там, где возможен масштаб)

4.1 Проверяйте условия масштаба до инвестиций

• Гомогенность спроса: кластеризация клиентов по процессам/JTBD; если 30–40% сегмента решают одну и ту же задачу «почти одинаково» — зелёный сигнал.

• Стандартизация/конфигурация: доля требований, покрываемых «ядром», ≥60%.

• TAM/SAM/SOM: хватит ли рынка для окупаемости GTM+R&D?

• TAM = #организаций в отрасли × средний бюджет на класс задач
  SAM = TAM × % доступного вам региона/ниши × % «вашего» типа клиента
  SOM (3-летний) = SAM × % достижимой доли с учётом каналов/ресурсов

4.2 Перестраивайте оргмодель под value-streams

• Оргструктура: Переходите от финансирования проектов к финансированию потоков создания ценности (value-streams). Это кросс-функциональные команды, которые постоянно развивают часть продукта.

  Метрики: измеряйте то, что важно

  • Для продаж: Длительность цикла сделки, win-rate, время до первой ценности для клиента.

  • Для Delivery: Lead time, cycle time, TTM

  • Для продукта: Доля выручки от подписки (ARR), юнит-экономика (LTV/CAC), % требований, покрываемых «ядром».

4.3. Встройте пресейл и PMM

Здесь метрики продукта — запаздывающие, а реальные рычаги — в воронке покупки B2B и снятии рисков у комитета.

• Presales/Solutions: снимает технические риски, готовит демо

• PMM: позиционирование, месседжи, конкурентка, контент по стадиям воронки и сайт

• Совместно с сейлз: квалификация лидов, карта стейкхолдеров и матрица коммуникаций.

Что реально может сработать:

• Готовые адаптеры и «книга интеграций» - минус недели на пилоте. Пример: для нового клиента не пришлось "с нуля" пилить интеграцию с Bitrix24, а просто настроили готовый коннектор. Это уменьшило оценку сроков внедрения.

• Стандартизованные ответы на типовые запросы сокращение цикла согласований.

• Репрезентативные демоданные и скрипты демо - выше win-rate. Не абстрактное демо, а настроенная под "производственную компанию" база с заказами, номенклатурой и клиентами. Пример: после того как продажники начали показывать "демо под отрасль", win-rate вырос с 15% до 35%.

• ROI-калькулятор на языке процесса заказчика - проще пройти комитет.  Не "наша система быстрая", а "внедрение нашего модуля сократит время обработки заявки с 2 дней до 4 часов, что позволит вашим 10 менеджерам обрабатывать на 50 заявок больше в день". 

5) Роли и компетенции: кто за что отвечает

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

• BA (Бизнес-аналитик): Изучает регламенты регулятора, проводит воркшопы с экспертами заказчика, рисует схемы процессов "as-is" и "to-be". Результат: Техническое задание, согласованное со всеми стейкхолдерами.

• Solution Architect (Архитектор решений): Проектирует, как модуль будет интегрироваться с WMS (складской системой) и ERP, как обеспечить бесперебойность и отказоустойчивость. Результат: Архитектурная схема и план интеграции.

• Product Manager (Продакт): Появится позже. Если компания решит, что этот модуль будет востребован еще 10+ фарм-компаниями, PM займется его "продуктизацией": выделит ядро, определит ценностное предложение, рассчитает TAM/SAM, поможет упаковать его в отдельный продукт для GTM.

• Delivery Manager/Project Manager: Управляет сроками, бюджетом, рисками. Отвечает за то, чтобы все работы были выполнены в срок и с нужным качеством. Результат: Внедренный и работающий модуль, довольный клиент.

• Presales Engineer (Инженер предпродажной подготовки): Еще на стадии продажи подготовил демо, которое показало, как система отрабатывает сценарий отзыва серии препарата. Результат: Помог снять ключевые сомнения технических специалистов заказчика и выиграть тендер.

Гибридный подход

Проблема часто не в методах, а в культуре. Инвесторы и СЕО могут требовать «быть как Яндекс», а команда продаж требует кастом под каждого клиента.

Жесткое противопоставление «продукта» и «проекта» — это упрощение. Реальность успешных B2B-компаний — это гибридная модель, где сила проектной экспертизы превращается в масштабируемый продукт. Ключ к этому — не разграничение ролей, а их теснейшая коллаборация.

Вместо линейного пути «от проекта к продукту» работает непрерывный цикл:

1. Погружение в проект (Этап сбора инсайтов)

• PM участвует в ключевых воркшопах с клиентом вместе с BA. Его задача — понять не «что нужно сделать для этого клиента», а «какую фундаментальную бизнес-проблему мы решаем и насколько она универсальна?»

• PM изучает архитектурные схемы от SA, задавая вопросы: «Какие интеграции повторяются от клиента к клиенту? Можно ли этот компонент сделать универсальным? Что мешает нам сделать его «коробочным»?»

• PM анализирует возражения и вопросы от Presales: «Какие «горячие» демо-сценарии просят показать чаще всего? Какие технические риски (безопасность, производительность) блокируют сделки?»

2. Анализ и синтез (Этап поиска паттернов)

• PM систематизирует полученные данные:

  • Карта повторяющихся требований: Какие функциональные блоки и интеграции заказывают 3 из 5 клиентов?

  • Матрица кастома: Группирует уникальные доработки по типам (например, «отчетность под регулятора», «интеграция с конкретной CRM»).

  • Библиотека возражений: Выявляет типовые страхи и барьеры комитетов, которые нужно снимать на уровне продукта.

3. Формирование продуктного бэклога (Этап упаковки)
На основе анализа PM формирует стратегический бэклог, который делится на три части:

4. Валидация и обратная связь

• Разработанное «ядро» и модули Presales используют в новых демо и пилотах.

• BA и SA смотрят, насколько новые компоненты покрывают реальные требования новых клиентов.

• Цикл повторяется: фидбэк от проектной работы снова идет к PM для анализа и приоритизации.

Роли в гибридной модели: Кто за что отвечает

• Business Analyst (BA): Добывает «сырые» требования из процессов заказчика. Отвечает на вопрос «Что нужно ЭТОМУ клиенту и ПОЧЕМУ?»

• Solution Architect (SA): Проектирует архитектуру решения под конкретного клиента. Отвечает на вопрос «КАК технически это реализовать надежно и эффективно?»

• Presales Engineer: Убеждает клиента, что наше решение ему подходит. Отвечает на вопрос «КАК снять сомнения и риски комитета до покупки?»

• Product Manager (PM): Анализирует входы от всех, ищет паттерны. Отвечает на вопрос «ЧТО из этого нужно универсализировать, чтобы следующий похожий проект был дешевле и быстрее?»

Выводы

Не существует одного "правильного" подхода. Есть подход, адекватный вашей бизнес-задаче и рынку.

В сложных доменах и длинных сделках выигрыш приносят BA/SA, пресейл и дисциплина delivery. Продуктовая функция нужна там, где есть масштаб и стандартизируемое ядро, которое вы умеете превращать в платформу и в повторяемую GTM-машину. А CustDev и «быстрые эксперименты» — лишь часть набора, который работает после того, как вы вчистую поняли контекст.

• Контекст важнее догмы. CustDev и эксперименты работают только при наличии масштабируемого спроса. В сложных B2B-доменах сначала поймите процессы и регуляторику.

• Не бойтесь быть «проектной» компанией. В нишах с высоким кастомом ваш козырь - это экспертиза, аналитики и безупречный delivery. Это не «плохо», это другая бизнес-модель.

• Длинные сделки управляются через снятие рисков. Инвестируйте в артефакты, которые ускоряют согласования: security-пакеты, готовые адаптеры для интеграций, ROI-калькуляторы.

• Продуктизация — это эволюция. Начните со стандартизации своих услуг и процессов, постепенно выделяя общее «ядро».

Ну и традиционно подписывайтесь на канал StrategicMove, там будет оповещение о новых вебинарах и полезностях.