Два менеджера одного возраста покупают один и тот же планировщик. Первый в понедельник утром: не успевает к дедлайну. Второй в воскресенье вечером: не может уснуть от списка дел в голове. Реклама для "менеджеров 30-40 лет" не попадёт ни в одного.
Продукт нанимают под ситуацию, и сегмент её не видит
Jobs To Be Done часто сводят к формуле интервью или к красивой схеме. Смысл метода проще: он возвращает продукту связь с реальными причинами выбора. Клейтон Кристенсен с соавторами описал эту логику в книге "Competing Against Luck" (2016) и в статье "Know Your Customers' Jobs to Be Done" в Harvard Business Review за сентябрь 2016 года: люди "нанимают" продукт, чтобы продвинуться в конкретной ситуации, и "увольняют" его, когда он перестаёт с этим справляться.
Причину плохих продаж обычно ищут в аудитории: не та демография, не тот сегмент, не те фичи. Логика кажется очевидной, но она проскакивает мимо момента, где решение о покупке действительно принимается. Люди одного сегмента покупают по разным причинам и в разных обстоятельствах. Если рамка выбрана неверно, точный расчёт не поможет, сколько бы денег ни ушло в рекламу.
JTBD переносит вопрос на шаг раньше. Команда спрашивает, в какой ситуации её выбирают. Вопрос "кто наш пользователь" остаётся, но становится вторым.
Работа даёт маркетингу и продукту один критерий спора
Всё ломается, когда у маркетинга и продукта нет общей опоры. Маркетинг оперирует сегментами и воронками, продукт фичами и roadmap, и свести две картины к одному решению не на чем. Маркетинг обещает одно, продукт делает другое, пользователь ожидает третье. Каждое решение по отдельности выглядит разумным, а вместе они не складываются в одно обещание.
Работа, ради которой продукт нанимают, применима и к приоритетам разработки, и к тексту на лендинге. Поэтому спор о том, чья метрика важнее, сменяется общим вопросом: усиливает ли решение эту работу.
Возьмём тот же планировщик. На квартал в план разработки претендуют две задачи: интеграция с корпоративным календарём, которую просит отдел продаж, и режим "выгрузить всё за пять минут", который предлагает продуктовая команда. По сегментам спор не решается: календарь нужен "менеджерам", режим выгрузки тоже. По работе решается сразу. Если продукт нанимают, чтобы снять тревогу в момент перегрузки, режим выгрузки усиливает эту работу напрямую, а интеграция с календарём полезна позже, когда задачи уже разобраны. Календарь не выбрасывают, его ставят вторым.
Отсутствие такого критерия видно по продукту задолго до отчётов. Исследования собирают абстрактные "боли": пользователям "неудобно", "долго", "дорого". Превратить их в решения трудно, потому что они вырваны из контекста выбора. Разработка выпускает набор фич без общей логики, каждая вроде бы полезна, а продукт не становится сильнее. Маркетинг постоянно меняет формулировки, а отклик не растёт. Если продукт нельзя описать одним предложением о том, в какой момент он нужен, работы в основании скорее всего нет.
Где искать работу? В моменте переключения
Работу редко угадывают с первого раза. Команда может неверно определить её, перепутать контекст или переоценить мотив, и это нормальный этап поиска. Важно, на каком материале она ошибается. Ошибка, сделанная на реальных историях выбора, быстро исправляется. Ошибка, сделанная на мнениях о гипотетическом продукте, живёт годами.
Поэтому основной материал JTBD составляют истории переключения: человек пользовался одним решением, затем перешёл на другое. Разбирать стоит конкретный последний раз. Когда он понял, что старое решение не справляется? Что он попробовал до вас? Что почти заставило его остаться? Вопрос "купили бы вы такой продукт?" здесь бесполезен: отвечать на него ничего не стоит, и люди охотно говорят "да". Прошлое поведение честнее. На что человек уже потратил деньги или вечер, то для него и важно.
Удобнее всего восстанавливать историю по времени, от первой мысли до первого использования. Сначала человек замечает, что старое решение подводит, но ничего не делает. Потом начинает присматриваться к вариантам. Потом происходит событие, после которого ждать уже нельзя: сорванный дедлайн, разговор с начальником, бессонная ночь. Это и есть триггер.
Отдельно стоит спросить, что удерживало человека на старом решении: привычка, страх потратить время на настройку, деньги, уже заплаченные за другой сервис. Эти тормоза так же важны для маркетинга, как и сам триггер, потому что лендинг должен снимать их прямо.
Затраты здесь небольшие. Восемь интервью с людьми, которые перешли на продукт за последние 90 дней, по 45 минут каждое, дают шесть часов разговоров и примерно столько же на разбор. Если в пяти-шести историях из восьми повторяется один и тот же триггер, у команды есть рабочая гипотеза. Если триггеры все разные, рынок, возможно, нанимает продукт под несколько работ, и выбирать основную придётся отдельно.
Результат работы оставляет два характерных следа. Первый: job story, короткая история работы. В отличие от user story и персоны, в ней есть ситуация, повод, желаемый прогресс и ожидаемый результат: "Когда в пятницу вечером у меня в голове двадцать незакрытых дел, я хочу за пять минут выгрузить их куда-то, чтобы спокойно провести выходные". Второй: карта переключений. Она показывает, от какого решения пользователь ушёл, к чему пришёл и почему. Если команда не может ответить, что было "до" продукта, метод используется поверхностно, и методология превращается в ритуал.
Подмены работы слышны по фразам команды
Почти каждый провал сводится к подмене: на место работы встаёт что-то более привычное и лучше видимое. Портрет аудитории рисуется по CRM за полчаса, контекст найма приходится выкапывать из разговоров. "Работу" описывают через функциональность, потому что фичи уже лежат в бэклоге. Альтернативы сужают до прямого конкурента, потому что его видно, а блокнот, таблицу или вариант "ничего не делать" не видно нигде. В итоге позиционирование строится против не того соперника.
Услышать подмену можно в том, как команда говорит о рынке. У каждой фразы есть вопрос, который возвращает разговор к работе:
- "Наша аудитория: предприниматели 25-45" описывает кого угодно. Вопрос взамен: что случилось у последнего клиента в день, когда он начал искать решение?
- "Им просто нужна удобная функция" подменяет прогресс пользователя свойством продукта. Вопрос взамен: что человек сможет сделать после покупки, чего не мог до неё?
- "JTBD у нас есть, вот презентация" выдаёт метод, застрявший на слайдах. Вопрос взамен: какое решение за последний квартал изменилось из-за этих выводов?
- "Давайте добавим ещё один сценарий" выдаёт попытку обслужить все работы сразу. Вопрос взамен: какая работа основная и что мы ради неё откладываем?
- "Пользователи сами не знают, чего хотят" служит поводом не искать триггер. Вопрос взамен: что они делали в последний раз, когда старое решение подвело?
Дороже всего обходится страх неприятных выводов. Сигнал, что продукт нанимают "не за тем", игнорируют, чтобы не пересобирать стратегию. Тот же страх толкает закрыть все работы сразу, отчего продукт теряет фокус, и не проверять рекламные сообщения на реальных ситуациях. Проверка могла бы показать, что выбранная работа не главная.
Тревога и защита решения: две истории подмены
Как звучит эта подмена в жизни продукта и что даёт возврат к работе, видно на двух историях. Обе сложены из типичных ситуаций, конкретных компаний за ними нет, цифры придуманы для наглядности.
Компания развивала онлайн-сервис для планирования задач. Функции добавлялись, а рост замедлился: маркетинг жаловался на слабую конверсию, продуктовая команда на "непонятных пользователей". Решения принимали по опросам и NPS. Серия интервью о переключении показала, что продукт нанимают для снижения тревоги в моменты перегрузки. Люди уходили к нему из блокнотов и заметок, функции планирования их почти не интересовали.
Команда пересобрала коммуникацию вокруг момента "когда всё валится и нужен контроль". Заголовок и онбординг повели через сценарий разгрузки в аврал, а первый экран вместо календаря с фичами предложил быстрый способ выгрузить всё из головы.
Допустим, такой сдвиг поднимает удержание на второй неделе с 18% до 27%. Механизм понятен: люди быстрее доходят до момента, ради которого продукт и нанимают. При 10 000 регистраций в месяц это 900 дополнительных активных пользователей на второй неделе без дополнительного рекламного бюджета.
Во втором случае B2B-продукт для аналитики терял сделки на поздних этапах. Product Manager считал, что дело в цене, маркетинг винил каналы. Интервью показали другое: продукт нанимали как страховку от управленческого риска. Покупателю нужна была уверенность в решении, которое ему предстояло защищать перед руководством.
В корпоративной закупке решение почти никогда не принимает один человек. Подключаются финансы, ИТ, безопасность, будущие пользователи, и большую часть этих разговоров поставщик не слышит. Значит, внутри компании продукт продаёт ваш сторонник (в продажах его называют чемпионом), и ему нужны готовые аргументы для этих разговоров.
Команда пересобрала демо: вместо тура по дашбордам продавцы вели покупателя по пути "вот как вы защитите это решение перед руководством" и заранее давали аргументы и слайды под этот разговор. Сделка раньше вставала на внутреннем согласовании, теперь покупатель приходил туда подготовленным. Финальный этап цикла сократился с месяцев до недель.
Когда сегментация права, а JTBD почти бесполезен
Маркетолог, который отвечает за медиабюджет, возразит резонно. Рекламные системы продают показы по демографии, интересам и поведению. Купить "ситуацию перегрузки в воскресенье вечером" нельзя. Значит, сколько бы команда ни знала о работе, деньги в итоге всё равно распределяются по сегментам, и тратить месяцы на интервью вместо тестов таргетинга кажется роскошью.
Этот аргумент верен в части медиазакупки. JTBD действительно не говорит, где покупать трафик. Он говорит, что написать в объявлении, какой момент ловить и какую фичу тянуть в приоритет первой. Сегмент отвечает на вопрос "кому показывать", работа на вопрос "что показывать". Поэтому для одного и того же сегмента под разные работы пишут разные предложения.
Рабочее правило для выбора отправной точки: сравните конверсию или удержание между сегментами и внутри них. Если разница между сегментами больше чем в два раза, начинайте с сегментации, она объясняет главное. Если сегменты похожи, а разброс внутри каждого большой, причина в ситуациях, и время идти в интервью о переключении.
Есть и случаи, где метод слабеет или требует оговорок:
- В B2B и сложных дорогих сделках он работает лучше, чем в массовых продуктах, потому что причина выбора спрятана за формальными требованиями. Ломается он там, где команда принимает закупочные критерии за настоящую работу.
- В массовых продуктах он помогает, пока пользователь помнит, когда старое решение перестало справляться. Если переключение давно стало автоматическим, триггер уже не вспомнить.
- При привычном или импульсном выборе интервью может не восстановить триггер: осознанного момента найма просто нет. Сопоставьте рассказ с наблюдаемым поведением и не выдавайте реконструкцию за установленную причину.
- Когда пользователь и покупатель разные люди, работ тоже две. Сотрудник нанимает сервис, чтобы меньше возиться с отчётами, руководитель покупает его, чтобы видеть загрузку команды. Лендинг для одного и демо для другого строятся вокруг разных ситуаций.
Персоны JTBD не отменяет. Они остаются фоном, а решения опираются на работу. У продукта обычно одна основная работа и несколько вторичных, и попытка обслужить все сразу размывает ценность.
Как проверить работу до того, как переписывать лендинг?
Работа, восстановленная по восьми разговорам, остаётся гипотезой. Подтверждает или опровергает её поведение, и самый дешёвый способ проверки обычно A/B-тест посадочной страницы. Версия A описывает продукт через функции, версия B через ситуацию из job story.
Прикинем размер такого теста. Формула для оценки на глаз: размер выборки на вариант = 16 × p × (1 минус p) / d², где p базовая конверсия, а d абсолютный прирост, который нужно заметить. Текущая конверсия страницы в регистрацию 3%, команда хочет заметить рост на 20% относительно, до 3,6%. При уровне значимости 5% и мощности 80% стандартная оценка даёт около 16 × 0,03 × 0,97 / 0,006², то есть примерно 12 900 посетителей на вариант. При 1 000 посетителей в день, поделённых пополам, тест займёт около 26 дней.
Останавливать его раньше по первому зелёному графику нельзя. Если каждый день заглядывать в результат и закрывать тест при первом значимом p, шанс объявить победу там, где эффекта нет, оказывается в разы выше заявленных 5%: за 26 дней у случайного шума много попыток один раз выглядеть как успех. Если трафика меньше, честнее проверять работу на продажах: дать отделу продаж новый сценарий первого звонка и сравнить долю перешедших на следующий этап за месяц.
Успех мерьте двумя цифрами. Основная: доля новых пользователей, которые в первую неделю выполнили действие, соответствующее работе, например выгрузили в планировщик больше десяти задач. Контрольная: стоимость привлечения и доля возвратов. Если активация растёт, а возвраты тоже, новое сообщение обещает работу, которую продукт выполняет хуже, чем говорит лендинг.
Ошибку в выборе работы выдают и другие симптомы. Регистраций стало больше, а удержание на четвёртой неделе не сдвинулось: сообщение попало в ситуацию, а продукт в ней не помогает, и чинить надо онбординг. Отдел продаж охотно пользуется новым сценарием, но сделки по-прежнему встают на согласовании: работа угадана для пользователя, а для покупателя нет. В обоих случаях первое действие одно и то же: вернуться к картам переключений и проверить, чья история легла в основу job story.
Проверить себя перед стартом можно по нескольким вопросам: знаете ли вы, в какой момент вас нанимают и от какого решения приходят пользователи; можете ли описать работу, не упоминая продукт; влияет ли она на план разработки; учитываете ли альтернативу "ничего не делать"; меняются ли решения после интервью. Восемь интервью показывают механизм выбора. Сколько людей на рынке нанимают продукт под эту работу, покажут уже трафик и продажи.
Последний из этих вопросов самый неудобный. Если после восьми интервью в дорожной карте не сдвинулась ни одна строчка, команда либо нашла не ту работу, либо выслушала людей и вернулась к прежнему плану.