Зачем проджекту Lean Canvas и как его сделать? + Шаблон

Всем привет! Решила не откладывать в долгий ящик и, раз в прошлой статье про бизнес-кейс (что это, кому нужен, для чего, как сделать) я упомянула, что на том же самом этапе инициации проекта вместо бизнес-кейса предпочитают разрабатывать Lean Canvas, то решила про этот артефакт и писать.

Пойдем, как обычно, по порядку: что это за документ, какие задачи решает, кому нужно делать, как его делать, потом какие-нибудь выводы сформулируем. Разбирать буду на примере, потому что так оно веселее. Не мудрствуя лукаво, вперед!

В переводе с английского Canvas — это «холст», по сути, этот артефакт так и строится «с чистого листа (холста)», куда в определенном порядке выписываются ключевые элементы проекта и / или идеи.

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

Поэтому Business Model Canvas был переработан в Lean Canvas (автор Э. Маурья), чтобы помочь сосредоточиться на предпринимателе и его новом продукте, потому что доработка была на основе фреймворка «бережливый стартап», Lean Startup. То есть мы берем бережливую модель производства + MVP нового продукта + реальные боли будущих потребителей + потребности бизнеса, а потом фиксируем это все на одном листе в специально отведенных под это местах:

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

Кому нужно делать такой документ?

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

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

Элементы в порядке их заполнения (да, заполняется не сверху-вниз и не слева-направо, а по клиенто- и проблемно-ориентированной логике) и кратко содержание блока:

Подготовила вам шаблон для заполнения / копирования / иных целей на русском языке:

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

Сегменты клиентов (Customer Segments)

Ключевой вопрос: «Кто будет использовать приложение?».

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

Важно, что в основе заполнения пункта лежит не наша фантазия, а предположения на основании изученных / проведенных анкетирований, опросов респондентов, глубинных интервью, то есть какой-то доказательной базы.

Проблема (Problem)

Ключевой вопрос: «Какую проблему решает приложение?».

Мы предполагаем, что люди в наших целевых сегментах

Здесь тоже помним, что в основе лежат исследования трендов, потребностей, рынка и т. д.

Уникальное ценностное предложение (Unique Value Proposition)

Ключевой вопрос: «Почему это приложение лучше других?».

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

По составлению УЦП есть свои методологии и процессы, они тоже в основе имеют, например, А/В тестирования. Про них скоро выйдет статья от продуктового маркетолога и меня для блога сервиса Кайтен.

Решение (Solution)

Ключевой вопрос: «Как приложение решает проблему ЦА?».

Уведомления и напоминания, на основании информации о пользователе о его целях, потребностях и обычном режиме гидратации, ежедневные цели по потреблению воды, отслеживание прогресса, предоставление статистики и рекомендаций.

Решение формулируется на основании конкурентного анализа, анализа рынка и стратегий развития.

Каналы (Channels)

Ключевой вопрос: «Как мы будем привлекать и удерживать пользователей?».

Предполагаем, что наиболее эффективным будет продвижение через социальные сети, коллаборации с фитнес-блогерами, размещение в App Store и Google Play, размещение рекламы в фитнес-залах (партнерство с крупными студиями).

Источники доходов (Revenue Streams)

Ключевой вопрос: «Как ваше приложение будет приносить доход?».

Бесплатная базовая версия + подписка на 1 / 3/ 6 / 12 месяцев на премиум-функции (интеграция с фитнес-трекерами и персонализированные рекомендации) + покупка разовых рекомендаций без подписки. Ожидаемый средний чек ХХ руб., возможная стоимость подписки ХХ руб.

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

Структура затрат (Cost Structure)

Ключевой вопрос: «Какие затраты потребуются для разработки и поддержания приложения?».

Разработка приложения (аналитика, бекенд, флаттер, тестирование), маркетинг, поддержка серверов, обслуживание приложения (техподдержка), общий бюджет на разработку до ХХ руб., на маркетинг до ХХ руб., на обслуживание ХХ руб.

Ключевые метрики (Key Metrics)

Ключевой вопрос: «Какие метрики будут использоваться для оценки успеха приложения?».

Количество активных пользователей не ниже ХХ чел. /мес., уровень удержания пользователей, количество подписок на премиум-версию. Ожиданий по остальным метрикам пока нет.

То есть мы предполагаем, что точно будет трекать эти метрики, но пока не знаем наши ожидания по минимальным / средним значениям, какие еще будут метрики, то же количество скачиваний, темпы роста и т. д., как часто будет трекать тоже пока не знаем, но учитывая подписочную модель понимаем по трендам рынка, что ниже ХХ человек в месяц нам невыгодно держать приложение.

Нечестное преимущество (Unfair Advantage)

Ключевой вопрос: «Что у вас есть такого, чего нет у конкурентов?».

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

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

Выглядеть это в заполненном виде может так:

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

О чем вам это скажет?

О том, что идея, скорее всего, сыровата, и ее не нужно пускать в реализацию. Бывает иногда такое у бизнеса: хотим сделать вот это, проблему это не решит, аудитории под это решение нет, как монетизировать не уверены, но идея — огонь! Канва эти моменты выявляет очень хорошо.

Поэтому проджекту Lean Canvas нужно уметь делать, чтобы:

И на основании как раз этой информации принимать решение о запуске / отклонении проекта.

Самостоятельно я такой документ за 5 лет работы в ИТ составляла 1 раз (когда от и до сама по конкретному продукту, материалам исследований и анализу рынка), остальные разы (целых три!) — в составе команды, мы разбирали, советовались, формулировали то, что в итоге входило в виде текста в документ, потом получали одобрение гипотезы и приступали к разработке. Так как я была у истоков идеи, мне было легче подбирать людей на проект по разработке и объяснять им цели и задачи. В этом еще один такой вот проджектовский плюс я вижу. Поэтому на других проектах продуктовой разработки я бы повторила этот подход.

А как у вас обстоят дела с этим артефактом? Работали или не приходилось? Залетайте на мой менеджерский огонек и делитесь своими историями: