| Концепция Jobs To Be Done (JTBD): Почему она превосходит сегментацию по персонам и как применять её в B2B-разработке |
| 20.06.2026 10:01 | ||||||
|
В современной продуктовой разработке выбор правильной методологии анализа целевой аудитории определяет успех продукта на этапе проектирования. Традиционно маркетологи и дизайнеры полагаются на создание «персон» — вымышленных портретов пользователей, основанных на демографических данных и психографике. Однако в условиях высокой конкуренции и усложнения клиентских потребностей классический подход часто оказывается недостаточно эффективным. Альтернативой, обеспечивающей более глубокое понимание мотивации пользователя, становится концепция Jobs To Be Done (JTBD). Ограничения метода персон: почему «кто» не всегда определяет «что»Метод построения портретов пользователей (User Personas) фокусируется на характеристиках индивида: возрасте, месте жительства, должности и интересах. Хотя этот подход полезен для визуализации аудитории, он обладает существенным методологическим изъяном — он предполагает, что поведение человека определяется его идентичностью. На практике же потребители часто совершают покупки или используют сервисы не потому, что они «маркетолог в возрасте 30 лет», а потому, что им необходимо решить конкретную задачу в определенный момент времени. Два пользователя с абсолютно разными демографическими профилями могут иметь одну и ту же «работу» (job), которую они хотят выполнить. Фокусировка исключительно на персоне может привести к созданию продукта, который соответствует ожиданиям группы людей по внешним признакам, но не решает их реальных проблем. Суть концепции Jobs To Be Done: фокус на действии и контекстеКонцепция JTBD базируется на идее о том, что потребители «нанимают» продукты для выполнения определенных задач (jobs). Продукт — это инструмент, который помогает пользователю перейти из состояния А (проблема или потребность) в состояние Б (желаемый результат). Ключевые отличия подхода JTBD от анализа персон заключаются в трех аспектах:
Применение JTBD при разработке нового сервиса или сайтаПри проектировании интерфейсов и функционала нового цифрового продукта переход от персон к задачам позволяет структурировать процесс разработки следующим образом: 1. Идентификация «работ» через интервью Вместо вопросов о предпочтениях, необходимо проводить глубинные интервью, направленные на изучение истории действий пользователя. Важно выявить момент принятия решения: что произошло непосредственно перед тем, как пользователь решил использовать текущее решение? Какие барьеры мешали ему до этого момента? 2. Формулирование Job Stories Вместо классических User Stories («Как пользователь, я хочу...»), в рамках JTBD используются Job Stories. Они строятся по формуле: *«Когда [ситуация/контекст], я хочу [действие], чтобы [желаемый результат]».* Этот формат заставляет команду разработки фокусироваться на триггерах и целях, а не просто перечислять функции. Например: *«Когда мне нужно подготовить отчет для руководства в сжатые сроки (ситуация), я хочу автоматически агрегировать данные из разных таблиц (действие), чтобы избежать ручного ввода и минимизировать риск ошибки (результат)».* 3. Приоритизация функционала На основе Job Stories команда может оценить, какие функции напрямую способствуют выполнению «работы», а какие являются избыточными или декоративными. Это позволяет оптимизировать MVP (минимально жизнеспособный продукт), исключая элементы, которые не ведут пользователя к его цели. Специфика применения JTBD в B2B-сегментеВ сфере B2B разработка продуктов осложняется тем, что решение принимает не один человек, а группа лиц с разными интересами (центр принятия решений). Однако концепция JTBD здесь работает даже эффективнее благодаря четкому разделению ролей. Разделение задач по ролямВ B2B-продукте одна и та же задача может иметь разные «работы» для разных участников процесса:
Фокус на организационных измененияхВ B2B-сегменте «работа» часто связана с изменением внутренних процессов компании. Продукт должен помогать организации перейти из состояния неэффективности в состояние эффективности. При разработке сервиса важно понимать, какие административные или культурные барьеры мешают внедрению продукта и как ваш сервис помогает их преодолевать. ЗаключениеПереход от анализа «кто наш клиент» к пониманию «какую работу делает наш клиент» позволяет создавать продукты с более высокой ценностью для пользователя. Концепция Jobs To Be Done дает разработчикам четкий вектор: продукт должен быть не просто удобным или красивым, он должен эффективно помогать пользователю достигать прогресса в его конкретном контексте. Внедрение этого подхода на ранних этапах проектирования позволяет сократить количество ошибок при разработке и создать решение, которое пользователи будут «нанимать» снова и снова.
|
