Jobs to Be Done в примерах, или Для чего люди «нанимают» продукты?

Допустим, нам нужно купить сковородку. Чего мы хотим? Стильного дизайна? Большой площади поверхности? Антипригарного покрытия?

Мы хотим быть сытыми. Поэтому мы не покупаем сковородку, а нанимаем ее на работу, цель которой — утолить голод.

Только что мы кратко обрисовали Jobs-to-Be-Done (JTBD) — теорию о поведении людей, которая позволяет понять, почему они принимают решение о покупке. Суть этой теории в том, что продукты не приобретают, а «нанимают» для выполнения определенных задач. Конечная цель — решить их и тем самым сделать жизнь клиента немного счастливее.

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

Именно так мы работаем над клиентскими проектами. В каждом из них в той или иной мере применяются принципы Jobs-to-Be-Done. Чтобы не быть голословными, разберем один из таких примеров, который полностью реализован на JTBD-принципах.

Новый сайт «Новосибирскэнергосбыта» — ориентация на реальные задачи пользователя

В 2020 году в Machineheads за созданием нового сайта обратилась компания «Новосибирскэнергосбыт» — поставщик электроэнергии в Новосибирске и области. На тот момент у нее уже был сайт, на котором клиенты могли получать услуги онлайн.

Однако у сайта уже проявлялись «возрастные болезни»: перегруженная структура, устаревшая стилистика, неочевидный UI. Отсутствовал адаптивный дизайн — серьезный недостаток при условии, что доля мобильного трафика приближалась к 50 %. Да и в целом сайт уже перерос себя, устарел морально, визуально и технически.

Посмотрите на скрин выше. Можете ли вы с ходу понять, куда нужно нажать, чтобы перейти к оплате? Здесь есть раздел «Где оплатить» — но он предлагает выбрать населенный пункт, район, улицу. Другими словами, намекает на то, что придется куда-то идти ногами. А как же оплата онлайн? На деле нужно искать глазами плашку «Личный кабинет для физических лиц», в котором поджидает еще и длительный процесс регистрации.

Сайт нужно было не просто обновить, а сделать более удобным и понятным. Сделать его рабочим инструментом для решения конкретных задач пользователей — таким, каким он должен быть в понимании концепции Jobs-to-Be-Done.

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

Мы подключили возможность оплачивать счета, указав только адрес квартиры и ФИО собственника, что удобнее по многим пунктам. Не нужен ни номер лицевого счета, ни данные договора с поставщиком энергии, ни какие-то другие реквизиты. Вероятность ошибиться в данных при таком подходе гораздо ниже. А оплачивать счета за электричество может не только собственник, но и, например, квартиросъемщик или взрослые дети за пожилых родителей. Да и в целом процесс оплаты стал проще. Два клика — и свет дома не погаснет.

Теперь на главной странице мы первым делом видим «Оплатить онлайн», а внутри раздела — несколько способов это сделать. Никакой регистрации не требуется.

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

Процесс или результат?

В зависимости от того, с какой целью нанимается продукт, концепция Jobs to Be Done может быть реализована по одному из следующих подходов:

Jobs-As-Activities

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

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

Jobs-As-Progress

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

В Jobs-As-Progress большое значение имеют эмоции, получаемый опыт. Этот подход помогает понять, почему пользователи меняют свои исторически сложившиеся паттерны потребления — перестают использовать продукт и переходят на новый. И определить, что предшествовало этому поведенческому изменению.

Например, почему люди редко пользовались предыдущей версией сайта «Новосибирскэнергосбыта»? Все просто: им было неудобно вводить длинный номер счета в личном кабинете. С появлением возможности платить по адресу квартиры и ФИО ее собственника поведение пользователей на сайте начало меняться.

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

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

В этой задаче был воплощен как раз подход Jobs-As-Progress. Цель пользователя, как вы помните, — электричество дома, подцель — оплатить его без затруднений. Мы увидели положительный эффект первого нововведения (авторизация по адресу) и поняли, что, облегчив процесс еще сильнее (авторизация по номеру телефона), увеличим потребность нанимать сайт на эту работу.

Выбирать конкретный подход и работать только по нему необязательно. JAA и JAP хорошо сочетаются и могут использоваться параллельно. Пример с сайтом «Новосибирскэнергосбыта» можно рассматривать как в том, так и в другом контексте. Одним пользователям важно удобство оплаты электроэнергии (JAA) — мы обеспечили соответствующую возможность. Другим важен сам факт оплаченных счетов — мы дали практичный и понятный инструмент для достижения этой цели. Поэтому такое разделение на подходы скорее условно. Разрабатывая продукт, вы (и мы) просто используете сам фреймворк Jobs-to-Be-Done, исходя из целей и задач будущих пользователей.

Этапы JTBD

В рамках этой концепции продукт проходит несколько этапов:

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

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

• Доставка/реализация — непосредственно работа над продуктом. От построения его архитектуры до представления готового решения.

Подробнее рассмотрим сессию идеации, поскольку именно здесь рождается продукт.

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

Здесь определяются:

• user — ваш пользователь;

• context — какую проблему продукт будет решать;

• job — какую работу он будет выполнять;

• solutions — способы решения проблемы;

• outcome — результат.

Примеры вопросов, которые ставятся на идеации:

• Какими технологиями мы обладаем и, соответственно, какими конкурентными преимуществами будет обладать наш продукт?

• Что будет тяжело скопировать?

И главное, с чем стоит определиться:

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

В случае с «Новосибирскэнергосбытом» ответ на Зачем-вопрос звучит именно так, как показано на картинке: «оплачивать электроэнергию». Главным конкурентным преимуществом нового продукта должно стать удобство оплаты — необходимые технологии и ресурсы для этого у нас есть. Как человек будет пользоваться новым сайтом? И с ПК, и с мобильных устройств. Значит, дизайн всех сервисов нужно сделать не только удобным, но и адаптивным.

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

Чем Job Story лучше User Story?

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

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

В такой цепочке не хватает одного очень важного компонента — вопроса «Для чего?». То есть User Story не затрагивает цели достижения конечного результата. «Чтобы иметь возможность приготовить ужин» — слишком абстрактное обоснование, за которым может скрываться множество важных аспектов. Но, поскольку до их уровня не углубляются, то и учтены они при разработке решения не будут.

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

То есть метод User Story помогает детально изучить ваших клиентов, однако не выясняет, почему они остаются с вами и почему придут новые. А Job Story фокусируется как раз на этих вопросах, не вдаваясь в социально-демографические тонкости. Он описывает, что пользователь хочет сделать, почему он это хочет сделать и в каких условиях. Это помогает уйти от стереотипов и обобщений, связанных с личностными характеристиками (как в User Stories), и сосредоточиться на реальных ситуациях и потребностях.

Пример:

• User Story: «Как мама, я хочу быстро приготовить ужин, чтобы накормить семью».

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

Возьмем еще один популярный метод, основанный на User Story, — метод персон. Он предполагает, что люди очень разные, но на самом деле похожего в них гораздо больше. Как в нашем примере: неважно, кто платит за электроэнергию, — офисный клерк, освоившая интернет пенсионерка или студент, снимающий квартиру. Их цель — электричество дома. Персоны объясняют, кто твои пользователи и что они делают. Но почему они это делают — гораздо важнее. Понять это помогает фреймворк Job Story, который, кстати, был составлен компанией Intercom как раз при попытке найти инструмент более эффективный, чем метод персон.

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

Еще одно важное правило: развитие продукта продолжается ровно до тех пор, пока это несет пользователю дополнительную ценность. Нужно уметь вовремя останавливаться.

Примеры использования Jobs to Be Done из мировой практики

Этот подход используют очень многие компании из самых разных сфер. В том числе и гиганты экономики. Вот несколько примеров.

McDonald's прокачал продажи молочных коктейлей

• Проблема: McDonald's хотел увеличить продажи молочных коктейлей, но традиционные методы (опросы, фокус-группы) не давали результатов.

• Решение: Команда провела наблюдения за покупателями и выяснила, что многие люди покупают молочные коктейли утром, чтобы перекусить по дороге на работу. Это была «работа» (Job), которая должна быть выполнена (Done), — быстро и удобно утолить голод, не пачкая руки.

• Результат: McDonald's улучшил коктейли, сделав их более густыми, чтобы они дольше насыщали, и добавил удобные упаковки для употребления в машине. Это привело к росту продаж.

Airbnb улучшил платформу для аренды жилья

• Проблема: Airbnb хотел понять, почему одни объявления привлекают больше гостей, чем другие.

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

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

Procter & Gamble разработала новые продукты

• Проблема: P&G хотела создать продукты, которые бы решали реальные проблемы клиентов.

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

• Результат: P&G разработала линейку чистящих средств и инвентаря Swiffer, которые упрощают уборку и экономят время.

Возможности и ограничения Jobs-to-Вe-Done

Как мы постарались показать, концепция JTBD — это мощный инструмент для понимания потребностей пользователей и создания продуктов, которые решают их реальные задачи. Однако, как и у любого метода, у Jobs-to-Вe-Done есть плюсы и минусы, поэтому она подходит не для всех ситуаций. Давайте вкратце рассмотрим, когда этот фреймворк хорош и эффективен, а когда могут потребоваться другие подходы.

Когда JTBD подходит для разработки продукта

• Нужно понять глубинные мотивы пользователей.

Just-to-Be-Done будет идеальным способом построения работы, если важно понять, почему пользователи выбирают тот или иной продукт, для решения каких задач он им нужен и что на самом деле для них важно. Особенно полезно это будет на этапах исследования и проектирования.

• Продукт создается для решения конкретных задач.

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

• Существующий продукт требует улучшений.

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

• Важно учитывать контекст использования.

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

• Нужно отстроиться от конкурентов.

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

Когда JTBD не лучший вариант

• Продукт ориентирован на эмоции, а не на задачи.

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

• Продукт нацелен на широкую аудиторию с разными потребностями.

Если разрабатываемый продукт рассчитан на очень разнородную аудиторию (например, социальная сеть), то работать по методике JTBD будет сложно. У разных пользователей в этом случае будут кардинально различающиеся Jobs, которые должны быть Done. В таких ситуациях приходится комбинировать несколько подходов.

• Влияют технологические ограничения или возможности

Когда процесс разработки продукта в высокой степени зависит от технологических возможностей, что характерно для Hardware-задач и сложных SaaS-решений, JTBD может быть второстепенным инструментом. Приходится учитывать не только «Какие задачи хотят решить пользователи?», но и «Есть ли ресурсы, чтобы создать инструмент под такие задачи?»

• Проект нужно запустить максимально быстро

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

В целом же, Jobs-to-Be-Done — это полезный, функциональный и гибкий фреймворк, который помогает не тратить ценные ресурсы и концентрироваться на том, чего действительно хотят люди. Помните о проблемах пользователя, концентрируйтесь на нужных ему работах (Jobs) и делайте так, чтобы они переходили в статус Done наиболее комфортным способом. Мы в том или ином виде используем этот подход это в каждом из наших успешных проектов. А других у Machineheads нет.