Framework что это в маркетинге

Обновлено: 06.07.2024

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

Зачем нужны фреймворки

Аудитория продукта — это абстрактная толпа людей. А три персоны или четыре job story — конкретные инструменты маркетолога. Фреймворки делают непонятное понятным.

Если вы применили фреймворк, но понятнее не стало, то есть два варианта.

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

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

Фундаментальная проблема в этих ситуациях — к фреймворку относятся как к священному объекту, который нельзя менять и адаптировать. Но это неправильно. Не бывает one-size-fits-all фреймворка.

Чтобы лучше понять эту идею, посмотрим на два примера. Один хороший, другой не очень.

Хороший и плохой пример

RFM-анализ

Всю аудиторию делим на сегменты исходя из трех критериев:

Recency — когда пользователь сделал последнюю покупку

Frequency — сколько раз пользователь делал покупки

Money — сколько пользователь суммарно принес выручки

Такой подход будет отлично работать в e-commerce продуктах или играх с встроенными покупками. В курсе по интернет-маркетингу мы хотели применить RFM-анализ на приложении с короткими смешными видео (как TikTok). Оно монетизируется через рекламу.

Оказалось, что классический RFM-анализ бесполезен. Пользователи не совершают покупки, а просматривают рекламные ролики. Из-за этого Recency будет измеряться минутами, а Frequence и Money будут сильно коррелировать.

Поэтому мы изменили критерии. Вот что получилось:

Recency — сколько часов назад пользователь последний раз заходил в приложение.

Frequency — сколько раз в день пользователь заходит в приложение.

Money — сколько роликов пользователь в среднем смотрит в день.

Это не каноничный RFM-анализ, но он решает конкретную проблему в продукте — выделяет полезные сегменты для рассылок push-уведомлений. Это хороший пример адаптации фреймворка.

Персоны и JTBD

Помимо количественного анализа целевой аудитории есть качественный. Здесь популярны два фреймворка: Persona и Jobs To Be Done. Persona — это создание портрета покупателя, а JTBD — это определение работы, на которую нанимают продукт.

Умные люди еще не решили, можно ли объединять эти фреймворки. Например, Intercom считает , что персоны не помогают понять пользователя. Тот факт, что человеку 35 лет и у него две собаки не объясняет, почему он купил Сникерс. А работа “утолить голод” в JTBD — объясняет.

Но Intercom не прав. Работа «утоление голода» не объясняет, почему Питер купил именно Сникерс, а не другой батончик. Ведь в магазине десятки батончиков, каждый из которых утоляет голод. Очевидно, что JTBD не дает ответ на этот вопрос.

Но персона в классическом понимании тоже бесполезна. Такие обобщенные портреты приводят к тому, что в каждом продукте целевая аудитория — это молодой человек 25 лет, который работает в айти и живет в однокомнатной квартире.

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

Подход Intercom — это плохой пример, как не надо работать с фреймворками. Если команда игнорирует фреймворк, который может сделать непонятное понятным, то она делает хуже себе.

Бесплатный курс по продуктовому мышлению

За неделю вы научитесь применять продуктовое мышление в работе и жизни

Как сделать фреймворк еще лучше

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

Есть три инструмента, которые помогут вам пройти этот путь.

Mutually Exclusive Collectively Exhaustive — принцип структурирования, который придумали умные ребята в McKinsey. Ключевая идея — делить объект на взаимоисключающие и коллективно исчерпывающие сегменты. То есть сегменты не накладываются друг на друга, а их сумма равняется 100%.

не MECE деление целевой аудитории : молодежь, женщины и офисные сотрудники. Один человек может входить в несколько сегментов, в сумме эти три сегмента дадут больше 100%.

MECE деление целевой аудитории : дети, молодежь, взрослые, пенсионеры. Каждый сегмент выделен по возрастной группе. Они не будут пересекаться, а в сумме дадут 100%.

Задание

Выберите все варианты ответа, в которых не соблюдается принцип MECE.

Top-down и Bottom-up

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

Если проблема фундаментальная, то вам нужен Top-down подход. Ухудшение качества лидов — это фундаментальная проблема, которую нужно разложить на более мелкие. Это могло произойти из-за выгорания креативов, изменений в лендинге и сезонности продукта. Идем сверху вниз.

Если вы нашли несколько мелких проблем, то вам нужен Bottom-up подход. Падение конверсий на экране оплаты, негативные отзывы в сторе и снижение Retention day 1 — могут быть сигналами, что есть проблемы с качество онбординга. В таком подходе мы идем снизу вверх.

Приходите в наш телеграм — там полезные шаблоны и классные задачки.

Задание

Представьте, что в блоге вашего продукта упал MAU (Monthly Active Users). Что может быть локальной проблемой?

Матрица 2x2

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

Кстати, матрица 2х2 всегда будет MECE. Это еще один плюс.

В статье про определение позиционирования продукта нам надо было определить, в какой “ментальной папке” находится продукт у пользователя. Поэтому мы взяли матрицу Росситера-Перси, которая раскрывает уровень риска и мотивацию при покупке. Сразу стало понятна разница при покупке холодильника и шоколадки.

Задание

Вы запускаете новый e-commerce продукт на рынок США. По каким критериям вы будете сравнивать себя с конкурентами в матрице 2х2?

Читайте лучшие статьи по продакт-менеджменту

Раз в неделю будем отправлять свежий дайджест вам на почту. Наc читает 12000 человек 🚀

Резюмируем

Обычно, обнаружив проблему, мы быстрее бежим ее решать, погружаемся в операционное болото и пробуем все, что можно попробовать. Это весело, но неэффективно.

Попробуйте сначала заструктурировать проблему и минимизировать непонятное. Поиск решений займет меньше времени, а результаты получатся более системными. В этом вам помогут фреймворки.

Не бойтесь адаптировать фреймворк под вашу ситуацию: меняйте критерии, объединяйте и дополняйте. Вам нужно сделать непонятное понятным. Для этого подойдут все средства.

Зачастую за понятием «фреймворк» кроется методология проектной работы — инструмент, помогающий командам оценивать актуальность продукта для рынка и реализовывать сложные бизнес-проекты. А еще — генерировать больше полезных идей, которые действительно будут востребованы клиентами. Своим опытом внедрения фреймворка 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 позволяет глубже рассматривать конкурентов, так как определяет их не по сегменту или персоне, а именно по «работе», которую выполняет продукт.
Не ищите конкурентов по принципу соревнования в смежных или одинаковых категориях.

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

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

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. Какой результат от использования?
Персональный лендинг, который подробно описывает вакансию и улучшает отношение к бренду.

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

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

Заключение

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

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

Рассказываем о применении теории JTBD на практике: как строить исследование, проводить интервью и какие есть фреймворки.

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

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

Когда мы писали статью, то основывались на материалах Дмитрия Капаева, сооснователя агентства Useful, которое проводит исследования пользователей по теории «работ». Дима пришёл к нам в гости и поделился крутыми инсайтами по работе с JTBD, а мы рады поделиться ими с вами.

Как будет выглядеть процесс исследования и какие у него будут этапы?

Определяем цель исследования. Для начала нам необходимо определить цель: что мы хотим исследовать и что хотим узнать на выходе.
Формулируем гипотезы работ. Попытаемся определить работы на основе своего опыта и опыта наших клиентов.
Проводим интервью. Наблюдаем и собираем инсайты пользователей.
Анализируем данные. Интерпретируем полученную информацию с помощью фреймворков.
Создаем Job stories. На основе полученных инсайтов формулируем Job Stories.
Придумываем решения. На основе полученной информации улучшаем наш продукт или корректируем стратегию.

На этом этапе нужно определить, что мы хотим узнать в ходе исследования. Допустим, мы создаём этичную косметику: у нас в составах только натуральные ингредиенты, продукция не тестируются на животных и не используется пластиковая упаковка. Все наши продукты пользуются спросом, кроме крема для тела. То есть наша цель исследования — понять, почему нет спроса на этот крем.

Вместе с целью нам нужно определить вопросы к исследованию:

На какие работы пользователи нанимают наш крем?
Почему пользователи покупают крем?
Почему пользователям не нравится крем?

После того как мы сформулировали цель и определили вопросы, переходим к следующему шагу.

На этом этапе нам необходимо сформулировать гипотезы по Job Stories, определить наших прямых и непрямых конкурентов и выбрать респондентов, которых будем опрашивать.

Неэтичные косметические марки.

Нам нужно сформулировать гипотезы, на которые пользователи, возможно, нанимают наш продукт. Гипотезы помогут определить «портреты» респондентов, с которыми мы будем проводить интервью.

Формулировать работы будем по Job Stories, которые придумала Intercom и описала их применение в своей книге “Intercom on Jobs-to-be-Done”. Фреймворк выглядит как предложение: “When <situation> I want to <motivation> So I can <outcome>”.

Ситуация — описание контекста, в котором у пользователя возникает проблема.

Мотивация — желаемое решение проблемы.

Ауткам — это тот прогресс, который хочет совершить человек в будущем.

В этом случае нам важно не только, что пользователь хочет, а контекст: какая ситуация повлияла на появление желания.

Гипотезы Job Stories для марки этичной косметики:

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

На этом этапе гипотезы работ могут быть достаточно абстрактными, так как само исследование ещё не было проведено.

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

Для интервью желательно отбирать тех, кто недавно покупал у вас что-то, потому что в их памяти ещё свежи воспоминания, ощущения и эмоции о покупке.

Мы определили цель исследования, сформулировали гипотезы работ, определили релевантных респондентов, теперь нам нужно их опросить.

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

Вспоминаем фреймворк Алана Клемента из первой части статьи. Эта модель описывает, как создаются работы и как эти работы становятся причиной найма и увольнения продуктов.

То есть из интервью нам необходимо узнать:

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

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

Посмотрите на интервью в формате JTBD, которое проводят Крис Спик и Боб Моэста с респондентом о покупке машины. Это поможет вам понять логику интервью и определить примерный пул вопросов.

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

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

Почему вы решили купить крем?

Что стало причиной покупки крема?

Зачем вам понадобился крем?

Почему вы выбрали именно наш крем?

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

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

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

После первой покупки Люба вернулась к нам, чтобы купить шампунь, но не не стала покупать крем. Мы решили узнать почему. Оказалось, что крем всё ещё не закончился. Мы были рады услышать, что крем получился экономичным.

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

Мы провели десять таких интервью. Теперь у нас на руках много полезной информации. Что мы делаем с этим дальше? Прослушиваем записи, анализируем и начинаем интерпретировать их. Как раз тут нам помогут фреймворки JTBD, чтобы найти работы, определить контексты, понять struggle moments.

Анализировать и интерпретировать полученную информацию будем с помощью нескольких фреймворков.

Фреймворк «Силы прогресса» Криса Спика и Боба Моэсты

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

Что было толчком к принятию решения о покупке? То, что Люба стала экоактивисткой.

Что привлекает Любу в новом решении? Что она будет красива и свежа и при этом останется экогёрл.

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

За что переживает Люба? Любу пугает то, что крем необычной текстуры — он твёрдый, она такого никогда не видела раньше, и возможно, он будет плохого качества.

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

Все наши приобретённые вещи и решения проходят путь от «первой мысли» до «удовлетворения новым решением» или «разочарования в новом решении». Если мы разочаровались в новом решении, мы начинаем заново проходить путь.

Таймлайн помогает определить, когда произошла первая мысль о покупке, что произошло в «Событии № 1», что заставило нас начать активный поиск, что произошло в «Событии № 2», когда мы приняли решение о покупке, и так далее.

Очень важно узнать, что произошло с пользователем в период с «первой мысли» до «покупки».

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

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

Job Story помогает понять, когда и в каких условиях у клиента закралась первая мысль о покупке продукта (то есть то, что случилось ещё до начала его использования).

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

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

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

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

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

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

После того как мы просегментировали Job Stories, самое время проанализировать, какие изменения в продукте потребуются, и заняться улучшениями!

Если вам интересно почитать, что пишет Дима про JTBD, вот его блог на Medium, а это канал в Telegram.

От правильности создания продуктового фреймворка зависит эффективность работы команды и результат запуска нового продукта. Мы предлагаем познакомиться с универсальным product framework, состоящим из 7 шагов:

Ideation.
Discovery.
Design.
Development.
Deploy.
Scale.
Management.

Шаг 1. Ideation

Idention — 1 этап разработки нового продукта, в ходе которого цифровые инициативы проверяют на валидность, то есть отвечают на вопрос: «Что делать, а что не делать?».

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

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

После первого шага появляются следующие документы (артефакты):

бизнес-идея с оценкой эффектов;
список команды исследования;
Lean Canvas;
гипотеза о проблеме;
договор с подрядчиком (если планируется делегирование реализации какого-либо функционала или задачи);
гипотеза о решении;
карта дизайн-сессии;
скоринговая модель инициатив;
и другие.

Шаг 2. Discovery

В рамках исследования валидной идеи необходимо ответить на ряд вопросов:

как сделать?
кто будет делать?
какие инструменты и решения использовать в работе?

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

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

После второго шага появляются следующие документы (артефакты):

бэклог проблем и гипотез;
customer journey map (CJM) — то, как клиент будет проходить по бизнес процессу, что он будет испытывать, где его работа станет более эффективной и т.п.;
карта AS-IS на данный момент;
готовые решения;
ключевые метрики;
и другие.

Второй шаг заканчивается после окончания исследования последней идеи и фиксации списка валидных идей.

Шаг 3. Design

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

Приступают к созданию, но пока что в виде дизайн-проекта, а не в цифровом виде. Формируют первый интерфейс, технологическое описание, фирменный стиль и так далее.

После третьего шага появляются следующие документы (артефакты):

описание метрик успешности продукта;
бизнес процессы «to-be», то есть как они должны выглядеть после проектирования, успешного внедрения и использования продукта;
дизайн-система;
бэклоги проблем клиента и решений;
требования к разработке;
первый MVP (например, нарисованный на бумаге).

Шаг 4. Development

На четвертом шаге приступают к реализации программного обеспечения будущего продукта. Опытные команды применяют гибкие методы разработки, например, Agile, Scrum, LeSS, SAFe и другие.

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

Обратная связь важна в разработке любого продукта. Важно понять, что думают потенциальные потребители. Ранее мы рассказывали, почему в рамках создания продукта важно достичь соответствия ожиданиям целевой аудитории (product market fit).

После четвертого шага появляются следующие документы (артефакты):

бэклоги продукта и спринтов;
MVP;
прикладная архитектура;
репозиторий;
release notes;
и другие.

Шаг 5. Deploy

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

После пятого шага появляются следующие документы (артефакты):

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

Шаг 6. Scale

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

Кстати, мы уже рассказывали про стратегию взрывного роста growth hacking. Ее реализацию можно внедрить в product framework и получить десятки тысяч пользователей за минимальный период. Главное — подобрать оптимальную связку для взрывного роста своего продукта.

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

После шестого шага появляются следующие документы (артефакты):

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

Шаг 7. Management

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

После седьмого шага появляются следующие документы (артефакты):

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

Мы показали пример product framework, который можно использовать при создании нового продукта. Помните, что его надо адаптировать под конкретную организацию, продуктовую команду и поставленные задачи. Слепое копирование готового фреймворка — плохой вариант, который не приведет к эффективной работе.

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

Почему важна профессиональная команда

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

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

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

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

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

Предлагаем начинающим продакт-менеджерам сразу приступить к практике: разработайте product framework для какого-нибудь гипотетического продукта.

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