Повышение эффективности «Про бизнес» 19 января 2021

Если клиент «не в фокусе»: почему в сложных проектах удобно применять фреймворки

Зачастую за понятием «фреймворк» кроется методология проектной работы — инструмент, помогающий командам оценивать актуальность продукта для рынка и реализовывать сложные бизнес-проекты. А еще — генерировать больше полезных идей, которые действительно будут востребованы клиентами. Своим опытом внедрения фреймворка Jobs to be done в крупной B2B-компании (и разработки с его помощью проекта для HR) с нами поделился Юрий Бранковский, продакт-менеджер с успешным опытом работы в компаниях Planner 5D, VCV, Mego.travel.

**Юрий Бранковский**
Продакт-менеджер, ментор и член жюри хакатонов Emerge и Epam engineering jam

— Фреймворк — это программа или методология, облегчающая разработку и объединение различных частей одного большого или сложного проекта. Ниже я расскажу, как мы внедряли фреймворк Jobs to be done (далее по тексту — JTBD) для B2B-компании, которая занималась разработкой специальных видеоинтервью. Этот продукт был необходим для эффективной работы HR-отделов, поскольку отчасти заменял классические собеседования в компаниях, что позволяло:

Сократить время специалистов на скрининг-интервью кандидатов
Увеличить количество кандидатов, которых может охватить один рекрутер
Получить больше информации о соискателе уже на начальных этапах подбора.

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

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

Выяснилось, что HR используют видеоинтервью по-разному, на разных этапах и для разных вакансий. Так мы поняли, что метод создания персон не подходит для решения этой конкретной задачи.

Поэтому мы решили применить фреймворк Jobs to be done, который использует, в частности, компания Intercom, также работающая в B2B-сегменте.

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

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

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

Задачи, которые должны быть сделаны на этапе разработки продукта

1. Поймите, почему вообще ваш продукт «нанимают»?

Для этого есть шаблон ответа:

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

2. Найдите истинных конкурентов

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

Ищите тех, кто решает те же самые задачи, что и ваш продукт.

Ваши конкуренты «прячутся» в трех категориях:

Прямые конкуренты. Это те, кто сами (или при помощи своего продукта) выполняют ту же работу, что и вы (или ваш продукт). В качестве понятного примера можно привести McDonald's и конкурентов в лице Burger King и KFC. В нашем кейсе это были два других сервиса видеоинтервью
Второстепенные конкуренты. Это те, кто выполняют работу другим способом. В случае с McDonald's это сети быстрого и вегетарианского питания. В нашем кейсе это были компании, которые вместо видеоинтервью составляли детализированные анкеты и проводили онлайн-опросы кандидатов
Непрямые конкуренты. Это те, кто выполняют другую работу, которая также направлена на ваших пользователей, но приводит к конфликту результатов. В случае с McDonald's это могут быть приложения по снижению веса, а в нашем кейсе — например, сервисы азартных игр.

3. Задайте вопросы пользователям

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

Вот как он может выглядеть:

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

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

4. Определите четыре силы

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

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

5. Продумайте переключение на продукт для клиентов компаний

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

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

Что мы сделали:

1. Наряду с настройкой классической системы продаж подготовили наглядную демонстрацию продукта.

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

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

6. Проработайте период размышления клиента (Consideration set)

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

Есть вопросы, которые помогают понять, в каком конкретно состоянии находится пользователь в этот период:

Когда вы принимали решение о приобретении старого продукта, вы изучали, какой инструмент подходит для вашей компании лучше?
Вы были единственным, кто искал решение в то время?
Где вы впервые услышали об инструменте, которым воспользовались?
Можете вспомнить, как вы пришли к решению заплатить за инструмент?
Во время поиска вы или кто-либо другой пробовали другие инструменты? Какие?
Кто принял решение использовать инструмент? Эти люди еще работают в компании? Какие у них роли сегодня?
Сколько прошло времени с начала поиска, прежде чем вы купили старый продукт?
Когда компания начала использовать продукт?

Что мы сделали:

1. Прописали четкие вопросы для клиентов.

2. Для менеджеров по продажам разработали список «железных» аргументов по каждому вопросу.

3. В CRM прописали конкретные скрипты, которые использовали, чтобы помочь клиенту принять решение о покупке.

7. Сделайте обоснование выбора

Итак, первой из причин для выбора JTBD стало преимущество перед методом «персон».

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

Третьей причиной стала проблема — ранее мы не могли проводить количественные исследования (что характерно для многих B2B-продуктов).

Да, продукт изначально был нацелен на рекрутеров. Но среди них были:

Нанимающие менеджеры (рекрутеры)
Директоры по подбору персонала (HR)
Лица, принимающие решения о выделении бюджета (ЛПР).

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

Внедрение фреймворка JTBD в компании

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

Что мы для этого сделали:

1. Заручились поддержкой стейкхолдера. Объяснили ему, для чего нужен фреймворк и как он поможет разработке продукта, достижению метрик. В частности — что использование фреймворка будет полезным ввиду долгого цикла продаж продукта (условно говоря, вы можете понять, что клиент продлил контракт благодаря какой-то фиче только спустя год после ее релиза, когда перезаключается договор).

2. Взяли преимущества JTBD из «обоснования выбора» и использовали их в качестве аргументов при презентации фреймворка сотрудникам.

3. Проговорили с командой процесс добавления нововведений и объяснили их причины. Это сделали, поскольку внедрение фреймворка связано с определенной шаблонизацией Product Requirements Document (PRD) — документа с требованиями к продукту (аналог технического задания).

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

5. Переписали задачи из бэклога. Так мы показали преимущества JTBD-разработчикам и объяснили на конкретных примерах, как это работает. Вдобавок тем самым мы провели дополнительный груминг (причесывание бэклога).

6. После определенного периода «обкатки» провели митап, на котором рассказали про фреймворк всей компании и раскрыли этапы процесса создания Job Story (истории) и в дальнейшем — фичи продукта. Это сняло окончательные вопросы и синхронизировало разработку и продажи.

А вот как мы использовали фреймворк при работе над проектом.

Внедрение Job Stories

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

[ Когда _____ ] [ Я хочу _____ ] [поэтому мне необходимо _____ ].

Для того чтобы задача выполнялась максимально четко, на каждом этапе Job Story добавляем фокусировку:

[Когда ____ (фокусируется на ситуации)], [Я хочу ____ (фокусируется на мотивации)], и [поэтому мне необходимо ____ (фокусируемся на результате)].

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

Когда мы поняли ситуацию, в которой столкнулись с проблемой, требующей решения, поняли мотивацию к ее решению и выяснили, какова выгода — мы стали увереннее в том, что создаем ценный для клиентов продукт. Вдобавок эти истории можно использовать в отделе продаж для создания контраргументов, скриптов и работы с разными сегментами пользователей (рекрутеры, директоры HR и ЛПР).

Настройка процесса работы

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

Смотрели, как на данный момент люди решают проблему (какую работу для этого выполняют).
Определялись с Job Story, которая исследует причины, беспокойства и мотивацию относительно того, что пользователи сейчас делают.
Предлагали решение, которое выполняет эту работу.

Задача в трекере может выглядеть следующим образом:

Какую проблему мы решаем и почему
Job Story
Как мы измеряем успех (результат)
Что необходимо сделать (список работ заполняется совместно с разработчиками).

При этом в заголовке задачи мы сразу прописывали Definition of Done (DOD) — критерии, которые определяют, сделано ли то, что было целью разработки. Для чего также использовали Job Story.

Пример. DOD пользователь может сделать то-то и то-то согласно макетам.

Дизайн на основе Job Story

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

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

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

1. Useful. Что именно я делаю, когда использую конструктор страниц?
Я создаю персонализированное описание, добавляю фото офиса и видеозапись с рассказом генерального директора о нашей компании и о продукте.

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

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

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

Презентуем фреймворк стейкхолдерам
Презентуем фреймворк команде и коллегам
Создаем шаблоны для упрощения процесса проведения job interview
Создаем шаблоны PRD
Регулярно проводим интервью с клиентами и собираем обратную связь от менеджера продаж (в идеале — уже в формате Job Story)
Регулярно наблюдаем за тем, как пользователи применяют наш продукт (например, мы сами подбирали персонал при помощи видеоинтервью, смотрели скринкасты клиентов, наблюдали, как рекрутеры используют продукты конкурентов).

Заключение

Фреймворк JTBD подходит для использования в B2B-продуктах, так как позволяет работать с разными сегментами пользователей и фокусироваться на проблемах, которые решает для них продукт.

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