Что такое продукт?

2021.03.03 (ред. 2024.05.23)

Часто ли вам приходится иметь дело с продуктом, у которого пока нет ни одной продажи, ни одной активации, а в штате уже несколько команд разработчиков, которые никак не могут попасть фичами в рынок? В компании крайне нервная обстановка. CPO/PO/CTO постоянно нервничает, и сетует на отсутствие внятных критериев сбора и обработки фидбэка с рынка. Инвесторы нервничают, потому что всему есть предел - они уже вбухали несколько миллионов, а толку пока никакого. Разработчики чувствуют, что пилят в стол. И только CEO продолжает всех успокаивать и обещать золотые горы. Именно в такой ситуации находится сейчас один из стартапов, CEO которого я недавно консультировал.

В 2016-м году я был на конференции ScrumDay в Москве. Когда в самом начале дня участники самоорганизованно придумывали себе темы для обсуждения, меня привлек лист с надписью "Что такое продукт?". Как сейчас помню недоумение и растерянность на лице автора этой темы. Я был возле этой станции почти весь день. Чего мы ему только не вещали: и story map, и value proposition canvas, но никто из нас так и не смог помочь автору разобраться. Чтобы до конца ответить на этот вопрос, мне понадобилось ещё два-три года, и я до сих пор не уверен, что знаю ответ на 100%.

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

У меня PSPOIII, и это значит, что я минимум три раза сдавал экзамен на PO. Помню, там было много интересных вопросов, и вот один из них. Инкремент продукта имеет ценность, если:

  1. содержит все фичи, которые хотел product owner
  2. был зарелизен вовремя
  3. соответствует спецухе от бизнес-аналитика
  4. снижает операционные расходы в долгосрочной перспективе
  5. скорее всего повысит удовлетворенность заказчика/рынка
Правильные ответы - последние два. И если с пятым всё более менее понятно, то с четвертым лично у меня был полный туман до конца 2019 года, когда мне посчастливилось побывать на курсе CEO IT во ФРИИ.

В первый день на курсе был Илья Красинский, который проводил бизнес-игру с апельсинами. Пока у него за спиной пятеро участников увлеченно перекладывали апельсины из одной коробки в другую, он постоянно расхаживал туда-сюда с бутылкой воды в руках и разговаривал с остальной аудиторией. Самый крутой вопрос, который я от него тогда услышал: "Разработка - это всегда долго, дорого и с багами. Зачем бизнесу разработчики? Какую основную функцию они выполняют? На какую бизнес-метрику они действительно могут повлиять?". Правильный ответ перенес меня назад к тому самому 4-му правильному варианту ответа на вопрос про ценность инкремента продукта. "COGS - расходы на обслуживание".

Что же такое продукт?

Ценность чего измеряется, кроме customer satisfaction, дельтой по операционным расходам?

Позже я встретил такое определение от евангелистов скрама: Your product is a vehicle to deliver your value proposition - it shouldn’t drive your value proposition. Но именно это чаще всего происходит:

  1. CEO берет свой вижн продукта
  2. автоматизирует его с помощью команды разработчиков
  3. и потом пытается создать поток привлечения, продаж и обслуживания клиентов.
Формально, эти три шага верные. И даже порядок почти верный. CEO перепутал только шаги 2 и 3. Однако, концептуально здесь происходит попытка натянуть сову на глобус.

Сначала прицел сбивается на втором шаге. CEO приходится делать слишком много допущений, чтобы в разработке появилась хоть какая-то определенность. Именно по этой причине CEO стремится отгородиться от команды разработчиков какой-нибудь IT-менеджерской ролью (SM, PO, CPO, CTO, CIO и т.п.). Отмечу, что я ни в коем случае не против этих ролей. Дополнительная роль точно нужна, но явно позже. Затем прицел сбивается на третьем шаге, когда Sales&Marketing пытаются запустить реальных клиентов в уже автоматизированные каналы. Разработка по фидбэку от клиентов превращает архитектуру в кровавое месево, TCO взлетает до небес, клиенты не покупают (а те которые купили, создают такие проблемы, что лучше бы не покупали).

CEO искренне полагает, что причина проблем продаж и обслуживания находится в разработке. И это правда, если конечно мы правильно понимаем слово "разработка". Для CEO разработка - это процесс написания и отладки IT-средств, доступ к которым компания сможет продавать по модели SaaS (например) и на этом зарабатывать. А продукт - это те самые IT-средства (SaaS Web и/или мобильные приложения).

На самом деле разработка - это процесс итерационного снижения рисков бизнеса. Production, куда IT-шники так любят (или не любят) деплоить - это не продукт, это буквально фабрика по производству продукта. Давайте ещё раз и внимательно. Разработчики не занимаются производством продукта. Они разрабатывают средства производства продукта - софт, который, будучи запущенным, представляет из себя процесс производства и поставки продукции по запросу пришедшего клиента с себестоимостью практически 0 руб (электроэнергию и связь можно не учитывать). То, что CEO называет продуктом - это production, канал поставки продукта. Но что же такое тогда продукт?

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

Основные элементы любого продукта - это ценность и заказчик. Заказчик готов заплатить определенную цену за некоторую выгоду для себя. Заказчиком может быть как рынок, так и конкретный человек. По этой причине, когда мы говорим "продукт", мы должны подразумевать вполне конкретную ценность и столь же определенного заказчика, что очень часто не происходит в случае IT-продукта. Мы сначала автоматизируем что-то, а потом пытаемся придумать, кому и по какой цене это продать. Нет рынка - нет ценности. Управление продуктом - это на самом деле управление рынком.

Давайте разберем простой пример. Что является продуктом интернет-провайдера (напр., Ростелеком). Интернет? И да, и нет. Интернет нужен всем, и в то же самое время - никому. Никто не хочет интернет ради интернета. У людей разные потребности, которые они привыкли (или могут) удовлетворять с помощью интернета. Это значит, что реальными продуктами ISP являются конкретные тарифы, пакеты, нацеленные на разные целевые аудитории (рынки).

При этом интернет-роутер часто используется как часть продукта в составе тарифа/пакета. Однако, этот же самый интернет-роутер можно купить как самостоятельный продукт в компьютерном магазине. Подбор интернет-роутера под потребности, тонкая настройка интернет-роутеров, ремонт интернет-роутеров - это продукты (услуги), которые также можно попрбовать выводить на рынок по отдельности или же включить в виде части продукта в тариф/пакет.

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

Типы продукта/рынка

Можно выделить 4 основных типов продукта, которые рынок будет или не будет готов воспринимать, в зависимости от своего состояния осознания ценности:

  1. Проект - индивидуальное решение с рисками по цене, ценность которого надо подробно объяснять вплоть до расчета ROI.
  2. Готовое решение - типовое тиражируемое решение, с фиксированной ценой на старте, ценность всё ещё надо объяснять.
  3. Товар - ценность всем очевидна, отстройка от конкурентов происходит добавочными характеристиками или тупо ценой продукта.
  4. Сервис, услуга - ценность потребляется напрямую, продукт растворяется в канале поставки.
Можно декомпозировать эти типы более детально (см. 8 типов продукта). Ещё можно назвать эти типы стадиями развития. Любой продукт (рынок) проходит эти стадии сверху вниз, зацикливаясь в начало.

Проект

Если отгрузка ценности заказчику представляет из себя уникальную сборку индивидуального решения из множества компонентов, то скорее всего это проект. Из-за очень высокой сложности решения, цена для заказчика может сильно отличаться при продаже и при отгрузке. Однако, заказчик к этому готов и поэтому при продаже проекта обязательно идет речь о рисках. Наличие некоторой технологической базы, платформы, позволяет сузить люфт цены, но совсем убрать пока ещё не получается.

Частотность попадания заказчика в целевую ситуацию очень низкая, из-за чего маркетинг очень сложный. Сначала нужно долго заниматься осведомлением заказчика в одном или нескольких каналах, и только затем в каком-то специальном канале происходит лидогенерация и начинается диалог (при чем почти никогда с тем же человеком, который был успешно осведомлен). На стороне заказчика обязательно будут какие-то закупочные комитеты, под которых надо делать подробное коммерческое предложение с обоснованием окупаемости вложений и ценностью для каждого из участников. Если речь идет о какой-то инновационной технологии, ценность которой в принципе не удается обосновать, то наверняка заказчиком является какой-то стратег, который меняет большие суммы денег на некоторую надежду в результате дорогостоящих экспериментов получить нечестное конкурентное преимущество на рынке, с большими рисками не получить ничего вообще.

Структура принятия решения на стороне заказчика тоже сложно-составная. Кто-то высказывает потребность, проблему и спускает на другого участника. Тот берет на себя ответственность за решение и начинает крутить варианты. Подбор конкретного подрядчика (исполнителя) он поручает какому-то третьему участнику, и т.д. Если заказчик достаточно квалифицированный, то он не будет фиксировать ТЗ, прекрасно осознавая свою некомпетентность, как источник потребности в проекте. Чаще всего ТЗ пишет исполнитель исходя из некоторого брифа заказчика.

Самый простой пример: строительство частного дома на заказ. В поиске, выборе и принятии решения участвует всё семейство, и роль принимающего решения не всегда у отца. Это может быть даже ребенок, который выбирает под какие-то свои критерии из нескольких вариантов, а все остальные только влияют на его решение. Пример из IT-отрасли - SAP, в успешности внедрения которого можно много и часто сомневаться.

Готовое решение

В отличие от проекта, этот тип продукта не является индивидуальным. Это типовое решение, которое подбирается исполнителем под потребность заказчика. Основной критерий, по которому можно отделить его от проекта - конкретная цена, которая не изменится при доставке ценности. Однако, заказчик всё ещё сравнивает продукт с предыдущим способом удовлетворения своей потребности, а не с другими продуктами того же типа. По этой причине, ценность ему нужно объяснять в терминах его предыдущего (существующего) опыта. Описание ценности, также как и для проекта, должно содержать в себе проблему и решение с ценой/затратами.

Частотность попадания в целевую ситуацию уже сильно выше. Поэтому маркетинг существенно упрощается. И если в случае проектов чаще всего приходится целиться очень узко с кучей разных параметров сегментирования (либо вообще в конкретных людей), то здесь появляется возможность выделять сегменты более привычным способом - по отрасли, по размеру, по решаемой проблеме, и т.д. Здесь уже можно спокойно пробовать использовать одинаковые каналы для осведомления и лидогенерации.

Пример готового решения из мира IT: 1С. Фиксированная цена конкретной конфигурации напрямую связана либо с потребностью (бухгалтерия, документооборот, торговля/склад, логистика, и т.д.), либо с отраслью (общепит, салон красоты, бухгалтерия строительной организации, и т.д.). Причем заказчик понимает, что фиксированная цена - это только начало геморроя с сопровождением, поддержкой, за которую ему точно надо будет позже раскошеливаться дополнительно.

Товар

Когда заказчику уже не надо объяснять ценность продукта, на первое место выходят какие-то добавочные характеристики или тупо цена. Если проект и готовое решение заказчик сравнивал со своим предыдущим опытом и выбор делал на основе экспертизы подрядчика (исполнителя), то тут он начинает сравнивать разные продукты одной категории между собой, совершенно четко понимая свою потребность. На этом этапе заказчик может спокойно писать ТЗ и быть уверенным в том, что он знает, что хочет получить.

Частотность потребления - высокая. Маркетинг превращается в прямое предложение покупки. Можно выделить некоторое идеальное состояние продукта данного типа, при котором легкость потребления доведена до предела и значение имеет только цена. Например, бензин. За исключением риска нарваться на некачественное топливо, заказчику настолько безразличны маркетинговые усилия поставщика, что мы видим большое табло с ценами на разные стандартные типы топливо на некотором расстоянии до заправочной станции. К данном типу, аля commodity, стремится любой рынок.

Сервис, услуга

Все предыдущие типы продуктов фактически заставляли заказчика покупать то, что ему по большому счету не надо. Ведь заказчику не нужен продукт, ему нужна выгода. Скажу аллегорией. Когда вы покупаете бутылку воды, сама бутылка настолько бесполезна, что после поглощения воды она почти сразу же оказывается в мусорном ведре. Однако, без определенной тары (в данном случае - бутылки) будет очень сложно утолить жажду.

Также и с продуктом. В scrum guide дается такое определение продукта: транспортное средство, которое доставляет ценность. Так вот сервис, услуга, это когда заказчик получает ценность без необходимости покупать продукт. Сервис и есть сам продукт. Иными словами, пользовательский опыт заказчика настолько хорошо разработан, что ему не составляет никакого труда переключиться с одного продукта данного типа на другой. По этой причине вместо ценности продукта при продаже используются либо эмоции, впечатления, либо свойства маркетинговых каналов поставки.

Например, каршэринг. Часто выбор конкретной машины и поставщика делается просто по наличию доступного автомобиля поблизости или удобства работы мобильного приложения. Все подписные сервисы попадают в эту категорию: мобильные приложения мессенджеров, сотовая связь, банковский сектор... Из реального сектора это фастфуд, автомойки, сапожные мастерские...

Если вам приходится говорить с вашим потребителем о его проблеме и решении, то вы точно не про сервис. С другой стороны, именно IT-продукты очень быстро добегают до этого состояния из проектов и готовых решений. Так происходит, на мой взгляд, потому, что полностью цифровые рынки не имеют физических границ и ограничены только какими-то культурными, языковыми или юридическими рамками. Когда кто-то захотел упаковать готовое IT-решение в сервис, ему достаточно развернуть соответствующую IT-инфраструктуру. Затраты на производоство равны нулю, в переменные расходы уходит только маркетинг.

Разработка продукта

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

  1. взять вижн, который содержит сценарий привлечения, продаж и пост-продажного обслуживания с фактами и гипотезами (допущениями)
  2. как можно дешевле и быстрее прогнать по сценарию несколько клиентов (пресловутое MVP)
  3. откорректировать вижн, и если всё ещё есть гипотезы в сценарии, возвращаемся на шаг 2
  4. полученный фактический сценарий отгрузить в разработку

Эти 4 шага составляет первый этап CustDev, который называется Customer Discovery. Успешное прохождение этого этапа называется Problem-Solution Fit (PSF). И если погружаться в детали, то на самом деле на втором шаге делается три "подхода к снаряду":

  1. проблемное интервью - находим частотную потребность, решая которую можно попробовать заработать денег
  2. решенческое интервью - убеждаемся, что мы правильно поняли потребность
  3. MVP - убеждаемся, что мы правильно поняли границы и состав продукта

Когда PSF достигнут, полученный сценарий привлечения, продаж и обслуживания является уже отчуждаемой экспертизой и его можно отгружать в разработку, маркетинг, продажи и аккаунтинг. Если CEO нацелен на полностью цифровой продукт, то в пределе он видит полностью автоматизированное пост-продажное обслуживание, и вполне вероятно полностью автоматизированные каналы привлечения и продаж. И вот когда есть фактический поток продаж и обслуживания как текущее состояние продукта, и полностью автоматизированный поток как целевое, уже не возникает вопроса - что пилить? Возникает вопрос, где, что и как автоматизировать в первую очередь, чтобы:

Разработчики, также как команда роста (growth team) работают по конкретным метрикам в этом потоке. И можно крутить OKR-ы, если хочется.

И это всё в принципе можно менять. Есть уважаемые мною люди, которые чихать хотели на границы между этими итерациями. Есть не менее уважаемые мною люди, которые берут лидов для проблемных интервью сразу же из каналов, попутно измеряя CPA (cost per acquisition). И на моей практике была положительная история, когда CEO ничего не проверяя сразу же нанимал разработчиков, и у него даже получалось делать продажи, и аджайл позволял ему быстро адаптировать продукт вместе с теми жесткими маневрами, которые ему приходилось делать. Правила предназначены для того, чтобы их нарушать.

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

Что делать?

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

Лучше всего отгружать вижн в виде диаграммы CJM, USP, service blueprint или аналогичной. Чтобы убедиться, что отгрузка произошла правильно, попроси каждого члена команды разработчиков взять его в руки и рассказать тебе как работает твой бизнес.

Если ты уже успел нанять разработчиков без проверенного сценария в сегменте (без продукта на рынке), то не спеши их увольнять. Вполне возможно, что твой вижн окажется очень близко к фактическому сценарию. Я бы на твоем месте нарисовал service blueprint, разделил разным цветом факты и гипотезы и отгрузил в разработку. Далее взял бы в помощь внешнюю продуктовую экспертизу (SM с такой экспертизой, или трэкер) и побежал с ним (с ней) искать PSF, ограничив поиск по сроку в 2-3 месяца. И пока идет процесс поиска, разработчики выдохнут и спокойно и без нервов отдадут тех долги и приведут архитектуру в потребное состояние. И когда у тебя будет фактический сценарий, им уже будет гораздо легче и поэтому они смогут быстрее адаптировать продакшн к бизнесу, который фактически получился.

Разве не бывает исключений?

Есть ещё один тонкий момент с разработкой. Можно подумать, что я только что наложил запрет CEO ходить к разработчикам до момента PSF, и фактически ограничил его рамками т.н. мартышкиного типа проверки гипотезы ценности (вместо пары разработчиков найми 200 индусов на проектную работу). Нет, конечно не так. Когда CEO идет к разработчикам до PSF, он должен четко знать ответ на вопрос - нафига? Какую задачу я решаю с помощью разработки?

Цель второй стадии поиска PSF, решенческое интервью - убедиться, что мы правильно поняли потребность. Если в процессе переговоров клиент никак не может вьехать в то, что ему предлагают, то либо (чаще всего!) проблема плохо оцифрована, либо (гораздо реже!!!) действительно нужная какая-то автоматизация для демонстрации решения. Давайте почувствуем разницу между автоматизацией маркетинговых каналов, и макетным образцом продукта, который сделан только для того, чтобы провести решенческое интервью. Чаще всего достаточно описания или, на худой конец UX/UI-макетов, если речь идет об IT.

Цель третьей итерации поиска PSF, ручная отгрузка ценности - убедиться, что мы у нас есть все необходимые технологии и экспертиза, чтоб решить проблему/задачу клиента. Тут действительно может понадобится какая-то автоматизация, особенно для b2b сегментов. Но опять таки, есть огромная разница между автоматизацией каналов поставки/пост-продажного обслуживания с целью снижения операционных затрат, для чего нужна команда, отдельная роль руководителя этой команды, инфраструктура и т.д., и разработкой MVP с целью проверки границ и состава продукта, для чего, как правило, нужно 1-3 программиста на разовую работу.

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