Часто ли вам приходится иметь дело с продуктом, у которого пока нет ни одной продажи, ни одной активации, а в штате уже несколько команд разработчиков, которые никак не могут попасть фичами в рынок? В компании крайне нервная обстановка. 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. Но что же такое тогда продукт?

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

Что же такое продукт? Я выработал, выстрадал своё определение. Продукт изнутри - это сценарий пост-продажного обслуживания клиента. Продукт вовне - это путь решения задачи клиента. Пусть вас не смущает слово "обслуживание", потому что будучи полностью автоматизированным, оно превращается в автоматизированное обслуживание или даже самообслуживание. Вот вам ещё годные определения:

• Комбинация ресурсов организации, спроектированных чтобы предложить потребителю некую ценность. (ITIL4)
• Набор товаров/услуг вместе с рецептом их применения для решения конкретной задачи клиента. (Ниязи Хатипов, 7 ключей)
• Способ поставки ценности клиенту. Может представлять из себя товар и (или) услугу. Как правило состоит из технического решения и организованного процесса использования этого решения. (Дмитрий Козлов, Северсталь)

Когда мы говорим "продукт", мы сразу же подразумеваем (или проговариваем) продуктовую ценность и рынок. Нет рынка - нет ценности. Управление продуктом - это на самом деле управление рынком. А дальше можно и нужно использовать продукт, как товар (набор функционала), и сделать на основе него сервис (SLA). В какой-то момент нужно понять, что пора остановить продуктовую разработку и заняться настройкой и отладкой сервисов вокруг него.

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

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

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

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

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

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

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

• снизить операционные фикс расходы в конкретной точке потока продаж/обслуживания
• повысить пропускную способность потока, опять таки, в конкретной его точке и путем снижения расходов
• улучшить UX, чтобы повысить customer satisfaction в целом.

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

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

Однако, коллеги CEO, давайте будем честными друг с другом. У нас с вами должны быть стальные яйца, чтобы нарушать принципы CustDev-а. Это можно делать только при полном понимании, почему принципы такие, и какие именно проблемы мы создаем, и какие риски принимаем на себя. Тот самый CEO, которого я упомянул в предыдущем абзаце, не смог долго вывезти такой нагрузки, нанял себе fake-PO и компания "успешно" превратилась в зомби.

Что делать?

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

• у тебя есть сценарий продаж и пост-продажного обслуживания
• в этом сценарии нет гипотез, одни факты
• если у тебя несколько сегментов, то ты проверил сценарий на реальных клиентах в каждом (!) из сегментов

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

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

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

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

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

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

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