Как создать успешный продукт. Фреймворк Jobs To Be Done 💎 — OnAgile Consulting

Как создать успешный продукт. Фреймворк Jobs To Be Done

Концепция Jobs To Be Done помогает определиться с видением продукта и отдельными его функциями, которые будут привлекательны для пользователей.

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

Суть Jobs To Be Done

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

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

Контекст вместо портрета пользователей

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

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

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

Конкуренты 

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

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

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

Схема из книги Jobs-To-Be-Done by Intercom

Вовремя остановиться

Во время работы над продуктом к начальной идее добавляются все новые и новые функции. Руководствуясь стремлением решить как можно больше задач и получить признание пользователей, команда, однако, рискует потратить силы на никому не нужный функционал. Например, в IT, согласно статистике, 45% функций продуктов не используются вообще никогда. Пугающие цифры, не правда ли?

Концепция Jobs To Be Done предлагает оценить контекст применения продукта и начать на том этапе, где ваш продукт сможет принести ощутимую пользу. Так, если мы разрабатываем приложение для планирования, то можно добавить будильник, чтобы пользователь не проспал встречу, и напоминание с вечера, что стоит лечь спать пораньше, но нужно ли это — решать команде в каждом конкретном случае. 

Дополнительная функция, вероятно, будет лишней, если:

  • на рынке есть явные лидеры (Apple, Amazon, Netflix), которые закрывают эту задачу пользователей, и вы не собираетесь с ними конкурировать;
  • задача решается множеством разных способов многими типами пользователей;
  • появляются другие конечные пользователи (например, сотрудники вместо внешних клиентов);
  • она не добавляет продукту ценности.

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

По-настоящему успешным становится продукт, который нравится пользователям и решает задачи бизнеса. Фреймворк Jobs To Be Done — один из способов сконцентрировать усилия команды на вещах, которые принесут максимум пользы. В центре внимания — контекст, в котором у пользователей возникает та или иная задача («работа»), и поиск способа перевести эту работу в статус «Done». 

Разобраться в деталях и попробовать подход на практике можно на нашем курсе Agile Product Management. 

Хотите узнать, каких результатов можно достичь с помощью Agile в вашем проекте или компании?
Напишите нам
                                                      

Еще публикации по Agile в Управление продуктами

Публикация
Управление продуктами
Модель приоритизации бэклога WSJF
Как упорядочить бэклог и определить, какие элементы следует выполнить в первую очередь? Обратимся к математике и рассмотрим простой инструмент Weighted Shortest Job First.
Кейс
Телекоммуникации
Разработка и запуск корпоративного портала «с нуля» за 3 недели
Наш клиент, одна из крупнейших телекоммуникационных компаний России, поставила перед нами задачу быстрого запуска «с нуля» нового программного продукта — внутреннего портала для десятков тысяч сотрудников компании, распределенных по всей стране.
Кейс
Управление продуктами
Как переосмысление и формулировка целей (с помощью OKR) привело финтех-команду к успеху
Представьте, что вы создали отличное мобильное приложение для ваших клиентов. Оно функциональное, красивое, но... пользователи почему-то не спешат им активно пользоваться. Знакомая ситуация? Именно с такой проблемой столкнулась одна финтех-команда, и сегодня мы расскажем вам, как они смогли все изменить.
Публикация
Управление продуктами
Практика Scrum: как создать бэклог продукта
Пошаговый алгоритм создания бэклога продукта для Scrum-команд.

С 2004 года мы помогаем адаптировать к изменениям культуру и процессы компании

Связаться с нами

Дмитрий Лобасев

Managing Partner

+7 495 221 87 39

dmitry@onagile.ru

Наш Telegram канал об Agile и гибких организациях, присоединяйтесь!