309. Битком 24: продукт для работ, но без монетизации

В самом начале проекта «Битком 24» основатель выдвинул две задачи, которые на деле оказались двумя работами по JTBD, тогда, правда, мы не называли их работами. Сейчас видно, что это job story.

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

Парадокс в том, что обе работы сервис закрывал. Загруженность как раз отвечала на вопрос «кто сейчас внутри»: в пятницу видно, что бар заполнен гостями, в понедельник утром можно посмотреть, что заведение полностью свободно.

По метрикам продукта у нас был внушительный MAU. То есть пользователей (users) было достаточно, потому что работы, описанные выше встречались достаточно часто.

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

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

#кейс@custdevlab #jtbd@custdevlab

310. Unit-экономика и custdev: зачем считать гипотезу до исследования

Расчёт гипотезы в  unit-экономике можно сделать до custdev. Он показывает, есть ли у гипотезы шанс вывести продукт в плюс по метрикам, в первую очередь по сходимости на 1-го привлеченного пользователя. Если даже с запасом по частоте и чеку плюса нет, discovery-процедуры этой гипотезы усилия не окупят: интервью подтвердит боль, а модель всё равно не сойдётся.

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

Вторая связь идёт в обратную сторону: часть метрик для этого расчёта юнит-экономики берётся из самих custdev-процедур. И это не только интервью. Как часто случается ситуация, кто платит и сколько сейчас уходит на привычный способ, можно узнать в интервью и опросах. Доходит ли пользователь до оплаты, сколько стоит канал и какой чек получается на деле, видно в тестах канала, продажах и A/B-тестах. Никто не отменял бенчмарки по отрасли, но дополнительные процедуры позволят уточнить расчеты.

Слова «я бы заплатил» в расчёт лучше не ставить как факт. То есть это не метрика, а намерение. В расчёт лучше ставить то, что пользователь уже платит сейчас, и то, заплатил ли он в проверке. Не забываем про воспринимаем метрику и реальную.

В сухом остатке: расчёт гипотезы сокращает custdev: не исследуем то, что в плюс не выведет; сами процедуры, и не только интервью, дают часть метрик, на которых этот расчёт стоит.

#unitэкономика@custdevlab #методика@custdevlab