У меня для вас две новости.
Хорошая и плохая.
С какой начнём?
Чёрт, я расчитывал, что вы сначала прочитаете плохую новость и не был к этому готов.
Всё равно начну с плохой
Кастдев умер
Customer Development — это не просто «поговорить, наконец, с клиентом», это большой и мощный фреймворк пошагового снижения неопределённости при создания продукта с нуля.
Как инструмент, Customer Development устарел, так как не позволяет:
Учитывать разные потребности сегментов клиентов на разных этапах из развития и в разных контекстах
Ежедневно/еженедельно фокусировать на снижении неопределённости в рутинной работе предпринимателя / продакта. Но ведь за каждой новой фичой почти всегда стоит какое-то рискованное предположение, которое может убить эту фичу. И хорошо бы её проверить без разработки.
Думать про решение не только болей клиентов, но и возможностей для вовлечения в новый кайфовый продукт
Гибко использовать MVP. В Customer Development это способ понять, нужен продукт людям или нет, хотя в процессе снижения неопределённости это лучший способ количественно провалидировать рискованные компоненты юнит-экономики.
Но продукты-то делать нужно.
Кипиайи и окиары сами себя не выполнят
На смену кастдеву пришли три новых инструмента: Jobs To Be Done, Riskiest Assumption Test и процесс проверки гипотез
JTBD
Думать про решение не только болей клиентов, но и возможностей для вовлечения в новый кайфовый продукт
Даёт простой и эффективный инструмент описания потребности клиента: Job Story. С его помощью удобно дистиллировать из JTBD интервью ключевые потребности, удобно выделять сегменты
Даёт возможность увидеть возможности для delighters [продуктов, которые приносят кайф и улучшают текущий опыт], а не только какие боли чинить
RAT
Помогает в каждый момент времени находить самое рискованное предположение, которое с наибольшей вероятностью убьёт идею продукта/фичи RAT и сформулировать способ проверки этого рискованного предположения
Процесс проверки гипотез
Фокусирует на ритмичности проверки гипотез. За каждой новой фичей стоит гипотеза Job Story [потребости клиента], которая может не подтвердиться. За фичей стоит гипотеза, что наше решение решает потребность клиента, ведь мы можем ошибиться и сделать неправильный интерфейс, написать кривой текст email'а.
Если над этими двумя инструментами JTBD и RAT поднять процесс проверки гипотез, на выходе мы получаем команду [продакта, организацию], которая неделя за неделей проверяет гипотезы:
Провели 10 JTBD-интервью и оказалось, что ТАКОЙ JS ни у кого нет, зато нашли пачку новых
Верна ли эта гипотеза Job Story, которую мы придумали?
Сэкономили в среднем миллион рублей на ненужную фичу
За неделю провели 12 решенческих интервью, с четырьмя сделали консьерж- MVP, один купил. Так себе результат, зато собрали возражения и можем пойти на следующую итерацию решенческих интервью после переделки предложения
Решает ли наш продукт Job Stories наших клиентов?
Сэкономили миллион
Выгрузили 1000 номеров телефонов, написали всем в вацап, посмотрели % ответов. Устраивает. Супер!
Ой, в нашей фиче мы исходим из рискованного предположения, что большая часть наших клиентов пользуются WhatsApp
Фух, сняли риск
Кастдев умер, да здравствуют Jobs To Be Done, Riskiest Assumption Test и процесс проверки гипотез