В материале использован вольный перевод некоторых отрывков из книги Jobs-To-Be-Done by Intercom. Anna Buldakova опубликовала неплохой перевод из книги на медиуме.
Хочу рассказать вам про один классный фреймворк, о котором, к сожалению, знают немногие: Jobs-To-Be-Done (JTBD). Его популяризировал профессор Гарвардской школы бизнеса и автор “Дилеммы инноватора” Клейтон Кристенсен.
Компании стремятся улучшить свой продукт, но этого недостаточно. В итоге кто-нибудь изобретет новый способ решения проблемы, и пользователи просто переключатся на другой продукт.
В основе Jobs To Be Done также лежат работы Даниэла Канемана, Амоса Тверски, Гэри Кляйна и других ученых, которые исследовали процесс принятия решения: почему пользователи принимают нерациональные решения, не всегда действуют в своих интересах и бывают непоследовательны, высказывая мнение о продукте.
Все это начало превращаться в методологию в конце 80-х годов благодаря предпринимателю Бобу Моэста и профессору Гарвардской школы бизнеса Клейтону Кристенсену.
В статье для Harvard Business Review и книге «Дилемма инноватора» Кристенсен пишет, что растущее количество данных о пользователях не помогает компаниям, а уводит в неправильном направлении.
Данные показывают взаимосвязи (68% пользователей страница А нравится больше, чем страница Б), но ничего не говорят о причинах.
Фокусироваться надо на том, чего стремится достичь пользователь в определенных обстоятельствах. Это и называется job to be done — «работа, которую надо выполнить».
Суть подхода очень простая:
вот есть, к примеру, Петя. Пете 30 лет, у него жена и ребенок. Петя трудолюбивый, веселый и добрый. По выходным Петя ходит в спортзал, а раз в месяц встречается с друзьями в спортбаре.
5 минут назад Петя купил сникерс.
Повлияла ли какая-то из характеристик, перечисленных выше, на факт покупки? Нет, не повлияла. Петя купил сникерс не потому, что ему 30 лет, а потому что он проголодался.
Смысл в том, что у нас всех постоянно возникают какие-то задачи (“работы” в терминологии JTBD): убить время, стоя в очереди; приготовить полезный завтрак; поделиться впечатлениями от поездки. Когда мы начинаем пользоваться каким-то продуктом, мы по сути “нанимаем” его, чтобы он помог нам выполнить какую-то конкретную “работу”. Продукт не матчится с человеком или его особенностями, он матчится с проблемами, которые он решает.
Конечно, идея строить продукт вокруг проблемы совсем не нова (собственно, и JTBD существует уже больше 30 лет, но применялся преимущественно в производстве физических продуктов). JTBD просто дает удобный фреймворк и инструментарий для работы, вот и все. Но разница в организации команды, в построении стратегии и разработке фич — огромная.
User stories vs job stories
Даже если вы не эксперт в UX, наверняка слышали (или видели) такой шаблон:
As a <type of user>, I want to <action/some goal> so that <outcome>
По сути, это и есть user story — какое-то краткое описание фичи со стороны пользователя. <Type of user> обычно основывается на одной из ваших Персон (про Персон можно почитать подробнее здесь, если вкратце — вы проводите user researches, анализируете онлайн-данные и создаете несколько (стандартно 5–6) собирательных пользователей, которые представляют ключевые сегменты вашей аудитории).
Я, честно, несколько раз пыталась использовать Персон и user stories в работе, но постоянно сталкивалась с одними и теми же проблемами:
- по идее, Персоны должны поддерживать нужный уровень эмпатии в команде, особенно для тех, кто не так много общается с пользователями. На самом деле, никто в команде не был в состоянии запомнить все характеристики даже одной Персоны. Каждый запоминал что-то свое, и в итоге у всех получалась совершенно разная картинка;
- что делать, если твоя аудитория слишком большая и сегментированная? У всех разные цели, разные профессии, разный бэкграунд — комбинаций явно больше, чем 6. Еще интереснее, когда по персональным и соцдем характеристикам аудитория примерно однородна. Тут обычно начинаются попытки все каким-то образом объединить в “Лену, юриста” или “Ваню, студента” — это значит, что мы начинаем делать предположения. Какие-то аспекты и вовсе могут сбить с толку: к примеру, мы делаем фичу “поделиться в соцсетях” для новостного сайта. То, что наша персона работает врачом, должно как-то повлиять на разработку фичи, должны ли мы это как-то учесть? Вот здесь у меня, например, начиналась трансформация what в why — а зачем вообще кому бы то ни было делиться нашими новостями в соцсетях? Что движет пользователем, какая у него мотивация? И, как ни странно, многие персоны при ответе на этот вопрос объединялись в одну группу.
Не будем так уж обижать персон, в целом, это хороший инструмент, чтобы “познакомить” разработчиков с пользователями. Но для определения продуктовой стратегии и приоритизации фич подходит не очень. Вот цитата из статьи Пола Адамса, VP of Product в Intercom (а ранее работавшего в Google и Facebook):
“Whilst best in class personas focus on goals (goals are what drive people’s behaviour) as well as attributes, the reality is that most personas focus on attributes alone, and even goal-driven personas artificially break apart audiences. So critically, personas artificially limit your product’s audience because they focus on attributes rather than motivations and outcomes”.
Таким образом, мы плавно подошли к job stories, которые Intercom и изобрели. И суть в том, что фокус с персональных характеристик смещается на контекст:
When <situation> I want to <motivation> So I can <outcome>
Давайте сравним:
As a 30-летний Петя, I want to съесть что-нибудь вкусненькое, so that я больше не был голодным.
When у меня есть всего 2 минуты, чтобы перекусить между встречами, I want to съесть что-то, чтобы это было просто, быстро и подняло мой уровень сахара в крови, so I can продержаться до обеда и сохранить рабочее настроение.
Чувствуете разницу?
Job story в действии
Разберем теперь более подробно, как составлять job story.
Есть у нас, к примеру, спортзал, где мы хотим увеличить продажи месячных абонементов. Сначала посмотрим на персон (описание довольно условно, в реальности оно гораздо более подробно и детализированно):
- 30-летняя Маша, мать двоих детей. Маша поправилась после родов и хочет прийти в форму, но заниматься может всего два раза в неделю. По факту же занимается она и того реже, частенько пропуская тренировки. По образованию Маша филолог, в свободное время любит рисовать и читать художественные книжки;
- 25-летний спортсмен Никита, завсегдатай нашего спортзала. Никита студент на факультете менеджмента, у него много времени и не очень много денег. Никита любит кататься на велосипеде и ходить в походы с друзьями.
В каком случае такие описания будут нам полезны?
Например, для таргетированной рекламы. Хотим мы привлечь больше Маш или Никит — пожалуйста: устанавливаем настройки кампании в соответствии с определенными характеристиками наших персон и ждем.
Годятся ли они для разработки, тем более, инновационной?
На мой взгляд, не очень. Персона — это какой-то конечный результат исследований и нашего труда; эта та аудитория, которая у нас уже есть. Ориентируясь на персоны, мы искусственно ограничиваем свой продукт, не разрабатываем фичи для новых, потенциальных пользователей. Опять же, фокусируясь исключительно на “старичках”, улучшая продукт для них, мы выпадаем из конкурентной борьбы. Почему? Потому что не думаем о других способах решения проблемы наших пользователей. Мы думаем о том, как они видят это решение, и отполировываем его — вместо того, чтобы в корне менять подход и перебирать варианты решения.
Условно говоря, мы можем построить суперсовременный спортзал с тачскринами и детским уголком — и при этом все равно “отдать” часть пользователей мобильному приложению с тренировками или домашнему велотренажеру.
Давайте вернемся к нашей Маше. Вот пример job story, который мог бы случиться:
Когда я занимаюсь спортом в зале, а у меня есть маленькие дети и мне не с кем их оставить, я хочу, чтобы они были под присмотром, чтобы я не волновалась и спокойно упражнялась в течение часа.
Важно ли тут, что Маше 30 лет? Что у нее двое, а не один ребенок? Кто она по образованию? И что вообще это Маша, а не Аня? Нет, на передний план выходит одна единственная характеристика: что у нашего пользователя есть маленькие дети. В job stories это часть контекста, а не описания пользователя — просто потому, что в контексте могут оказаться совершенно разные по профилю пользователи. В примере с детьми это может быть Маша, а может быть и Никита, если его старшая сестра уехала в командировку и попросила посидеть с детьми, а он не хочет пропускать тренировку.
Легче всего это понять на примере Uber. Вроде как уж здесь-то точно есть две конкретные персоны: водитель и пассажир. На самом же деле, эта характеристика лишь часть контекста: в зависимости от ситуации водитель может оказаться на месте пассажира, и наоборот.
Если мы говорим про магазин сладостей, и контекст “Хочу изредка побаловать себя сладким после тяжелого дня или успешного проекта”, сюда могут попасть как Маша и Никита, так и диабетик Миша, вегетарианка Алиса и сидящий на диете Петя. Мы думаем не о том, что разнит наших пользователей, а что их объединяет. Таким образом, те фичи, что мы делаем и релизим, получают больший охват.
Персоны, безусловно, гораздо лучше, чем ничего. Более того, многие успешные компании до сих пор работают с этим фреймворком и прекрасно себя чувствуют. В любом случае, job stories — это лишь еще один классный способ с другой стороны взглянуть на свой продукт. Персоны позволяют вам под лупой посмотреть на ваших пользователей, но не отвечают на вопрос, почему они продолжают пользоваться вашим продуктом — и почему придут новые после того, как вы зарелизите фичу. В моей картине мире все выглядит примерно так:
- в целом, важно понимать, как выглядит ваша текущая аудитория, — это понимание приходит после регулярных user researches и работы с аудиторными циферками;
- но конкретно перед разработкой фичи или продуктовой стратегии нужна job story.
Как провести исследование для job story
Итак, допустим мы прониклись и хотим написать хорошую job story. С чего начать? Конечно, с исследования.
Большинство текущих исследований фокусируются на моменте потребления продукта, тогда как job story research пытается понять, когда и в каких условиях у клиента закралась первая мысль о покупке продукта (то есть, то, что случилось еще ДО начала его использования). Исследователь основывается на предположении, что на клиента в момент решения о покупке действуют четыре силы:
- недовольство текущей ситуацией (“push”) — “Этот спортзал работает только по утрам, а я хочу заниматься вечером”
- притягательность нового решения (“pull”) — “Другой спортзал открыт круглосуточно”
- тревога, что что-то может пойти не так — “А что если в новом спортзале будет слишком много народу?”
- привязанность к тому, что есть — “Я хожу в этот спортзал уже год и знаю всех тренеров”.
Собственно, основная задача в таком интервью — выявить эти четыре фактора. При этом очень важно понимать не только рациональные, но и эмоциональные аспекты решения (условно — “шел ли дождь, когда вы делали покупку?”):
— В какой спортзал вы ходили раньше? Откуда вы о нем узнали?
— Расскажите, какой образ жизни вы вели в то время? Часто ли испытывали стресс?
— Расскажите мне про свой прежний спортзал. Как часто вы занимались? Опишите по шагам, что происходило после того, как вы открывали входную дверь.
— Что вас особенно расстраивало в прежнем спортзале? Когда вы начали задумываться о поиске нового?
— Когда вы впервые услышали про текущий спортзал? Было ли у вас несколько опций или только одна?
— Как долго вы принимали решение о переходе? Что вас сдерживало от покупки?
И так далее. Очень важный момент: разговаривать надо не с пользователем, а с покупателем; человеком, который принял решение о покупке. То есть, вы должны интервьюировать не ребенка, которому родители купили абонемент в спортзал, а как раз родителей.
Зачем все это и что оно нам дает?
Люди инертны по своей природе. В большинстве случаев, они будут продолжать пользоваться привычным решением, чем исследовать рынок и искать что-то новое — просто потому, что им и так норм. Должно случиться что-то из ряда вон выходящее, чтобы я перестала брать кофе в своей любимой кофейне.
И очень важно понимать, что пользователи не покупают ваш продукт, они переключаются на него с чего-то еще. До нового спортзала был предыдущий спортзал. До предыдущего спортзала была зарядка на коврике по утрам. До коврика были бургеры и мороженое в макдаке (это уже непрямая конкуренция, о ней дальше). Цена переключения с одного продукта на другой определяется привычкой и степенью удовлетворенности, помноженных на страх перемен. И вам критично важно поймать этот момент внутренней борьбы и подтолкнуть пользователя в нужном направлении.
Когда “работа” продукта заканчивается
Продукты решают не изолированные проблемы, а проблемы, которые происходят в каком-то workflow: есть то, что случилось “до”, и то, что произойдет “после”. То есть, таким образом, у “работающего” продукта есть начальная и конечная точки. Вопрос в том, как их правильно определить.
Если ваш продукт делает слишком мало, в глазах пользователя он не стоит того, чтобы его устанавливать (и, тем более, платить за него). Если продукт делает слишком много, он вступит в конфликт с уже существующими элементами workflow, которые вполне устраивают пользователя.
Так где же золотая середина?
Давайте разберем на простеньком примере. Допустим, вы пишете приложение-будильник; в этом случае workflow может выглядеть так:
- Пользователь вечером штырит инстаграмчик
- Понимает, что уже очень поздно и пора спать
- Ставит будильник на 7
- Спит
- Просыпается, идет на кухню выпить воды
- Спит
- Будильник звенит в 7, пользователь переставляет его на 7–30
- Будильник звенит в 7–30, пользователь встает
- Включает радио
- Делает зарядку.
“Работа” вашего продукта должна начинаться с того шага, где вы можете добавить какую-то ценность для пользователя. Для нашего примера это, скорее всего, шаг 3. Мы, конечно, можем влезть и раньше: например, если пользователь обычно встает в 7 утра, а уже 12 вечера, и телефон активен, наше приложение отправит ремайндер: котик, а не хотите ли поставить будильник и пойти спать? Можем пойти еще дальше: сделать фитнес-браслет, который будет трекать пульс и активность пользователя и рекомендовать ему лучшее время, чтобы пойти спать (и будить его, соответственно, тоже в лучшее время для подъема). Нужно ли это? Испытывает ли пользователь “боль”, соответствующую масштабам исследований и разработки? Это и нужно понять и решить продуктовой команде в самом начале.
А когда же “работа” должна заканчиваться?
Когда:
- у следующего шага в workflow есть однозначные маркет-лидеры, и вы не хотите с ними конкурировать
- следующий шаг в workflow может быть решен миллионом разных способов и миллионом разных типов пользователей
- на следующем шагу у нас радикально меняется аудитория
- следующий шаг не добавит никакой ценности продукту.
Конкуренция в контексте JTBD
Какое-то время назад я писала про компанию BVG, которая де-факто монополист в сфере общественного транспорта в Берлине. BVG тратит огромные деньги на рекламу — вопрос: зачем она это делает, если и так все метро, автобусы и трамваи принадлежат исключительно ей?
Если посмотреть на этот вопрос с точки зрения JTBD, ответ придет сам собой. “Работа” пользователя в этом контексте — добраться из точки А в точку Б, а не воспользоваться общественным транспортом. И тут BVG оказывается никаким не монополистом, а лишь одним из участников рынка — наравне с:
— велосипедами
— велосипедами/скутерами напрокат
— такси
— собственными автомобилями
— каршерингом
— да даже передвижением пешком.
JTBD позволяет шире посмотреть на проблемы пользователя и выявить ваших настоящих конкурентов.
Прямая и непрямая конкуренция
С прямой конкуренцией все понятно. Но есть еще один вид конкуренции, о котором все забывают.
Пример: Петя обожает бургеры и хочет питаться только ими, но в то же время Петя хочет быть мускулистым и спортивным.
То есть, условный BurgerKing и FitBit продают совершенно разные продукты и решают разные проблемы, но борются за одного и того же пользователя. Это непрямая конкуренция.
Прямая конкуренция — соперничество за “работу”
Непрямая конкуренция — соперничество за “результат”
Помните наш фреймворк для job stories?
When <situation> I want to <motivation> So I can <outcome>
Вот этот outcome нам и важно определить. В этом контексте Skype, например, соперничает с полетами бизнес-классом, потому что результат у них один — провести бизнес-встречу. Возвращаясь к бургерам и спорту, результат может быть “почувствовать себя счастливым/ более уверенным в себе” или “ощутить принадлежность к какой-то социальной группе”.
Определение глобального “результата” вашего продукта помогает не только правильно позиционировать себя на рынке, но и работать с конкурентами. Чтобы двигаться вперед, вы должны либо сделать “результат” другого продукта менее привлекательным в глазах пользователя, либо же изменить позиционирование продукта, чтобы “результаты” больше не находились в конфликте.
Каждый час в мире открывается около 11 тысяч стартапов — это более 100 миллионов в год. 90% из них ждет провал. Почему? По мнению Fortune, ключевая причина: «они создают продукты, которые никому не нужны».
В век Big Data и бесчисленных инструментов для аналитики, кажется, проще простого понять, кто твой пользователь. Однако проблема не в этом.
Долгое время Nokia и Motorola работали над тем, чтобы удовлетворить потребность своих покупателей: иметь недорогой мобильный телефон с хорошей связью и физической клавиатурой. Потребность взяли не с потолка, а сформулировали по результатам многочисленных исследований. Пользуетесь ли вы таким телефоном спустя 15 лет после бума?
А это Facebook 10-летней давности. В то время такой дизайн считался достаточно передовым, но что бы вы сказали сегодня, открыв подобную страничку?
Невозможно строить продукты будущего, ориентируясь только на запросы и ожидания пользователей от текущего продукта. Люди любили «Нокию» и Facebook 2007 года. Цифры показывали, что все хорошо, аудитория и продажи растут. Но любые данные — это лишь верхушка айсберга.
На какие цифры смотрела Apple, когда убирала кнопки клавиатуры из своих смартфонов? Какие показатели подсказали Facebook, что пора добавлять новые функции?Data-driven дизайн выигрывает в краткосрочной перспективе, но для долгой и счастливой жизни компаниям не обойтись без design-driven подхода.
Одна из самых эффективных концепций в этом контексте — Jobs To Be Done.
Что такое Jobs To Be DoneКлейтон Кристенсен, профессор Гарвардской школы бизнеса, определяет концепт Jobs To Be Done следующим образом:
«Большинство компаний делят свою целевую аудиторию на сегменты по пользовательским или продуктовым характеристикам. Но у пользователя другой взгляд на рынок. У него просто есть задача, которую надо выполнить (job to be done), и он ищет лучший продукт, который поможет ему в этом».
Продукт, который вы создаете, решает проблему пользователя — «выполняет работу». Пользователи покупают, то есть «нанимают на работу» ваш продукт, чтобы он сделал свою работу — и сделал жизнь пользователя немного счастливее.Условная Агриппина Иванова покупает не подписку на конструктор сайтов, а возможность для развития своего бизнеса, а если копнуть глубже — лучшую жизнь для себя и своих детей. Потребности пользователей меняются не так быстро, как технологии, поэтому для инновационных компаний имеет смысл сосредоточиться на проблеме и только потом на решении.
Помимо философии (начинать с проблемы, а не с решения), концепция Jobs To Be Done предлагает набор принципов и инструментов, которые помогают лучше понимать мотивацию пользователя для его привлечения. Придумано это было не за один день, а постепенно эволюционировало и приобретало форму в течение почти 75 лет.
Краткая история подхода JTBD из книги Алана Клемента «Когда кофе и кейл становятся конкурентами»:
Йозеф Шумпетер «Созидательное разрушение»
- Новые решения приходят на смену текущим
- Потребители пользуются только одним средством в один момент времени, чтобы решить свою задачу
- Твоим конкурентом может стать кто угодно
Уильям Деминг «Система глубинных знаний»
- Изучение взаимосвязей и взаимодействий
- Понимание мотивации потребителя как системы
- Процесс инноваций не должен останавливаться
- «Выбросы» и нормальное отклонение
- Корреляция не значит, что между объектами есть причинно-следственная связь
Джордж ЛоуенстайнТревога, вызванная необходимостью выбора и действия
Энн ГрейбилПокупатели подчиняются своим привычкам
Амос Тверски, Дэниэль Канеман «Совокупная теория перспектив»
- Предпочтения зависят от контекста
- Потребители переоценивают потери и недооценивают выгоды
- Количество ценностей, которое может быть у потребителя, ограничено
Гэри Кляйн «Естественное принятие решений»Симуляция прогресса при использовании продукта
Джон Палмер, Боб Моэста, Ричард Педи и сообщество JTBD:
- У потребителей есть «работа», которую они хотят видеть «сделанной»
- Потребителям нужен не продукт, им нужна помощь, чтобы сделать жизнь лучше
- Потребителям нужен прогресс