В данной статье я делюсь своим опытом в том, зачем, когда и как заполнять канвасы бизнес-модели. Отчасти, статья может быть полезна в любых бизнес-проектах, но в силу моего фокуса проф интереса в продуктовой IT-разработке, больше всего ценности статья даст начинающим IT-предпринимателям и SPM (software project/product managers). Если вы успешный предприниматель, и вам не хватает IT-экспертизы, то для вас статья также может быть полезна. В любом случае, если у вас не стоит задача активно расти в рынке, то нет смысла дальше читать - я намеренно не буду рассматривать такие случаи использования канвасов.

Когда и зачем нужен канвас бизнес-модели?

Есть такой старый анекдот в тему. Почему санитары всегда ходят вдвоем? Один из них знает куда ставить клизму, а другой знает зачем.

Сама по себе бизнес-модель является достаточно иерархически-высоким ответом на вопрос "зачем" - в ней описаны все ключевые функции и элементы бизнеса. И на рынке есть много всяких продактов и аналитиков, которые знают как заполнять разные канвасы бизнес-моделей. Я и сам когда-то давно в 2015 году писал в своем резюме, что умею такое. Но не менее важным и, как мне кажется, первостепенным является знание другого порядка - зачем нужно заполнять эти канвасы?

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

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

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

Бизнес-модель в разработке

Для IT-разработки модель бизнеса важна потому, что помогает ответить на вопрос "зачем". По-существу, IT-разработка нужна только для того, чтобы расшить узкие места и ограничения, мешающие масштабировать бизнес.

Расходы на разработку - это не переменно-прямые затраты (var cost). Маржинальный доход не увеличится от сокращения расходов в разработку. Если, конечно, вы не продаете аутсорсинг разработки (или проекты). К условно-постоянным затратам (fix cost) её можно отнести только в случае поддержки/сопровождения. Активная же разработка достаточно больших функциональных блоков - это как минимум кап затраты, потому что так вы хотя бы можете снизить налогооблагаемую базу. Но если это просто капэксы, то не совсем понятно как мерить её ценность для бизнеса? Поэтому, в идеале, разработка - это инвестиции, о возврате которых желательно подумать до того, как вы начали их тратить.

Разработка - это всегда долго, дорого и с багами. Как возвращаются инвестиции в разработку? Только через рост бизнеса, который стал возможен благодаря этой разработке. Есть два типа ограничений роста бизнеса, которые расшиваются с помощью IT-разработки: низкая удовлетворенность клиента (плохой клиентский и/или пользовательский опыт, он же CX/UX) и высокие операционные издержки. До тех пор, пока у вас нет идеи масштабировать бизнес, у вас нет и ограничений роста, а значит есть риск получить неадекватный возврат инвестиций в разработку. Подробнее о бизнес-ценности IT-разработки я пишу отдельную статью.

Для разработки бизнес-модель помогает увидеть ключевые метрики и прицелить разработку в те из них, которые отражают главное ограничение роста бизнеса в продукте. Скорее всего там нужно будет провести некоторое количество малобюджетных экспериментов, чтобы снизить риски неадекватного ROI в разработке. Этим занимаются аналитики и UX-дизайнеры. Но в целом смысл в том, чтобы правильно делегировать ответственность за продукт в разработку. И пока разработчики работают, предприниматель, глядя в бизнес-модель, сосредотачивается на поиске и проверке механизмов роста бизнеса.

Как выбрать канвас?

Есть разные канвасы. Самые популярные три: Business Model Canvas (Остервальдер), Lean Model Canvas (Аш Маурья) и Value Proposition Canvas (Остервальдер). Далее я буду сокращенно употреблять их соответственно - BMC, LMC и VPC. Какой из них надо использовать для разработки бизнес-модели?

Лично я всегда использую BMC потому, что достаточно хорошо ориентируюсь в нюансах таких понятий как уникальное ценностное предложение (оно же УТП), кривая принятия инноваций, ключевая экспертиза, MVP, продуктовая упаковка, отстройка от конкурентов и т.д. Однако, для предпринимателя и его менеджеров это всё может быть совсем не знакомо, и именно по этой причине есть ситуации, когда лучше использовать другие канвасы.

Например, если у вас продукт относится к одному из первых четырех типов (технологии, проекты, платформа, готовое решение), то вам как минимум нужно будет добавить VPC к BMC, чтобы тщательно проработать и проверить ценностное предложение. Либо в этом случае можно переключиться на LMC, потому что в нём есть необходимые элементы для обоснования ценности.

Если вы делаете бизнес на основе инновационного продукта, то вам придется иметь дело с ресегментацией рынка и поэтому лучше с самого начала выбрать LMC, в котором есть отдельный блок для ранних последователей и конкурентов замены. Для IT бизнес-проектов это почти всегда так, потому что скопировать продукт на одном и том же рынке не получится. В целом LMC лучше подходит для IT-проектов и стартапов, ориентированных на агрессивный рост в рынке. BMC в этом смысле больше похож на чистый лист бумаги, и добавление VPC, особенно в случае подрывных инноваций, не сильно спасает ситуацию.

Если у вас бизнес с минимальными рисками по части рынка, рынок стабилен, и основные риски находятся в технологиях, производстве, поставщиках и тому подобном "бэкофисе", лучше сразу же выбрать BMC. Крайний пример, который вспоминается мне из моего опыта - оборудование для геофизических исследований в нефтяных скважинах. Я искренне пробовал найти там риски по части рынка, но не нашел от слова совсем. Все риски были в производстве, поставщиках и партнёрах. LMC и даже VPC не было смысла даже пробовать.

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

Где взять шаблон?

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

Скачайте картинку соответствующего канваса, откройте его на компьютере или телефоне, и срисуйте на лист бумаги подходящего размера. Вот вам готовые картинки для скачивания с официальных ресурсов их авторов на начало декабря 2023 года: BMC, VPC, LMC. Лично я люблю вешать заполненные канвасы на стенку в офисе, для чего очень хорошо подходит бумажный (малярный) скотч.

Как заполнять канвас?

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

Итак, поскольку задача в активном, если не сказать аггресивном росте, с самого начала нужно поставить цель - какой оборот и когда мы хотим иметь по этой модели? В канвасе LMC сразу же пишем это число с не шибко точной датой (год/месяц) в ячейку Metrics. Если используем BMC, то там такой ячейки нет, пишите куда-то над канвасом. Не надо писать точные цифры - грубо, в качестве ориентира. Вам нужен желаемый порядок цифр. Чтобы увидеть объем необходимого бизнес-результата, сразу же рядом поставьте текущий год-месяц и впишите туда текущий оборот по этой модели, вероятно он у вас уже есть. Аш Маурья, автор LMC, советует ставить цель в этом блоке не более чем на три года. С учетом текущей обстановки в мире на конец 2023 года, я б не пытался ставить более чем на 1 год.

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

Продукт

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

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

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

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

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

Можно назвать эти типы стадиями развития. Любой продукт (рынок) проходит эти стадии сверху вниз, зацикливаясь в начало.

Проект

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

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

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

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

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

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

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

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

Товар

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

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

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

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

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

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

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

Продуктовые блоки на канвасе

Так почему же идея сначала запилить, а потом придумать кому и как продать, так плохо воплощается для IT-продуктов?

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

Как двигается успешный IT-продукт? Ресегментацией рынка. Сначала выбирается достаточно узкий сегмент рынка, где можно за счет точечной отстройки от конкурентов быстро вырасти, а затем уже происходит расширение в соседние сегменты. Иначе говоря, даже если наш конечный продукт подписной, сначала в любом случае придется искать на рынке какую-то неудовлетворенную потребность, решение, ценность, и только потом станет понятно, что же всё таки надо автоматизировать, чтобы расти в рынке.

В остальном, если ваш тип продукта - "товар" или "сервис/услуга", то просто вырезаем определенный кусок рынка (чаще всего по территориальному признаку), пишем его в Customer Segments. Затем кратко описываем продукт с учетом отстройки и размещаем стикер в Value Proposition. Дальше переходим к каналам.

Проблема

В случае IT-продукта скорее всего у вас проект или готовое решение, и поэтому клиент будет сравнивать вас с предыдущим способом удовлетворения своей потребности. По этой причине вам нужно найти проблему, которая есть у вашего целевого клиента ещё до того, как он что-то узнал о вашем продукте. Поэтому сразу же задаем себе вопрос: почему клиент захочет что-то менять? Рынок уже живет без вас определенным образом, и даже если там кого-то что-то не устраивает, сила привычки (инерция рынка) здесь работает против вас. Например, если вы делаете он-лайн магазин по продаже автомобильных шин, то на рынке уже есть определенные стереотипы потребления шин. Почему клиенту надо что-то менять в том, как он сейчас покупает автомобильные шины? Иначе говоря, какую проблему на рынке вы решаете вашим он-лайн магазином? Если у вас LMC, то добавляем стикер с проблемой в блок Problem, если BMC - в блок Customer Segments.

Автор LMC советует использовать технику 5-почему для получения хорошего описания проблемы. Пишете исходную проблему на стикер, спрашиваете себя "почему это происходит у клиента?" - получается 1+ причин этой проблемы, которые также пишем на стикеры. К ним также задаем этот же вопрос, и так далее. Получается дерево проблем на стикерах. Выбирайте из всего дерева 2-3 стикера, которые наиболее хорошо отражают решаемую вами проблему.

Отстройка через проблему всегда означает, что вы занимаетесь ресегментацией - выделяете относительно узкий сегмент, который вы можете скушать достаточно быстро за счет точного попадания в его неудовлетворенную потребность. Это ваш идеальный клиент, при условии, конечно, что у вас сходится экономика. Именно его проблему и надо использовать, а его профиль пишем в блок Early Adopters (или в Customer Segments, если у вас BMC). Однако, поскольку сегмент Early Adopters сам по себе не очень интересный, реальная цель - другие, более крупные сегменты, в которые вы собираетесь выйти. Поэтому есть смысл коротко перечислить их в блоке Customer Segments. Не надо тратить на это слишком много времени. Достаточно убедиться, что в целом в рынке денег достаточно, чтобы вам была интересна вся эта затея.

Часто проблема, которую вы сформулировали, является скрытым решением. Так происходит потому, что мы чаще думаем о нашем продукте, его функциях и пользе. И гораздо реже мы думаем о том, как рынок живет сейчас без нашего продукта. Чтобы проверить проблему, спросите себя - как сейчас идеальный клиент решает свою проблему? Это конкуренты замены, которые используют ваши будущие клиенты на рынке. Вполне возможно, что клиентов вполне устраивают альтернативы и они не захотят переключаться на что-то ещё? Если не устраивают, то чем именно? Впишите альтернативы в блок Existing Alternatives (или в блок Customer Segments, если у вас BMC).

Решение

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

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

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

Опишите ключевые изменения, которые необходимо принять клиенту, чтобы получить выгоду и поместите его в блок Solution (если у вас LMC) или в блок Value Proposition (если у вас BMC). Убедитесь, что из получившегося описания клиенту будет понятно, как меняется его текущий потребительский опыт. Здесь может запросто оказаться, что цена ваших продуктов/услуг в решении - лишь часть всех расходов клиента. Заранее подумайте, какие это будут расходы?

Теперь клиенту понятно, какую выгоду он получит, а также к каким изменениям ему надо готовиться. Но, вероятно, от вашего первоначального описания продукта ничего не осталось. Клиенту может быть непонятно, что же все таки вы делаете? Если такая проблема есть, то какое-то простое объяснение сути вашего продукта в двух-трех словах может быть очень полезно. Например, "CRM-система" или "Сервис доставки горячей еды". Размещаем это описание в блоке High-Level Concept (или в Value Proposition, если заполняем BMC).

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

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

Каналы

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

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

Осведомление и лидогенерация

Для первых четырех типов продукта это практически единственный способ создать рыночный запрос на ваш продукт. Например, если вы продаете обучающие курсы за относительно большой чек (30-40-50 тыс руб) в аудиторию со средним доходом, то вам понадобится сначала достаточно качественно проблематизировать клиента, чтобы он захотел изучить что-то новое для себя. Вы ещё ничего не рассказываете ему о своём курсе, только делитесь с ним своей экспертизой по части его проблем и их реальных причин. У клиента случаются инсайты и он обращает на вас внимание, подписывается на вас и т.д.

Осведомленный (прогретый) клиент в какой-то момент захочет провалиться в вашу воронку продаж, для чего ему понадобится один из каналов данного типа. Для того же примера с обучающим курсом, клиент, будучи вашим подписчиком, в какой-то момент настолько прогревается, что становится готовым прийти на ваш бесплатный (или дешевый) вебинар, где вы уже можете попробовать продать ему ваш курс. Интересно, что чем сложнее продукт (ближе к 1-2 типам), тем больше вероятности, что вам придется иметь разные каналы для осведомления и лидогенерации. Тогда как в районе 4-5 типов, можно использовать один канал для обеих этих функций.

Прямая реклама

Если у вас тип продукта 5+, то рынок уже вполне спокойно реагирует на прямой призыв к покупке вашего продукта. А ближе к 7-8 даже начинает недекватно реагировать на попытки заниматься осведомлением и лидогенерацией. Например, попытка объяснить ценность бензина на коммерческой АЗС (commodity тип) выглядит абсурдно. Вместо этого мы видим табло сразу с ценами за литр разных типов бензина у дороги на некотором расстоянии до самой АЗС.

Коммуникация

Достаточно общий термин, к которому можно отнести каналы других типов. Коммуникация бывает разносторонней и на разных стадиях работы с клиентом. Например, вывеска "ремонт обуви" на входе в мастерскую - это канал односторонней исходящей коммуникации с клиентами, которые живут или работают в районе местонахождения мастерской. Другой пример: мини-пульт "оцените уровень обслуживания" с кнопками "плохо/хорошо" в туалете парижского аэропорта - канал односторонней входящей коммуникации с клиентами. Это были простые примеры, которые навряд ли достойны для стикеров на канвасе. Вот вам более реальный пример. Горячая линия, телефонный номер которой указан на упаковке вашей продукции, представленной на полках торговой сети - канал двухсторонней коммуникации для этапов продажи и пост-продажного обслуживания.

Продажа

Может показаться достаточно банальным выделять под это отдельный стикер, но не спешите с выводами. Например, если вы производите топливо-раздаточные колонки (ТРК), то завод по производству АЗС - это ваш клиент или канал продаж? Другой пример: вы сделали мобильное приложение для торговых команд производственных компаний. В этом случае BTL-агенство, которое продает им же аутстаффинг торговых представителей, и поэтому покупает у вас приложения для их контроля - это ваш клиент или канал продаж во всё те же производственные компании?

Как уже стало наверняка понятно из ответов, каналы продаж могут быть достаточно неожиданными: от торговых точек до производителей, которые перепродают ваш продукт с некоторой добавленной ценностью. Для таких даже есть специальный термин - канал с добавленной ценностью (VAC - value added channel). На самом деле, это очень важный тип, потому что бизнес - это канал продаж прежде всего. Это значит, что бизнес-риски в первую очередь надо искать именно там.

Поставка

Для IT-продукта очень важный тип, потому что именно от него во-многом зависит профиль команды разработчиков. Если вы делаете CRM-систему для стоматологий, то скорее всего для администратора нужно будет выбрать web- или desktop-приложение в качестве канала, а для глав врача или собственника - мобильное приложение. Мобильное приложение, как канал поставки продукта, также нуждается в канале для поставки (простите за тавтологию) - AppStore, PlayMarket, RuStore и т.д.

Я не оговорился, приложение - это чаще всего не продукт, а канал поставки. Это может быть шокирующей новостью, потому что данное заблуждение довольно распространено. Продукт - это способ поставки ценности. Канал - способ поставки продукта. Например, ценность стоматологической CRM-системы - управление загрузкой клиники. Эту же самую ценность можно упаковать в другие продукты - консалтинг, обучающие курсы для владельцев клиник и их администраторов. Можно выбрать совершенно разные каналы поставки CRM-системы: от мобильного приложения до стационарного терминала с тач скрином. Именно поэтому вам скорее всего не нужны разработчики на этапе разработки продукта. Они вам понадобятся позже, когда вы уже разработаете (найдете) продукт, и перейдете к разработке (поиску) и автоматизации каналов.

Пост-продажное обслуживание

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

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

Удержание и развитие

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

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

Реферальные программы, когда вы получаете некоторый бонус, если приведете другого человека, который также станет клиентом - это также каналы развития. Есть даже автоматизированные партнерские программы, где можно получать деньги за трафик (модель называется CPA - cost per action). Для BMC стикеры с каналами удержания и развития можно размещать в Relationships. Для LMC отдельного блока нет, поэтому размещаем их в Channels.

Выручка

Собственно то, ради чего нужен весь вышеперечисленный движ - клиент платит деньги вам в кассу и получает ваш продукт. Если он доволен, то он возвращается и/или приводит к вам других клиентов. Вспоминаем, что нас интересует рост бизнеса, и пишем в этот блок средний чек сделки, которую мы хотим масштабировать. Даже если вам кажется, что у вас 100500 разных товаров в магазине, среди них есть идеальный комплект, который сделает вам 80% вашего дохода. Вот его сумму чека и надо написать в блок Revenue streams.

Если вы зарабатываете на подписном сервисе, то навряд ли вы сможете найти интересную бизнес-модель на клиентах, которые пользуются месяц-два и потом уходят. Скорее всего, ваша экономика сойдется на длительной дистанции клиента - 6-12-18 месяцев. Это значит, что сюда нужно писать не MRR (ежемесячный чек), а LTV - сумму всех чеков, которые вы получите от клиента за все время его "жизни" в сервисе.

У вас несколько разных тарифов и вы не понимаете какой из них надо сюда писать? Всё просто: у вас есть целевой тариф с вполне конкретной ЦА, для которой он идеальной подходит. Целевой, это значит что на нём вы собираетесь заработать больше всего - выделите его. Конечно, это не значит, что мы не продаем другие тарифы другим клиентам. Речь о том, чтобы сфокусироваться и контролировать рост бизнеса, иначе канвас будет перегружен и станет бесполезен - я видел такое, не надо так делать.

Статья в разработке...