Суть «теории работ» в том, чтобы определить реальные задачи пользователей, связанные с продуктом, и контекст их решения. Основываясь на этих данных, вносить изменения в продукт, влияющие на рост ключевых метрик.
Существуют разные трактовки JTBD и подходы к работе с теорией. Для команды роста важно не закопаться в исследованиях, а найти быстрые решения, которые дадут измеримый результат.
Подход Growth Team строится следующим образом:
1. Определить задачу и метрики для отслеживания
Прежде, чем брать инструмент в работу, нужно понять, какую задачу хочет решить команда и определить связанную метрику, влияние на которую будет определять результат.
Для сервиса такси, например, задачей может быть увеличение числа поездок за счет уменьшения количества отказов в момент ожидания машины. Метрика – процент отказов.
2. Сформулировать Job Stories
Job Stories помогают сфокусироваться на ситуациях, мотивации и ожидаемом результате, который нужен пользователю.
Формула: Когда + Я хочу + Чтобы
Участники команды предлагают свои варианты историй, исходя из понимания продукта, запросов пользователей, данных аналитики.
Пример Job Story для сервиса такси:
— Когда машина едет на мой заказ дольше изначально указанного времени
— Я хочу знать реальное время подачи
— Чтобы уведомить коллег об опоздании и внести изменения в план на день
3. Провести интервью с пользователями
Убедиться в том, что Job Stories имеют реальное подтверждение, можно пообщавшись с пользователями сервиса, которые недавно отменяли заказ по причине долгого ожидания.
В процессе интервью необходимо выяснить контекст, в котором находился каждый пользователь, мотивацию и дальнейшие действия после отказа.
Важно не озвучивать свое видение, а собирать информацию о реальном опыте пользователей.
По результатам нескольких интервью вы сможете сгруппировать Job Stories по повторяемости или сформулировать новые, неочевидные ранее.
4. Сгенерировать гипотезы
Если в ходе интервью вы обнаружили подтверждение существующих у пользователей задач, можно перейти к генерации гипотез. Одна Job Story может иметь несколько разных способов решений и наоборот, одно решение может закрывать сразу несколько Job Stories.
Для более четкого понимания, что именно нужно сделать в продукте, необходимо сформулировать гипотезы решений.
В формулировке гипотезы должно содержаться предполагаемое изменение на стороне продукта и измеримый эффект, к которому оно может привести.
Например: Если отправлять пользователям сообщения об изменении времени подачи при опоздании водителя, то это позволит снизить количество отказов на 10%.
5. Протестировать изменения
Для тестирования изменений не обязательно разрабатывать новый функционал или дорабатывать текущий. На стадии проверки гипотезы вы можете воспроизвести его в ручном режиме.
Например, в течение какого-то времени отслеживать ситуации, когда первоначальное время подачи уже прошло, а машина еще не приехала на заказ. Смотреть на карте расположение водителя и пассажира, высчитывать фактическое время приезда, звонить или отправлять пассажиру адресное сообщение, объясняющее ситуацию.
Если тестирование показывает, что процент отказов при таком подходе ниже, чем когда пассажир не получает информацию об опоздании, можно переходить к внедрению эксперимента на стороне продукта.
Jobs To Be Done – очень многогранная теория, применять которую можно по разному и для разных задач. Важно помнить, что от команды роста требуется высокая скорость проверки гипотез, поэтому нет возможности проводить длительные, сложные исследования.
Для применимости инструмента допустимы упрощения, которые не противоречат исходной логике и помогают команде в быстром поиске возможностей для роста.