Инструмент позволяет посмотреть на продукт со всех сторон и оценить его сильные и слабые стороны. Обобобщая, Lean Canvas — это одностраничный документ, разделенный на девять блоков и позволяющий определить области риска и возможностей новой идеи.

1. Сегменты клиентов – кто будет покупать и пользоваться продуктом. Также здесь важно указать ранних последователей – людей, которые произведут первые продажи.
2. Проблема – 3 основные проблемы вашего клиента и существующие альтернативы (как потребитель решает эти проблемы сейчас).
3. Потоки доходов – источники дохода. Как продукт будет себя окупать?
4. Решение – обрисуйте возможное решение для каждой проблемы.
5. Уникальное ценностное предложение – которое позволит превратить неосведомленного потребителя в потенциального клиента. Иными словами, концепция высокого уровня – описание идеи простыми словами
6. Каналы взаимодействия с потенциальными клиентами
7. Ключевые показатели роста продукта.
8. Структура постоянных и переменных затрат.
9. Несправедливое преимущество – то, что невозможно легко скопировать или купить.

Как и MVP, CustDev — это скорее стратегический подход, чем структура. Но это все же концепция, которая лежит в основе практически любого продуктового исследования.

После проведения более 700+личных интервью и проектирования еще сотен, мы с командой решили собрать в единую статью: гайд и примеры проведения Глубинных интервью (или в простонародье кастдева), которые вы можете применить в своих проектах.

Ознакомиться с гайдом можно здесь.

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

3 этапа работы в рамках методологии Value Delivery:

1. Определение проблемы и последовательности работы с продуктом.

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

2.Работа с техническими рисками

• Установка способов решения технических рисков перед стартом проекта

Эта система может быть либо про время, либо про людей.

В первом случае на решение экстренных задач выделено конкретное время. Например, раз в квартал. Во втором случае, это фиксированная команда, которую привлекают для "тушения пожара”.

• Разбивка проекта на спринты

Один из способов проверить, достаточно ли вы разбили работу на мелкие фрагменты, - это спросить себя: “Что произойдет, если какой-то й этап не будет выполнен или займет больше времени, чем ожидалось?”. Если это приведет к нестабильности, то нужно продолжать разбивку.

3.Установка реалистичных этапов внедрения новых функций

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

То привязка к объему работ, чтобы не растягивать процесс разработки, требует четкого ответа на вопросы:

• Что нам нужно узнать в этом запуске?

• Что нужно сделать, чтобы получить ответ на первый вопрос?

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

TARS – это сокращение: Targeted (целевой), Adopted (принятие), Retained (удержанный) и Satisfied (удовлетворенный).

Targeted. Вся ЦА, которая потенциально может воспользоваться новой фичей.
Если разработка ведется для всей пользовательской базы, то ваша целевая аудитория по TARS может отражать целевую аудиторию всего продукта. В ином случае, сюда должны быть включены только конкретные сегементы аудитории.

Базово при определении ЦА новой функции нужно понимать:

• Пример использования продукта.
• Демография пользователя.
• Уровень взаимодействия с продуктом.
• Уровень опыта работы с продуктом.
• Тип клиента (бесплатный, базовый платный, премиум).

Adopted. Доля ЦА, которая использует функцию.

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

• Установить измеряемое событие. Пользователи, которые завершают это событие, должны впервые ощутить ценность функции.

Примеры.
Мобильное приложение Dropbox. Когда пользователь сохраняет свой первый файл в Dropbox через мобильный телефон.
Подкасты Spotify: прослушивание одной минуты подкаста.
Webflow: публикация сайта.

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

Если компания не обладает средними рыночными показателями, то оценка должна зависеть от степени серьезности проблемы, которую решает функция. Для высокого уровня серьезности итоговый показатель должен быть не ниже 80%, для низкого – 30-40%.

Retained. Доля ЦА, которая остается после использования (можно пропустить на низкочастотных продуктах)

Этот показатель может подсветить, что фича не предоставляет достаточной ценности или имеет проблемы с удобством использования. Т.е указывает на необходимость дальнейших улучшений.
Можно ссылаться на метрику удержания как на ежедневных активных пользователей (DAU), еженедельных активных пользователей (WAU) или ежемесячных активных пользователей (MAU).

Анализ удержания.

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

• Ось Y - это процент пользователей, которые повторно используют функцию
• Ось X - это время. (Для DAU – день, для WAU – неделя и т.д.)

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

Оценка показателей также зависит от степени серьезности проблемы, которую решает новая функция. Для высокого уровня серьезности итоговый показатель удержания должен быть не ниже 50%, для низкого уровня – 10-20%.

Satisfied. Доля тех, кто доволен функцией

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

Мы рекомендуем использовать Customer Effort Score (CES) для измерения удовлетворенности пользователей.

Получив все необходимые данные, мы получаем 4 направления развития новой функции:

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

Существует три общие категории каналов роста, которые, в свою очередь, разделены на 12 подкатегорий.

Viral loops

• Из уст в уста.

Один пользователь рассказывает другому о продукте/услуге за пределами продукта.

• Органический.

Один пользователь приглашает другого без рефереальной программы.

• Случайный контакт.

Один пользователь использует продукт и случайно демонстрирует его непользователям.

• Стимуляция.

Пользователи делятся продуктом за вознаграждение от компании.

Content loops

• Пользовательский контент – User Distributed (UGC-UD).

Пользователь создает контент, где использует продукт и делится на разных площадках.

• Пользовательский контент – Company Distributed (UGC-CD).

Пользователь создает контент, где использует продукт, а компания распространяет его, как правило, через SEO.

• Контент, созданный компанией- User Distributed (CGC-UD).

Компания создает контент, который привлекает больше пользователей, пользователи распространяют контент, как правило, через социальные сети.

• Контент, созданный компанией - Company Distributed (CGC-CD).

Компания создает контент, который привлекает больше пользователей, а затем распространяет его, как правило, через SEO.

Paid loops

• Реклама.
• Интеграция.

Компания инвестирует капитал от новых пользователей для создания интеграций, которые затем распространяются партнерами или самой компанией.

• Входящие продажи через партнеров.
• Исходящие (холодные) продажи.

Чтобы определить первый канал роста, нужно выявить:

Model Channel Fit.
Например, продукты с низким ARPU (среднем доход на пользователя) должны использовать каналы с соответствующим низким CAC (стоимость привлечения клиентов).

Product Channel Fit.
Если мы намерены использовать Content loops, то наш продукт должен мотивировать пользователей на создание контента. Для некоторых проектов на рынке нужно использовать два канала – по одному на каждую роль пользователя.

Пример. Поскольку Airbnb имеет более низкий ARPU для гостей, чем для хозяев, они используют стимулированный Viral loop для гостей и Paid loops для хостов.

Вопросы для определения Product Channel Fit

Viral loops

• Из уст в уста. Может ли опыт работы с продуктом создать толпу поклонников, которые будут говорить о нашем продукте с другими?
• Органический. Как продукт будет делать пользовательский опыт лучше, если потребитель будет делиться им с другими?
• Случайный контакт. Есть ли способ случайно попасть в поле зрения не пользователя?
• Стимуляция. Зарабатываем ли мы достаточно денег на одного пользователя, чтобы предложить вознаграждение за приглашение друзей?

Content loops

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

Paid loops

• Реклама. Это продукт, который можно легко описать в объявлении? Можем ли мы эффективно ориентироваться на нашу целевую аудиторию и охватить достаточное количество на рекламной платформе? Можем ли мы получать доход от пользователей достаточно быстро, чтобы поддерживать разумный период окупаемости?
• Интеграция. Есть ли потенциальные партнеры, которые могли бы расширить нашу ЦА?
• Входящие продажи. Ожидают ли клиенты взаимодействие с человеком перед покупкой продукта?
• Исходящие продажи. На сколько сложный наш продукт, чтобы потенциальный покупатель испытывал трудности с покупкой и использованием?

После бенчмаркинга более 100 стартапов Шон Эллис (автор книги Hacking Growth) спросил пользователей, насколько они были бы разочарованы, если бы больше не могли пользоваться тем или иным продуктом. Полученные данные показали, что компании с более чем 40% “растроенных” пользователей продолжали строить успешный бизнес.

Как провести тест.

Выберите целевую группу для опроса. В идеале это должны быть:

• Пользователи, которые испытали ваш продукт по крайней мере дважды
• Пользователи, которые испытали ваш продукт в течение последних двух недель
• Пользователи, которые испытали ваш премиум-продукт (в пробной версии и/или в качестве подписчика)

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

• Очень разочарован
• Немного разочарован
• Не разочарован

Проанализируйте результаты.
Если >40% респондентов говорят, что они будут "очень разочарованы", то вы можете быть уверены, что у вас есть первоначальный PMF.

По сути, Discovery — это расследование, которое проводится на ранних стадиях разработки проекта с целью понять: кто является нашим клиентом и важна ли для них проблема, которую мы пытаемся решить.

Это первый этап методологии Customer Development, и он нужен для проверки наших начальных гипотез о продукте. В ходе Discoveryопределяются потребности пользователей, а также осуществляется сбор информации для дальнейшего планирования и разработки проекта.

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

Самая важная стоимость эксперимента, которую нужно учитывать, - время. Время для запуска и анализа результатов.

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

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

Выражается в процентах (до 10%, где 10 – это эталон и, как правило, недостижимый).

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

Предположим, что сейчас у нас 100 000 платных пользователей в месяц.
Годовая стоимость – это сколько стоит каждый из этих платных пользователей в год. Если каждый платит 100 рублей в месяц (1200 рублей в год) и в среднем подписан на 90% года. То каждый пользователь стоит около 1080 рублей в год.
Таким образом, получается 108 млн. рублей.

• Коэффициент дисконтирования стоит учитывать, когда мы понимаем, что новое постепенное улучшение может быть более низкого качества

Например, новые пользователи с гипотезы могут иметь более низкое годовое значение.

Оценка уверенности (CONFIDENCE)
Это вероятность успеха. Определять уверенность можно по шкале L/M/H.

• Low. Это новая область, над которой мы никогда не работали и о которой мало что знаем. Оценка уверенности до 30%
• Medium. У нас есть некоторый опыт и знания, но мы не очень уверены в себе. Оценка уверенности до 60%
• High. Область, где у нас много опыта, много информации или много обучения. Оценка уверенности до 90%

Оценка усилий или время получения результата

Время получения результатов - это ожидаемое время, которое потребуется от запуска теста до его завершения.

Рассчитывается по формуле:
Выборка А/В тестирования*/объем чистого трафика

*Требуемый размер выборки рассчитывается по калькулятору Эвана Миллера. Полезный материал, как работать с калькулятором здесь.

В этом выпуске дайджеста мы решили представить фремворки, которые проверены крупными зарубежными компаниями (Uber, Dropbox Malwarebytes и др). Вместить все в один дайджест не получилось, но в одном из следующих выпусков мы расскажем о фремворках для:

• User Research
• Product Strategy
• RoadMaps & Goal Setting

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