Знания о портретах пользователей, их возрасте и увлечениях не всегда гарантируют успех продукта. Для создания качественного сервиса, гораздо полезнее понимать, какую «работу» он выполняет. Сделать это можно с помощью фреймворка JTBD (Jobs to Be Done). Давайте разберемся, что это такое и как применять его в разработке IT-продуктов.
Кто нанимает ваш продукт на работу, или зачем нужна эта методология
Представим, что наша компания занимается облачными хранилищами. Тариф с дополнительными гигабайтами только что купили два пользователя:
- Миша, 35 лет. У него есть высшее образование и работа со средним доходом. Два раза в неделю он ходит в зал, а в выходные обычно гуляет с женой и дочкой. Большое облако ему нужно, чтобы хранить семейные фото и видео там, куда можно дать доступ тем родственникам, которые постоянно просят отправить фотографии.
- Саша, 23 года. После колледжа он уехал в долгое путешествие, работает на фрилансе и ведет блог о своих приключениях. Большое облако ему нужно, чтобы сохранить отснятые видео и фото, на случай, если его технику украдут в отеле.
Два этих человека никак не пересекаются по соцдему и сделали свои покупки не из-за возраста или семейного положения. У них была задача «обеспечить доступ с разных устройств к своим фото и видео». Наш сервис может ее выполнить. Это и есть основа методологии.
JTBD — способ изучения целевой аудитории, чтобы создать продукт, который будет полезен людям и за счет этого востребован.
Объясню идею фреймворка на примерах:
- Человек не покупает пылесос, он как бы нанимает его на свою «работу» — уборку.
- Горячий кофе на вынос могут использовать, чтобы согреться в холодный день, почувствовать привычную атмосферу или скоротать 5 минут до встречи с другом.
Так или иначе «работают» все продукты и сервисы, с которыми соприкасается человек. Например, банкинг на смартфоне. Один человек будет открывать его каждый день для всех расчетов; другой — только для того, чтобы раз в месяц посмотреть начисления по своим вкладам. Таким образом, один сервис можно применять по-разному, в зависимости от задач разных пользователей.
Фреймворк смещает фокус с того, что вы делаете, на то, что нужно сделать клиенту.
Как применять JTBD в разработке IT-продуктов
Основная идея фреймфорка: любой продукт, сервис или даже отдельная функция «нанимаются» человеком на «работу». Поэтому первоочередная задача разработчиков — понять, какие «работы» пользователей будет выполнять их продукт, и создавать его, отталкиваясь от этого. Разберем применение фреймворка Jobs To Be Done на примере корпоративного мессенджера.
Шаг 1. Соберите информацию и проведите исследование
Сбор информации
Хорошее исследование начинается с постановки целей и понимания того, что нужно получить на выходе.
Прежде чем создавать продукт, нужно выяснить, с какими «работами» может прийти покупатель. Первичной информацией станут знания, которые уже есть — портреты потребителей, карта пути клиента, обзор трендов, отзывы о похожих сервисах.
На основе этих данных команда проводит брейншторм, составляет первичные гипотезы и черновой список «работ». Далее они подтвердятся или будут опровергнуты.
Проведение глубинных интервью
Чтобы получить корректный список «работ», нужно понять глубинные мотивы пользователей. В этом поможет JTBD-интервью. Его цель — узнать, почему сформировалась «работа» и как человек решил ее «выполнить». Стартовая точка — начальные гипотезы, полученные в результате брейншторма.
Интервьюировать нужно тех, кто использует похожий продукт, и тех, кто выбирает альтернативное решение задачи. Например, в случае с корпоративным мессенджером, полезно будет включить в исследование не только пользователей других мессенджеров, но и тех, кто решает рабочие вопросы в CRM-системе.
Также важно опросить всех стейкхолдеров:
- руководителей, которые принимают решение о покупке продукта;
- специалистов, которые непосредственно работают с продуктом.
Нужно учесть, что клиенты, как правило, не покупают абсолютно новый продукт, а переходят на него с чего-то другого. Например, в компании все общались по электронной почте, но перешли на корпоративный мессенджер, потому что это быстрее.
Итогом глубинного интервью с человеком из такой компании должна стать информация о том, как появилось решение сменить способ общения, сложностях на пути к новому продукту и решениях, которые помогли получить желаемое.
Шаг 2. Найдите и изучите конкурентов
Фреймворк JTBD разделяет конкуренцию на три вида и учитывает даже неочевидные причины, по которым продукт может лишиться аудитории. Рассмотрим конкурентов мессенджера:
- Прямые — остальные мессенджеры. То есть все специализированные приложения для обмена сообщениями. Делают одну и ту же работу, одним и тем же способом.
- Вторичные — остальные приложения, где можно писать сообщения и другие способы обмена информацией. Например, соцсети и электронная почта. Делают ту же работу, но другими способами.
- Непрямые — продукты, которые выполняют другую работу, но в случае выбора одного сервиса, необходимость в другом отпадает. Например, если вы каждый день обсуждаете вопросы на совещаниях, необходимость писать сообщения отпадает.
Выявление и анализ конкурентов поможет понять, насколько заполнен рынок, который вы собираетесь покорить. А взглянуть дальше основных конкурентов полезно, чтобы представлять полную картину выбора, с которым сталкивается пользователь.
Шаг 3. Проведите анализ данных и расставьте приоритеты
После того, как данные по интервью и конкурентам собраны, нужно сгруппировать повторяющиеся и уникальные ответы, чтобы определить «силы прогресса», влияющие на выбор нового продукта.
В случае с корпоративным мессенджером «силы прогресса» могут быть такими:
- Проблема: «Коллеги пропускают рабочие сообщения в обычном мессенджере, потому что отвлекаются на личное общение и развлекательные каналы».
- Преимущества нового: «Если мы перейдем на корпоративный мессенджер, сотрудники смогут лучше сосредоточиться на работе и им будет сложнее пропустить сообщение в общем потоке информации».
- Тревога из-за смены: «Что, если перейти будет сложно и не будет всех нужных функций? Например, мы привыкли отправлять файлы с презентациями прямо в чаты».
- Привычка: «У нас уже настроены рабочие чаты. Заново добавить в мессенджер всех сотрудников и настроить рабочее пространство будет нелегко».
Такая детальная проработка поможет определить истинную мотивацию клиента. Видя задачу со всех сторон, можно начинать прописывать «работы».
Далее по каждой полученной «работе» распределяются данные о конкурентах, которые тоже могут ее выполнить и прописываются критерии «найма» продукта. Они превращаются в требования, которые стоит учесть при разработке.
Среди всех привлекательных «работ» нужно определить одну или несколько тех, на которых предстоит сфокусироваться. Здесь есть риск выбрать то, что звучит прекрасно в глубинных интервью, инвестировать ресурсы в разработку, а потом понять, что рынок слишком маленький и идея не масштабируется.
Поэтому важно утвердиться, что запрос на «работу» есть у многих людей. В этом поможет количественное исследование. Нужно оцифровать ключевые составляющие «работы» и оценить их потенциал:
- как часто у людей происходит такая проблема;
- насколько распространена подобная мотивация;
- что чаще всего побуждает людей искать новое решение проблемы;
- каковы самые важные критерии «найма» продукта;
- какие барьеры смогут остановить пользователей от выбора нового решения.
После исследований и расстановки приоритетов должна остаться одна Core Job — наиболее сильная «работа», которую будет делать продукт. Можно приступать к планированию разработки.
Шаг 4. Пропишите иерархию работ
Если хотите понять Core Job, ее нужно разбить на подзадачи и составить схему. Поможет вопрос «Как это сделать?». В результате должен получиться список «подработ», выполнение которых приведет в точку «Задача выполнена».
Таких «подработ» можно насчитать десятки, и для каждой из них будет свой алгоритм. Для нашего примера можно выделить еще 2 подзадачи:
- «Подработа» 2 уровня: проверить презентацию. Перейти в приложение по упоминанию — Сразу оказаться в нужном чате, на нужном сообщении — Нажать на прикрепленный файл — Нажать на кнопку загрузки — Открыть файл на своем устройстве.
- «Подработа» 2 уровня: дать обратную связь по презентации. Войти в приложение — Открыть чат — Найти сообщение с презентацией — Открыть комментарии — Упомянуть коллегу — Написать сообщение.
Шаг 5. Определите функции, из которых строится продукт
Далее, на основе «подработ» нужно создать функции, которые отвечают за их выполнение. Например, сотруднику нужно проверить презентацию, которую ему отправил коллега в чате проекта. Функции, которые должны быть в продукте:
- Поиск внутри чата, который будет учитывать названия документов.
- Загрузка документа на свое устройство или возможность открыть его внутри сервиса.
- Комментарии к сообщениям, чтобы обсудить презентацию в отдельном треде, а не засорять общий чат.
- Упоминание пользователей, чтобы им пришло персонализированное уведомление о новых данных по задаче.
Каждая из этих функций — набор кода с деталями интерфейса. Из них и складываются сценарии взаимодействия пользователя с приложением.
Если вы только начинаете разработку, иерархия работ поможет увидеть, на каких функциях стоит сконцентрироваться сначала. Если приложением уже пользуются — понять, какие функции стоит совершенствовать или упрощать.
Шаг 6. Позаботьтесь о времени пользователя
Вместе с разработкой функций, которые сделают жизнь пользователя лучше, нужно позаботится и о его transaction cost. Иначе ничего не получится.
Transaction cost пользователя — это сумма времени, денег, энергии и внимания, которую человеку необходимо потратить на действие. Каким бы классным ни был продукт, если он слишком сложный и тормозит, — пользователи надолго не задержатся.
Три кита удобного продукта:
- Оптимизация UX/UI. Интерфейс должен быть понятен для пользователя, а все нужные функции должны быть доступны в 1-2 клика.
- Стабильность работы. Если мессенджер постоянно вылетает, когда человек тратит время, чтобы написать сообщение, он просто не будет им пользоваться.
- Скорость работы. Люди привыкли к мгновенному отклику приложений и, даже если сервис работает корректно, но тормозит, они найдут более быструю замену.
Особенно важно учитывать transaction cost в инновационных продуктах, которые формируют новые рынки. Люди уже потратили усилия, чтобы понять, чем им полезен сервис. Если им придется еще и долго разбираться, как его использовать, — они не станут этого делать и продолжат «нанимать» привычные решения.
Шаг 7. Анализируйте иерархию работ, чтобы понять, куда двигаться дальше
Клиенты уже не смотрят на список функций — им интересно, насколько легче станет их жизнь с приложением. Поэтому смотрите на схему, чтобы понять, что делать дальше. Старайтесь выделять смежные «работы» и наращивать функции под них. А также анализируйте, какие еще задачи могут появиться у клиентов в ближайшем будущем. Тут будет полезен SWOT-анализ.
Читайте также:
Очень трудоемкий и затратный метод, с большими ограничениями, часто не приводящий к нужному результу. И не только на мой взгляд) Хотя ценность в нем есть несомненно.
Согласен с коллегой. JTBD стал каким-то чрезвычайно популярным инструментом в арсенале коллег. Но чем больше смотрю на это все, тем больше понимаю, что JTBD либо понимают неправильно, либо что-то неправильно перевели при адаптации ))) В итоге это приводит к крайне поверхностному восприятию концепции. И ошибочным гипотезам в последствии.
Почему-то JTBD воспринимают как некий методологический инструмент, который можно легко внедрить и использовать вместо привычных инструментов работы с потребителями. Не углубляясь в суть.
Вообще привычка фокусироваться только на функциональных аспектах задач клиентов, игнорируя эмоциональные и социальные компоненты, ни к чему хорошему не приводит. Без сегментарно-функционального анализа ЦА будет вообще плохое представление про UVP (Unique Value Proposition). И если Саша и Миша не пересекаются по соцдему, то по болям и триггерам легко, копайте глубже. Потому что набившее искомину "покупка для дрели для дырки в стене" ошибочна. Не нужна мне дырка, мне нужно картину на стенку повесить.
Ограниченное понимание контекста потребительских триггеров вообще бич. Адепты JTBD считают, что задачи клиентов статичны и не зависят от обстоятельств. В реальности же они очень сильно меняются в зависимости от ситуации, времени, места и сотен других факторов. Иначе позвонить (нанять сделать звонок) хватило бы по идее и кнопочного телефона, но с Айфона даже звонить не нужно, он сам по себе атрибут. Но в случае пожара, что с него звонить, что с Нокиа 3310 - без разницы...
И с интерпретацией полученных данных тоже вопросы. Тут главное не перепутать средства с целями )) А с учетом, что современный потребитель крайне потребительски инфантилен, а порой не может вообще вычислить и формализовать свои хотелки, задача усложняется ))
Но это уже я придираюсь. Статья прекрасна! И мессенджер великолепен, кстати
Мне показалось, что статья – это упрощенный пересказ обычной работы маркетолога по исследованию рынка и разработке нового продукта, в котором выражение «удовлетворить потребность» зачем-то заменили на «нанять на работу».
И особенно порадовало:
В пункте про понятность автор пишет «Оптимизацию UX/UI» - без расшифровки. Не знаю, как другим, но мне эти буквы ни о чем не говорят. А, значит, товар «статья» неудобный, и я его «на работу» не нанимаю.
Можно и дальше пойти: закрыть пятно на стене, вспомнить любимую, похвалиться Ренуаром))))
Да, вот это главное, не углубляясь в суть.
Хочу заметить, контекст в самой модели заложен, Алексей, так же как и социльно- эмоциональные компоненты.. Но дело как раз в том, о чем вы написали выше, про суть.
Сам метод и формулу можно считать идеальными для исследователей!
Но ее поверхностное понимание служит для возникновения например таких "ляпов" как указаканных в шаге 7 Клиентам интересно на сколько их жизнь станет легче - с этим следовало разобраться еще на шаге 1!
На аналогичных исследованиях основано "бережливое производство" - в противном случае следуют потери, как производство не нужных, а следовательно не эффективных работ.
А то что продукт Евгения оказался восстребованным, то этому можно порадоваться! Вероятно, что даже не самое подходящее использование метода может привести к успеху!:)
Понятно, как обосновать внедрение в пределах одной конкретной компании. Но общение в мессенджерах идет как раз потому что НЕ ТОЛЬКО они там на связи. Также все старые и потенциальные клиенты, поставщики, подрядчики, СМИ, вообще кто угодно. Добрый старый феномен Facebook, который ненавидит примерно каждый — однако млрд пользователей позволяет дотянуться до каждого, при взаимном интересе. Аналогично с Телеграм после того, как он сумел набрать критическую массу
Вот это же трудный момент, именно он. Только он. Все остальное "бантики". К слову даже прямые конкурентные преимущества по функционалу вторичны. Решает количество активных пользователей, и тренд по расширению охвата
Что говорит JTBD на этот счет?
JTBD - это метод исследований найти точку входа в проект, который может включать также постоянную обратную связь с пользователями, по аналогии с принципами Agile!
В втором шаге статьи предлагается исследовать конкурентов - а по стандартам например Тойоты или Сони это делается сразу на первом шаге инженерами компании.
Инженерам сразу же на начальном этапе нужно разобраться с тем что они будут позиционировать на рынке.
Количество активных пользователей тоже является зависимостью от разрабатываемых технологий, в том числе функционала!