Продакт обещает пользователю ценность, коммерческий блок требует выручки здесь и сейчас, и оба уверены, что говорят про одну и ту же «стратегию». На деле это два разных документа с разными вопросами, и пока их не разделить, они так и будут воевать друг с другом.
Две стратегии, которые отвечают на разные ставки
Вспыхивает конфликт обычно в одной из двух точек: продукт обещает рынку то, что компания не готова финансировать, или коммерческий блок диктует фичи, не понимая, какую работу делает пользователь.
Стратегия бизнеса отвечает на вопрос, где и как компания зарабатывает. В неё входят рынок, сегменты, модель дохода, стоимость продаж, издержки, маржа и темп роста. Это ставки компании: кому продавать, почему именно этим клиентам и за счёт чего всё окупится.
Стратегия продукта отвечает на другой вопрос: почему выбранный клиент купит продукт, начнёт им пользоваться и останется. В ней есть проблема клиента, позиционирование, то, чем продукт отличается от других, ключевые сценарии, продуктовые ставки и метрики поведения пользователей.
Продакт не решает, выходить ли в новую страну или держать дорогую службу внедрения. Зато он обязан доказать, что продукт решит проблему сегмента лучше альтернатив.
Граница не означает изоляцию. Бизнес задаёт поле игры, а продукт проверяет, можно ли на нём выиграть, не разрушив ни ценность для клиента, ни экономику.
Полезная проверка для обеих стратегий взята из книги Ричарда Румельта «Good Strategy / Bad Strategy» (2011): у настоящей стратегии есть ядро из трёх частей, диагноз ситуации, руководящий принцип и согласованные действия. Если в одной из них вместо диагноза только цели, перед вами список пожеланий, и спор между стратегиями будут решать статусом.
Решение меняет либо устройство бизнеса, либо ценность для пользователя
Проверить, чьё это решение, просто. Спросите: оно меняет устройство бизнеса или то, какую пользу продукт приносит пользователю? Первое решает бизнес, второе продукт. Если затронуто и то и другое, решают вместе, но заранее называют, за кем последнее слово.
Рынок выбирает CEO, основатель или руководитель направления. Продакт приносит доказательства: насколько велика и остра проблема, можно ли дотянуться до аудитории, какие есть альтернативы, что мешает начать пользоваться и есть ли признаки, что люди останутся. Но делать рынок приоритетом в одиночку из-за обнадёживающих интервью он не должен.
Целевой сегмент выбирают вместе. Бизнес оценивает, готовы ли клиенты платить, как долго идёт сделка, сколько стоит привлечение и насколько сегмент важен стратегически. Продукт отвечает за то, как клиенты работают, какие задачи у них не закрыты, как часто им нужен продукт и что может помешать внедрению.
Ценностное предложение и опыт остаются за продуктом: какую работу клиент сделает быстрее, надёжнее или дешевле, что войдёт в первый релиз и на какие компромиссы по качеству идти нельзя.
Дальше начинаются деньги. Модель монетизации выбирает владелец бизнеса. Но без данных продукта получится прайс-лист, оторванный от ценности. Поэтому продакт показывает, за какой результат платят, какие лимиты естественно ведут к платному тарифу и где цена ломает первые шаги пользователя.
Издержки лежат на бизнесе и финансовом директоре. Инфраструктура, поддержка, продажи, внедрение и комплаенс не должны прятаться в бэклоге под видом «технического долга».
Приоритизация инициатив остаётся у продукта, если бизнес заранее назвал цель, бюджет и ограничения. Руководитель не выбирает экран, кнопку или порядок сценариев. Но он вправе остановить ставку, которая не укладывается в экономику или фокус.
Так снимается вопрос «кто главнее»: бизнес управляет портфелем ставок и капиталом, а продукт ценностью, поведением и качеством решения.
Для выбора рынка нужны и подтверждённый спрос, и экономика
Продакт может раньше коммерческого блока увидеть возможность: пользователи жалуются на ручной процесс, обходят ограничения, платят сторонним сервисам. Это повод исследовать. Решение выходить на рынок требует большего. Боль без платёжеспособности не создаёт бизнес; платёжеспособность без частой и дорогой проблемы не создаёт удержание.
Возьмём B2B SaaS для финансовых команд, который видит спрос малого бизнеса на автоматизацию сверки платежей: интервью показывают задачу на часы каждую неделю. Но стратегия бизнеса должна проверить три вещи: есть ли доступный канал продаж, окупает ли средний чек продажи и поддержку и не понадобятся ли индивидуальные интеграции, которые съедят маржу.
Рынок удобно описать двумя карточками. В бизнес-карточке: сегмент, канал продаж, ожидаемый доход, цена привлечения клиента, стоимость обслуживания и риски. В продуктовой: в какой ситуации пользователь, какую работу он делает, как обходится сейчас, какой сценарий для него главный, когда он впервые получает пользу и по каким признакам видно, что он вернётся.
Если карточки противоречат друг другу, спорить о вкусах незачем: каждое расхождение можно проверить.
Продукт при этом отвечает за качество доказательств. Видна ли боль в реальном поведении людей? Готовы ли они менять привычный способ работы? Останутся ли? Само число интервью ничего не доказывает.
Монетизация начинается после ценности
Цена не должна появляться в конце разработки как административное ограничение: модель монетизации определяет, какие действия станут ценными и измеримыми. Единица тарификации тоже не формальность, у каждой модели своя зона применимости:
- Подписка подходит для повторяющейся пользы и слабеет там, где ценность разовая, а поводов вернуться нет.
- Цена за место работает, когда ценность растёт с числом сотрудников, но наказывает распространение внутри компании, если считать всех подряд.
- Оплата за объём уместна, когда потребление близко к результату, и подталкивает к лишним действиям, если тарифицируется процесс, а не ответ.
- Комиссия оправдана, когда продукт помогает провести сделку, и теряет смысл там, где сделки нет, а есть только использование.
Бизнес выбирает модель дохода по рынку, конкуренции, марже, риску кассового разрыва и возможностям продаж, а продукт проверяет, не создаёт ли единица тарификации вредное поведение.
Плата за число отчётов в сервисе аналитики может подталкивать к лишним действиям вместо ответов; плата за активных сотрудников в документообороте не должна расти всякий раз, когда коллега открывает общий документ.
Гипотеза проходит путь от клиентской работы к прогнозируемой выручке: команда формулирует ценность, проверяет готовность платить, оценивает себестоимость обслуживания и строит сценарии спроса. Это удобно вести через бизнес-моделирование для продуктовых команд, связывающее гипотезы ценности с P&L, а не с абстрактным «большим рынком».
Продукт участвует в упаковке тарифов: он видит первую пользу, действия, коррелирующие с удержанием, и момент, когда лимит воспринимается честной границей. Бизнес может отказаться от модели, не выдерживающей финансовых требований; это проверка жизнеспособности ставки, и автономию продукта она не отменяет.
Издержки меняют продуктовые решения
Расходы влияют не только на годовое планирование, но и на архитектуру, онбординг, сегментацию, обещания и приоритеты. Это видно в трёх типичных ситуациях:
- Продукт с дорогой ручной настройкой не масштабируется через дешёвое самообслуживание.
- Фича с высокой вычислительной себестоимостью не подходит безлимитному дешёвому тарифу.
- Круглосуточная поддержка требует людей, процессов и бюджета, а не только чата.
Продакт должен получать от финансов и инженерии ограничения: переменные расходы на активного клиента, стоимость хранения и обработки данных, трудозатраты внедрения, нагрузку на поддержку и сроки окупаемости разработки. Иначе можно улучшить конверсию первого шага воронки и одновременно ухудшить валовую маржу.
Если расходы растут, бизнесу не стоит сразу требовать «добавьте платную фичу». Сначала выясняют, что происходит. Какие пользователи создают расход? Получают ли они соразмерную ценность? Можно ли снизить себестоимость, не ухудшив опыт? Нужен ли другой тариф или сегмент? Только после этого появляется осмысленная продуктовая задача.
Приоритизация проверяет две гипотезы сразу
Список фич смешивает устранение боли, продажу крупному клиенту, снижение себестоимости, договорные обязательства и защиту от оттока. RICE или ICE создают ложную точность: высокий балл не заменяет выбора ставки компании.
Поэтому каждая инициатива проходит двойную проверку. Продуктовая спрашивает, какую работу и для какого сегмента улучшит изменение, какое поведение изменится, как распознать первую ценность и что может пойти не так для текущих пользователей.
Бизнесовая спрашивает, с какой целью связана инициатива: новый доход, сохранение выручки, расширение контракта, снижение переменных расходов или выход в выбранный сегмент, и здесь фиксируют бюджет, срок проверки и финансовый риск.
Крупный клиент может попросить интеграцию с внутренней системой. В B2B-покупке со стороны клиента обычно участвует несколько человек, так что «клиент просит» нередко означает просьбу одного из них, и не всегда того, кто подписывает договор. Продакт не должен автоматически считать её «нужной рынку», а коммерческий директор «обещанной сделкой». Проверяют по порядку:
- повторяемость задачи в сегменте;
- место интеграции в ценностном предложении;
- стоимость поддержки;
- блокировку контракта при её отсутствии;
- возможность ограниченного пилота.
Единичную кастомизацию бизнес оплачивает как условие сделки или отклоняет; ставку на сегмент с понятной экономикой продукт превращает в проверяемую гипотезу.
Метрики соответствуют типу решения. Продуктовую ставку оценивают по доле клиентов, достигших критического события, времени до первой пользы, удержанию когорты и глубине сценария. Бизнесовую по валовой марже, стоимости привлечения, периоду окупаемости, доле расширения выручки и выручке сегмента. Нужны и защитные метрики: платная конверсия не считается успехом, если растут возвраты или падает удержание.
Один контур планирования вместо двух приказов
Разделение ответственности требует общего ритма. Если руководство раз в год утверждает финансовый план, а продукт ежеквартально отдельно выбирает фичи, конфликт возникнет в доставке. Решения связывают на трёх уровнях.
На уровне компании руководители фиксируют целевой рынок, модель дохода, финансовые ограничения и несколько ставок периода. «Стать лидером» не помогает выбирать при дефиците команды; «выйти в сегмент агентств с тарифом за рабочее место и окупить канал за двенадцать месяцев» задаёт границы продукту и продажам.
На уровне направления продакт, маркетинг, продажи, финансы и ведущий инженер строят дерево причин. Наверху бизнес-результат. Под ним то, что его двигает: качественный спрос, активация, повторное полезное действие, удержание, расширение. Для каждого пункта назначают владельца, метрику, период измерения и ставки. Тогда маркетинг не гонит трафик, пока продукт чинит удержание аудитории, которой сервис не подходит.
На уровне команды у инициативы есть владелец, гипотеза, срок проверки, первичная метрика и ограничитель. Публичный журнал решений полезнее длинной дорожной карты: он показывает, кто выбрал ставку, на каких допущениях, что должно подтвердиться и когда выбор пересмотрят.
Конфликт не лечится передачей полномочий
Плохой сценарий выглядит так: продакт сам выбирает сегмент, обещает экономический эффект и приносит крупный план, а бизнес в ответ передаёт список сделок, тарифов и обязательных фич. В первом случае продукт живёт без финансовой реальности, во втором становится очередью внешних запросов.
Рабочая граница строже. Бизнес не перекладывает на продукт решение, куда рисковать деньгами компании. Продукт не перекладывает на бизнес решение, как клиент получает ценность. А для совместных решений нужны общие факты и один человек, за которым последнее слово.
Большую часть таких споров снимают четыре документа:
- карта целевых сегментов с экономическими ограничениями;
- описание ценности и ключевого события для каждого сегмента;
- список инициатив, каждая из которых прошла двойную проверку;
- журнал ставок с датой пересмотра.
Все споры они не снимают. Если компании нужно закрыть кассовый разрыв в ближайший квартал, граница честно сдвигается в сторону бизнеса. Лучше записать это в журнал ставок как осознанное исключение с датой возврата. Хуже делать вид, что сделки под конкретного клиента и есть продуктовая стратегия. Тогда исключение тихо становится правилом, и через год продукт превращается в ту самую очередь внешних запросов.