JTBD: как применять фреймворк в продуктовых исследованиях

Пользователь отменил подписку и ушел к конкуренту. На вопрос «Почему?» он отвечает: «Там удобнее». Для продуктовой команды такой ответ мало что объясняет: непонятно, что именно оказалось удобнее, почему это стало важно именно сейчас и с чем человек вообще сравнивал продукт.

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

Идею Jobs to Be Done связывают с Клейтоном Кристенсеном и его коллегами. В основе подхода — представление о том, что люди выбирают продукты и услуги не ради набора функций как такового, а чтобы добиться определенного прогресса в конкретной ситуации.

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

Что такое JTBD и что с его помощью исследуют

В JTBD единицей анализа становится не пользователь как набор характеристик и не сам продукт, а job — задача или прогресс, которого человек пытается добиться в определенной ситуации.

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

И наоборот: одну и ту же job могут выполнять продукты из разных категорий. Если человеку нужно занять себя в дороге, альтернативами могут оказаться подкаст, книга, мобильная игра или социальная сеть. С точки зрения JTBD они конкурируют за одну ситуацию, хотя в обычном продуктовом сравнении их вряд ли назвали бы прямыми конкурентами.

Поэтому на JTBD-интервью исследуют прежде всего конкретный опыт человека:

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

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

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

Когда JTBD полезен в продуктовых исследованиях

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

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

Так можно исследовать несколько продуктовых задач.

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

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

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

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

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

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

Кого приглашать на JTBD-интервью

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

Состав респондентов зависит от вопроса исследования. Например:

• если нужно понять причины покупки — пользователи, которые недавно выбрали продукт
• если изучаем переключение с конкурента — те, кто недавно перешел с другого решения
• если хотим разобраться в отказах — люди, которые рассматривали продукт, но выбрали альтернативу
• если исследуем отток — пользователи, которые недавно перестали пользоваться продуктом или заменили его другим решением

Здесь важнее критерий отбора, чем универсальное число интервью. Если смешать в одной выборке людей с совершенно разными историями — например, новых клиентов, давних пользователей и тех, кто продукт вообще не выбрал, — сравнивать их ответы будет сложно.

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

Как провести JTBD-интервью: пять шагов

1. Найдите первую мысль о переменах

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

Например, пользователь таск-трекера говорит: «В какой-то момент стало неудобно вести проекты в таблице». Здесь полезно не переходить сразу к недостаткам таблиц, а восстановить событие:

• Когда вы впервые подумали, что таблицы вам уже не хватает?
• Что тогда происходило?
• Сколько человек было в команде?
• Что случилось непосредственно перед этой мыслью?
• Что вы сделали после этого?

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

2. Разберите прежнее решение

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

Уточните:

• Как вы решали эту задачу раньше?
• Что в этом способе вас устраивало?
• Что перестало устраивать?
• Почему вы не отказались от него раньше?
• Что удерживало от перехода на другое решение?

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

3. Восстановите поиск альтернатив

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

Спросите:

• Когда вы начали искать решение целенаправленно?
• Где искали варианты?
• Какие способы рассматривали?
• С чем сравнивали выбранный продукт?
• Какие варианты отвергли и почему?
• Кто еще участвовал в выборе?

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

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

4. Разберите момент выбора

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

Вместо вопроса «Почему вы выбрали наш продукт?» лучше разобрать сам момент решения:

• Между какими вариантами вы выбирали в конце?
• Что было важно при сравнении?
• Что понравилось в выбранном решении?
• Что вызывало сомнения?
• Был ли момент, когда вы почти отказались от покупки?
• Что в итоге перевесило?

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

5. Узнайте, что произошло после перехода

История не заканчивается оплатой или регистрацией. Стоит узнать, подтвердились ли ожидания пользователя после начала работы:

• Что вы сделали в продукте первым?
• Что оказалось сложнее, чем ожидали?
• Что, наоборот, получилось проще?
• В какой момент вы поняли, что новое решение вам подходит?
• Что изменилось по сравнению с прежним способом?

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

Четыре силы, которые влияют на переход от старого решения к новому

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

Эти силы не обязательно выяснять прямыми вопросами. Их можно находить в истории респондента. Например, фраза «мы еще месяца два сидели в таблицах, потому что переносить все проекты никто не хотел» показывает одновременно недовольство прежним способом и барьер перехода.

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

Как фиксировать результаты JTBD-интервью

Необязательно использовать специальную JTBD-карточку с жестко заданным набором полей. Главное — разбирать интервью по одной структуре, чтобы затем истории разных респондентов можно было сравнить.

Job Story можно сформулировать по схеме: «Когда [ситуация], я хочу [мотивация], чтобы [ожидаемый результат]».

Например:

Слишком узко: «Когда я пользуюсь таск-трекером, я хочу импортировать Excel».

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

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

Как обработать результаты JTBD-интервью

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

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

1. Восстановите таймлайн каждого респондента

Сначала соберите последовательность событий для каждого интервью отдельно. Например:

Ситуация: команда выросла с трех до восьми человек, задачи по-прежнему ведут в таблице и рабочих чатах

Триггер: несколько задач потерялись, один из дедлайнов пропустили

Прежнее решение: общая таблица + сообщения в чате

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

Альтернативы: оставить таблицу, доработать ее или перейти в один из трех сервисов

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

Барьер: сотрудники привыкли к таблице и не хотели переносить проекты вручную

Выбор: сервис с импортом существующих данных и подходящим тарифом

Результат: задачи и статусы проектов теперь собраны в одном месте

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

2. Сравните истории и найдите повторения

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

Допустим, три пользователя описывают разные события:

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

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

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

3. Отделите job от решения

Одна из частых ошибок при анализе — сформулировать работу через уже существующую функцию продукта.

Например:

Функция: настроить автоматические напоминания клиентам

Job: снизить количество ситуаций, когда клиент забывает о записи и специалист теряет рабочее время

Во втором случае не зашито конкретное решение. Эту задачу потенциально можно закрыть автоматическим напоминанием, ручным сообщением администратора, подтверждением записи или другим способом.

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

4. Сформулируйте jobs

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

Например:

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

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

Если получается «Когда я открываю приложение, я хочу нажать кнопку…», скорее всего, исследователь уже описывает решение. Если получается «Я хочу экономить время и работать эффективнее» — наоборот, контекста и конкретного результата недостаточно.

Как приоритизировать найденные jobs

Количество упоминаний в интервью можно учитывать, но нельзя автоматически присваивать работе высокий приоритет только потому, что ее назвали три человека из пяти. JTBD-интервью — качественный метод, а такая выборка не показывает распространенность потребности среди всей аудитории.

При разборе результатов полезнее смотреть сразу на несколько вещей:

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

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

Что запускает поиск нового решения. Чем конкретнее триггер перехода, тем понятнее, в какой момент возникает потребность в продукте.

Какие барьеры мешают перейти. Иногда job выражена сильно, но существующие решения требуют слишком дорогого или сложного перехода.

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

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

Как использовать результаты JTBD в продукте

Результатом исследования становится не только список Job Stories. Вместе с каждой работой команда получает контекст ее возникновения, альтернативы, критерии выбора и барьеры перехода. Эти данные можно использовать для разных продуктовых задач.

Для развития продукта. Если пользователи хотят перейти на сервис, но регулярно останавливаются из-за сложности переноса данных, команда может проверить гипотезу об импорте или более простом онбординге.

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

Для онбординга. Разные jobs могут требовать разных первых действий. Одному пользователю важно сразу перенести существующие данные, другому — пригласить команду, третьему — настроить первый процесс. Это можно учитывать при проектировании первых шагов в продукте.

Для дальнейших исследований. JTBD может показать отдельные вопросы, которые требуют проверки другим методом. Например, интервью обнаружили барьер в импорте данных — дальше можно провести юзабилити-тест самого импорта. Если нужно оценить, насколько проблема распространена, понадобится количественное исследование.

Как совмещать JTBD с глубинными интервью

JTBD и глубинное интервью не нужно противопоставлять. Глубинное интервью — метод исследования, а JTBD задает фокус: вместо общего разговора об опыте пользователя исследователь подробно разбирает ситуацию, в которой человек искал решение и делал выбор.

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

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

JTBD можно использовать и как часть более широкого исследования. Например, сначала поговорить с респондентом о его работе и текущих процессах, а затем подробно разобрать один недавний выбор по JTBD. Главное — заранее понимать, какую историю нужно восстановить, иначе интервью легко превращается в разговор обо всем опыте пользователя сразу.

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

Онлайн-запись
для экспертов

Всё на автопилоте: календарь, оплата, созвон, напоминания

Попробовать бесплатно

Ошибки при проведении JTBD-интервью

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

1. Спрашивать о гипотетическом поведении. Вопрос «Стали бы вы пользоваться такой функцией?» показывает отношение человека к идее, но не то, как он поведет себя в реальной ситуации. Лучше разбирать уже произошедшие события. Например, вместо «Вам были бы полезны автоматические напоминания?» спросить: «Когда клиент в последний раз не пришел на встречу? Что вы тогда сделали?»

2. Начинать с продукта. Вопрос «Почему вы выбрали наш сервис?» сразу направляет разговор к функциям, цене и интерфейсу. В JTBD интереснее то, что произошло раньше: чем человек пользовался, когда впервые задумался о переменах и что заставило его начать поиск. До самого продукта интервью дойдет позже — на этапе сравнения альтернатив.

3. Подсказывать мотив. «Вы перешли на сервис, потому что хотели экономить время?» — вопрос уже содержит предполагаемый ответ. Лучше спросить, что заставило человека искать другой способ, а затем уточнять детали. Если респондент говорит «так быстрее», выяснить, что именно раньше занимало время и в какой ситуации это стало проблемой.

4. Искать альтернативы только среди прямых конкурентов. До сервиса онлайн-записи человек мог пользоваться другим сервисом, договариваться с клиентами в Телеграме, вести расписание вручную или поручать запись администратору. Все это альтернативные способы выполнить одну job, поэтому на интервью нужно выяснять не только, какие продукты человек сравнивал, но и как он вообще решал задачу раньше.

5. Останавливаться на первом объяснении. «Было неудобно», «слишком дорого», «понравился интерфейс» сами по себе почти ничего не объясняют. За «дорого» может стоять рост стоимости после расширения команды, отказ руководителя согласовать бюджет или отсутствие достаточно ценных для пользователя функций. Задача интервьюера — восстановить конкретную ситуацию за общей оценкой.

6. Принимать функцию за job. «Хочу фильтр по проектам» — запрос на решение, а не работа пользователя. Нужно выяснить, зачем понадобился фильтр. Например, руководитель ведет десять проектов и перед еженедельной встречей хочет быстро увидеть просроченные задачи конкретной команды. Именно этот результат и контекст важны для JTBD.

7. Слишком широко объединять результаты. Формулировка вроде «хочу эффективнее управлять работой» позволяет записать в одну job почти любую историю. Если одни пользователи ищут таск-трекер после роста команды, другие — после подключения подрядчиков, а третьи — из-за проблем со сроками, сначала эти сценарии лучше анализировать отдельно. Объединять их стоит только тогда, когда совпадает не формулировка проблемы, а контекст и требуемый результат.

Сколько интервью проводить

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

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

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

Онлайн-запись
для экспертов

Всё на автопилоте: календарь, оплата, созвон, напоминания

Попробовать бесплатно

Как начать первое JTBD-исследование

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

Затем определите, кого нужно пригласить. Для первого вопроса подойдут люди, которые недавно действительно совершили такой переход. Для второго — пользователи, которые недавно ушли и выбрали другое решение.

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

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

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

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

Итого

JTBD-исследование начинается с конкретного выбора или перехода: например, пользователь купил продукт, отказался от него или сменил прежний способ решения задачи. На интервью исследователь восстанавливает события до этого решения — от первого недовольства старым способом до поиска альтернатив и окончательного выбора.

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

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

Онлайн-запись
для экспертов

Всё на автопилоте: календарь, оплата, созвон, напоминания

Попробовать бесплатно

Часто задаваемые вопросы

Онлайн-запись
для экспертов

Всё на автопилоте: календарь, оплата, созвон, напоминания

Попробовать бесплатно