Как запускать продукты по методологии JTBD: алгоритм из 7 шагов

Знания о портретах пользователей, их возрасте и увлечениях не всегда гарантируют успех продукта. Для создания качественного сервиса, гораздо полезнее понимать, какую «‎работу» он выполняет. Сделать это можно с помощью фреймворка JTBD (Jobs to Be Done). Давайте разберемся, что это такое и как применять его в разработке IT-продуктов.

Кто нанимает ваш продукт на работу, или зачем нужна эта методология

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

  1. Миша, 35 лет. У него есть высшее образование и работа со средним доходом. Два раза в неделю он ходит в зал, а в выходные обычно гуляет с женой и дочкой. Большое облако ему нужно, чтобы хранить семейные фото и видео там, куда можно дать доступ тем родственникам, которые постоянно просят отправить фотографии.
  2. Саша, 23 года. После колледжа он уехал в долгое путешествие, работает на фрилансе и ведет блог о своих приключениях. Большое облако ему нужно, чтобы сохранить отснятые видео и фото, на случай, если его технику украдут в отеле.

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

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

Объясню идею фреймворка на примерах:

  • Человек не покупает пылесос, он как бы нанимает его на свою «‎работу» — уборку.
  • Горячий кофе на вынос могут использовать, чтобы согреться в холодный день, почувствовать привычную атмосферу или скоротать 5 минут до встречи с другом.

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

Фреймворк смещает фокус с того, что вы делаете, на то, что нужно сделать клиенту.

Как применять JTBD в разработке IT-продуктов

Основная идея фреймфорка: любой продукт, сервис или даже отдельная функция «‎нанимаются» человеком на «‎работу». Поэтому первоочередная задача разработчиков — понять, какие «‎работы» пользователей будет выполнять их продукт, и создавать его, отталкиваясь от этого. Разберем применение фреймворка Jobs To Be Done на примере корпоративного мессенджера.

Шаг 1. Соберите информацию и проведите исследование

Сбор информации

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

Прежде чем создавать продукт, нужно выяснить, с какими «‎работами» может прийти покупатель. Первичной информацией станут знания, которые уже есть — портреты потребителей, карта пути клиента, обзор трендов, отзывы о похожих сервисах.

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

Проведение глубинных интервью

Чтобы получить корректный список «‎работ», нужно понять глубинные мотивы пользователей. В этом поможет JTBD-интервью. Его цель — узнать, почему сформировалась «работа» и как человек решил ее «‎выполнить». Стартовая точка — начальные гипотезы, полученные в результате брейншторма.

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

Также важно опросить всех стейкхолдеров:

  • руководителей, которые принимают решение о покупке продукта;
  • специалистов, которые непосредственно работают с продуктом.

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

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

Шаг 2. Найдите и изучите конкурентов

Фреймворк JTBD разделяет конкуренцию на три вида и учитывает даже неочевидные причины, по которым продукт может лишиться аудитории. Рассмотрим конкурентов мессенджера:

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

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

Шаг 3. Проведите анализ данных и расставьте приоритеты

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

Что влияет на выбор нового продукта, JTBD

В случае с корпоративным мессенджером «‎силы прогресса» могут быть такими:

  • Проблема: «Коллеги пропускают рабочие сообщения в обычном мессенджере, потому что отвлекаются на личное общение и развлекательные каналы».
  • Преимущества нового: «Если мы перейдем на корпоративный мессенджер, сотрудники смогут лучше сосредоточиться на работе и им будет сложнее пропустить сообщение в общем потоке информации».
  • Тревога из-за смены: «Что, если перейти будет сложно и не будет всех нужных функций? Например, мы привыкли отправлять файлы с презентациями прямо в чаты».
  • Привычка: «‎У нас уже настроены рабочие чаты. Заново добавить в мессенджер всех сотрудников и настроить рабочее пространство будет нелегко». 

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

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

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

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

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

После исследований и расстановки приоритетов должна остаться одна Core Job — наиболее сильная «‎работа», которую будет делать продукт. Можно приступать к планированию разработки. 

Шаг 4. Пропишите иерархию работ

Если хотите понять Core Job, ее нужно разбить на подзадачи и составить схему. Поможет вопрос «‎Как это сделать?». В результате должен получиться список «‎подработ», выполнение которых приведет в точку «‎Задача выполнена». 

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

  • «‎Подработа» 2 уровня: проверить презентацию. Перейти в приложение по упоминанию — Сразу оказаться в нужном чате, на нужном сообщении — Нажать на прикрепленный файл — Нажать на кнопку загрузки — Открыть файл на своем устройстве.
  • «‎Подработа» 2 уровня: дать обратную связь по презентации. Войти в приложение — Открыть чат — Найти сообщение с презентацией — Открыть комментарии — Упомянуть коллегу — Написать сообщение. 

Шаг 5. Определите функции, из которых строится продукт 

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

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

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

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

Шаг 6. Позаботьтесь о времени пользователя

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

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

Три кита удобного продукта:

  1. Оптимизация UX/UI. Интерфейс должен быть понятен для пользователя, а все нужные функции должны быть доступны в 1-2 клика.
  2. Стабильность работы. Если мессенджер постоянно вылетает, когда человек тратит время, чтобы написать сообщение, он просто не будет им пользоваться.
  3. Скорость работы. Люди привыкли к мгновенному отклику приложений и, даже если сервис работает корректно, но тормозит, они найдут более быструю замену.

Особенно важно учитывать transaction cost в инновационных продуктах, которые формируют новые рынки. Люди уже потратили усилия, чтобы понять, чем им полезен сервис. Если им придется еще и долго разбираться, как его использовать, — они не станут этого делать и продолжат «‎нанимать» привычные решения.

Три кита удобного продукта

Шаг 7. Анализируйте иерархию работ, чтобы понять, куда двигаться дальше 

Клиенты уже не смотрят на список функций — им интересно, насколько легче станет их жизнь с приложением. Поэтому смотрите на схему, чтобы понять, что делать дальше. Старайтесь выделять смежные «‎работы» и наращивать функции под них. А также анализируйте, какие еще задачи могут появиться у клиентов в ближайшем будущем. Тут будет полезен SWOT-анализ.

SWOT-анализ

Читайте также:

Расскажите коллегам:
Комментарии
Консультант, Нижний Новгород

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

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

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

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

Вообще привычка фокусироваться только на функциональных аспектах задач клиентов, игнорируя эмоциональные и социальные компоненты, ни к чему хорошему не приводит. Без сегментарно-функционального анализа ЦА будет вообще плохое представление про UVP (Unique Value Proposition). И если Саша и Миша не пересекаются по соцдему, то по болям и триггерам легко, копайте глубже. Потому что набившее искомину "покупка для дрели для дырки в стене" ошибочна. Не нужна мне дырка, мне нужно картину на стенку повесить. 

Ограниченное понимание контекста потребительских триггеров вообще бич. Адепты JTBD считают, что задачи клиентов статичны и не зависят от обстоятельств. В реальности же они очень сильно меняются в зависимости от ситуации, времени, места и сотен других факторов. Иначе позвонить (нанять сделать звонок) хватило бы по идее и кнопочного телефона, но с Айфона даже звонить не нужно, он сам по себе атрибут. Но в случае пожара, что с него звонить, что с Нокиа 3310 - без разницы...

Директор по развитию, Санкт-Петербург

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

Но это уже я придираюсь. Статья прекрасна! И мессенджер великолепен, кстати

Менеджер, Саратов

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

И особенно порадовало:

Три кита удобного продукта:

Оптимизация UX/UI. Интерфейс должен быть понятен для пользователя, а все нужные функции должны быть доступны в 1-2 клика.

В пункте про понятность автор пишет «Оптимизацию UX/UI» - без расшифровки. Не знаю, как другим, но мне эти буквы ни о чем не говорят. А, значит, товар «статья» неудобный, и я его «на работу» не нанимаю.

Менеджер, Саратов
Алексей Аникин пишет:
"покупка для дрели для дырки в стене" ошибочна. Не нужна мне дырка, мне нужно картину на стенку повесить

Можно и дальше пойти: закрыть пятно на стене, вспомнить любимую, похвалиться Ренуаром))))

Консультант, Нижний Новгород
Алексей Аникин пишет:
Ирина Плотникова пишет:
Очень трудоемкий  и затратный метод, с большими ограничениями, часто не приводящий к нужному результу.

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

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

Да, вот это главное, не углубляясь в суть.

Вообще привычка фокусироваться только на функциональных аспектах задач клиентов, игнорируя эмоциональные и социальные компоненты, ни к чему хорошему не приводит. Без сегментарно-функционального анализа ЦА будет вообще плохое представление про UVP (Unique Value Proposition). И если Саша и Миша не пересекаются по соцдему, то по болям и триггерам легко, копайте глубже. Потому что набившее искомину "покупка для дрели для дырки в стене" ошибочна. Не нужна мне дырка, мне нужно картину на стенку повесить. 

Ограниченное понимание контекста потребительских триггеров вообще бич. Адепты JTBD считают, что задачи клиентов статичны и не зависят от обстоятельств. В реальности же они очень сильно меняются в зависимости от ситуации, времени, места и сотен других факторов. Иначе позвонить (нанять сделать звонок) хватило бы по идее и кнопочного телефона, но с Айфона даже звонить не нужно, он сам по себе атрибут. Но в случае пожара, что с него звонить, что с Нокиа 3310 - без разницы...

Хочу заметить, контекст в самой модели заложен, Алексей, так же как и социльно- эмоциональные компоненты.. Но дело как раз в том, о чем вы написали выше, про суть.

Knowledge manager, Пермь
Алексей Аникин пишет:
Ирина Плотникова пишет:Очень трудоемкий  и затратный метод, с большими ограничениями, часто не приводящий к нужному результу.
Согласен с коллегой. JTBD стал каким-то чрезвычайно популярным инструментом в арсенале коллег. Но чем больше смотрю на это все, тем больше понимаю, что JTBD либо понимают неправильно, либо что-то неправильно перевели при адаптации ))) В итоге это приводит к крайне поверхностному восприятию концепции. И ошибочным гипотезам в последствии. Почему-то JTBD  воспринимают как некий методологический инструмент, который можно легко внедрить и использовать вместо привычных инструментов работы с потребителями. Не углубляясь в суть. 

Сам метод и формулу можно считать идеальными для исследователей!

Но ее поверхностное понимание служит для возникновения например таких "ляпов" как указаканных в шаге 7 Клиентам интересно на сколько их жизнь станет легче - с этим следовало разобраться еще на шаге 1!

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

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

Руководитель, Москва

Понятно, как обосновать внедрение в пределах одной конкретной компании. Но общение в мессенджерах идет как раз потому что НЕ ТОЛЬКО они там на связи. Также все старые и потенциальные клиенты, поставщики, подрядчики, СМИ, вообще кто угодно. Добрый старый феномен Facebook, который ненавидит примерно каждый — однако млрд пользователей позволяет дотянуться до каждого, при взаимном интересе. Аналогично с Телеграм после того, как он сумел набрать критическую массу

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

Что говорит JTBD на этот счет?

Knowledge manager, Пермь
Станислав Антипов пишет:
Что говорит JTBD на этот счет?

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

В втором шаге статьи предлагается исследовать конкурентов - а по стандартам например Тойоты или Сони это делается сразу на первом шаге инженерами компании.

Инженерам сразу же на начальном этапе нужно разобраться с тем что они будут позиционировать на рынке.

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

 

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
62% работодателей не берут сотрудников без высшего образования

Только 15% компаний признались, что закрывают на это глаза и часто рассматривают кандидатов без дипломов.