Intercom про Jobs-to-be-Done. Часть 1 / Mail.ru Group corporate blog / Habr

Jobs-to-be-Done — это подход к созданию продукта на основе анализа работы, которую стремится выполнить клиент с помощью продукта. Появился в 90-х годах и был адаптирован Intercom для IT-продуктов. Подход состоит из теории, почему «вечные» работы, для выполнения которых «нанимают» продукты, важнее свойств личности пользователя, а также фреймворка для практического применения при разработке продуктов.

Вторая часть

Предлагаю вашему вниманию перевод известной в узких кругах книги «Jobs-to-be-Done», выполненный менеджером продукта Ситимобил Александром Ивановым. Согласие Intercom было получено с оговоркой, что ответственность за качество перевода несёт переводчик. 🙂 Это мой первый подобный опыт, поэтому критика приветствуется.

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

В книге девять глав. В первом посте я публикую предисловие, введение и две первые главы.

Я пользуюсь концепцией Jobs-to-be-Done уже более 25 лет как один из старейших её создателей. Концепция помогла мне сделать и запустить на данный момент более 3,2 тыс. продуктов и сервисов. И я не планирую останавливаться. Поэтому написать предисловие к данной книге для меня большая честь.

Члены команды Intercom были моими студентами и клиентами ещё пару лет назад. Но видя, как они применяют Jobs-to-be-Done, могу сказать, что они шарят в этом не хуже меня. Их фокус на целевом рынке и глубина применения фреймворка на уровне маркетинга, продукта, исследований, разработки и др., а также смелость расшарить всё это клиентам действительно поражают.

Данная книга должна помочь продуктовым менеджерам, маркетологам и дизайнерам понять причинно-следственную связь между дизайном продукта, продажами и его последующим использованием. Jobs-to-be-Done никогда не был так важен, как сейчас. Особенно для веба и разработки приложений. Так как низко висящие плоды корреляции и широкой выборки быстро заканчиваются. Фокус на работе клиента и понимание её реальной причины становятся единственным способом переключить пользователя на ваш продукт.

При создании продукта бывает страшно, когда стоишь перед пропастью неизвестности. Ты смотришь вперёд и кажется, что ты одновременно ничего не видишь и видишь всё. Jobs-to-be-Done — это свет, который проведёт вас и вашу компанию сквозь эту бездну.

На первый взгляд, работа, для выполнения которой нанимают ваш продукт, обманчиво очевидна. Клэй Кристенсен, один из создателей теории Jobs-to-be-Done, говорил:

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

Эта книга проясняет, что строгость применения Jobs-to-be-Done компенсируется её простотой. Но требуется попотеть и наладить качественное взаимодействие в команде, чтобы правильно применить концепцию. Книга является отличным практическим пособием, в котором рассказывается, как пользоваться теорией и методикой Jobs-to-be-Done.

Боб Моеста, генеральный директор ReWired Group.

_{Боб Моеста, президент совета директоров и генеральный директор ReWired Group. Вместе с Клейтоном Кристенсеном, профессором Гарвардской школы бизнеса, Боб в середине 90-х был одним из главных разработчиков теории Jobs-to-be-Done.}

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

Когда мы только познакомились с Jobs-to-be-Done, эта концепция показалась нам похожей на то, до чего мы дошли интуитивно: лучшие продукты строятся вокруг решения проблем. Jobs-to-be-Done дала нам описание того, что мы ощущали — терминологию и фреймворк для объединения команды и реализации продуктовой стратегии. Со временем данная концепция в Интеркоме оказалась способом мышления не только о продукте, но и о маркетинговой стратегии, об исследованиях, о продажах и поддержке.

Несмотря на 30-летний возраст, практика применения Jobs-to-be-Done при разработке софта всё ещё довольно нова. Большинство написанного по теме освящает создание физических продуктов. Вы наверняка читали о том, почему люди покупают молочные коктейли или матрасы, но как это применить к покупке приложений?

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

Jobs-to-be-Done позволяет творчески ограничить фантазию по отношению к продукту. Позволяет фокусироваться на том, что хочет получить потребитель. Когда ты закрываешь существующие хотелки, вам не придётся убеждать людей, что им нужен именно ваш продукт. Проще создать то, что действительно хотят люди, чем сделать так, чтобы люди чего-то захотели. Настоящий вызов для компании — понять, какие проблемы решает продукт и улучшить это.

Но наши уроки, как и работы клиентов, которые мы здесь обсуждаем, вечны для любого бизнеса. Вы сможете по-новому воспринимать конкурентов, побуждать клиентов переключиться на ваш продукт, определять границы вашего продукта и работы, которую он выполняет. Мы надеемся, что вы найдёте своё собственное вдохновение в уроках, которые дала концепция Jobs-to-be-Done.

Дэс Трэйнор, кофаундер в Интерком.

Автор: Des Traynor

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

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

Мы поняли, что результат, ожидаемый персоной, важнее её самой по себе. Знание, что на клавиатуре руки 37-летнего человека, редко меняет то, как должен быть спроектирован продукт.

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

***

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

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

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

Совместный креатив. Стейхолдерам проекта следует участвовать и в исследовании, и в анализе — они должны быть вовлечены в создание персон.

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

Но когда ты пилишь продукт, не всегда так бывает.

Создание персоны

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

Если серьёзных различий между вашими пользователями нет, вы получите бесполезные, расплывчатые персоны: возраст — 16-55 лет, высшее образование, хорошее чувство юмора и другие бесполезные критерии. Если персоной можно описать любого, кого вы знаете, то лучше уничтожить её. И если это актуально для десяти последних персон, которые придумали ваши дизайнеры, то у вас проблема. Хорошая интуиция лучше плохих данных.

Плохие персоны получаются потому, что:

• проведено плохое или недостаточное исследование;
  
• персоны — не подходящий инструмент для вашей задачи.
  

Когда персоны хуже, чем ничего

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

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

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

Новое исследование закончилось увеличением продаж молочных коктейлей на 40 %. Их нанимали в первую очередь, утром, чтобы подкрепиться в долгой дороге. Выяснилось, что молочные коктейли конкурируют с бейгелями, бананами и энергетическими батончиками, а не с остальными позициями в меню сетевого заведения. Преимущество милкшейков перед батончиками и бананами в том, что их удобнее употреблять за рулём. Бейгели проигрывают, так как они чересчур сухие и вызывают жажду. Молочные коктейли также выигрывают кофе — они сытные и не вызывают желания посетить туалет во время 40-минутной поездки. Когда в сети фастфуда осознали всё это, то смогли сделать милкшейки лучшим инструментом для выполнения работы. Они предоставили удобный, легко употребимый снэк, чтобы утолить голод в ожидании обеда.

Фокусируясь на работе

Вот несколько работ, которые остаются актуальными уже долгое время.

1. Безопасно, предсказуемо и быстро переместить посылку из пункта А в пункт Б.
   
2. Держать всех членов команды вовлечёнными в проект.
   
3. Пообщаться один на один с коллегой из Сан-Франциско.
   

Работы могут существовать в долгосрочной перспективе. Юлий Цезарь часто вынужден был делать первую работу из списка, поэтому нанял людей и лошадей. Сейчас у нас есть FedEx. А работа не изменилась.

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

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

Когда нанимают приложение?

Когда вы фотографируете, у вас может возникнуть несколько разных работ. Вот шесть из них.

1. Поймать ценный для парочки момент — такой, который можно будет с любовью вспомнить через много лет.
   
2. Троллить друга на глазах другого друга.
   
3. Сделать фото и сохранить онлайн, чтобы отметить всех участников.
   
4. Сделать копию фотографии для бабушки, которая не пользуется компьютером.
   
5. Сделать фотку крутой и интересной, а потом пошарить её.
   
6. Обработать фото и разместить в портфолио, чтобы меня могли нанять на коммерческие проекты.
   

В этих случаях продуктами, которые вы нанимаете, могут быть Facebook, iPhoto, Flickr и, возможно, 500px. Когда вы задумываетесь, какие приложения использовать, вы понимаете, что их различие в работах, а не в вас.

Вы не меняетесь. И вполне нормально, что работы накладываются друг на друга. Это напоминает наемного работника, который делает сверх необходимого для продвижения по службе.

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

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

Фотографии, опубликованные в Facebook, часто невысокого качества. Они просто выполняют работу моментального расшаривания, чтобы друзья могли поржать. Facebook получит больше пользы от инструмента по добавлению пузыря с текстом на фотки, чтобы троллить было ещё проще, чем от высокого качества изображений и информации о фотокамере.

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

Как отмечал Питер Друкер, клиент редко покупает то, что компании кажется она продаёт ему. Иногда конкретный тип клиента определяет работу, которую ему нужно выполнить. Порой работа сама по себе является единственным движущим фактором. Часто сложно заметить разницу. Это напоминает мне поэму В.Б. Йейтса:

«О музыки качанье и безумье — Как различить, где танец, где плясунья?»
«Among School Children», В.Б. Йейтс

Автор: Des Traynor

Когда люди думают о своих соперниках, они склонны смотреть на то, что находится у них под носом. Если я побегу в пиццерию, а вы в McDonalds, то мы, наверное, соперники, так? Но не всё так просто.

Jobs-to-be-Done может быть теми очками, через которые вы увидите реальных соперников. Концепция даёт ситуационный контекст, побуждающий людей использовать продукт. Возвращаясь к примеру выше: если я знаю, что мои клиенты выбирают пиццу, потому что до неё идти 5 минут, а им необходимо быстро перекусить перед встречей, то я понимаю, что мой соперник — не McDonalds. На самом деле я конкурирую со Snickers и тележкой хот-догов неподалёку.

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

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

***

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

McDonalds и Weight Watchers продают совершенно разные продукты, но они сражаются за одних клиентов. Это мы называем непрямой конкуренцией. Она отличается от соревнования за результат. Видеоконференции и перелёты бизнес-классом соревнуются за результат, так как нанимаются для выполнения одной работы — проведения бизнес-встречи.

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

• «Хочу добавить приём платежей в свой продукт, но в то же время хотелось бы уменьшить объём внешнего кода».
  
• «Хочу добавить эту аналитическую тулзу, вместе с тем хочется оптимизировать скорость работы».
  
• «Хочу знать, как расходуется время командой, но также хочу, чтобы мы работали в атмосфере доверия».
  

Это может идти против логики, но для людей нормально иметь несколько разных конфликтующих мнений и желаний одновременно. Мы хотим «и рыбку съесть, и на трамвае покататься».

Что можно сделать?

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

Пример

Один из клиентов Intercom был в шоке. Сотни компаний присоединились к его продукту для проведения А/Б-тестирования, но немногие из них выходили за рамки тривиального тестирования. Они хотели лучше понимать продукт и как его использовать. Наш клиент использовал Intercom для того, чтобы писать сообщения своим клиентам, и узнавать, что пошло не так.

Какая вскрылась проблема? Так же сильно, как идею А/Б-тестирования, клиенты любили чистый, понятный и поддерживаемый код. Им не нравилось добавлять java-скрипты в свои приложения для проведения А/Б-тестов, поэтому продуктом они не пользовались.

Чтобы адресовать эти проблемы, клиент добавил в рассылку несколько сообщений, в которых уменьшал важность чистого кода и стимулировал к покупке более дорогой/платной версии. Не платящим пользователям на третий день он отправлял сообщение следующего содержания: «Если никто не пользуется вашим продуктом, то какое значение имеет чистота вашего кода?» На седьмой день он отправлял другое актуальное сообщение с текстом: «Этим утром ваша команда может добавить немного кода или немного клиентов. Что выберете?»

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

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

Продолжение — вторая часть

Jobs To Be Done — Работа, которая должна быть выполнена — Сибирикс

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

Леночка изучила целевых персон вдоль и поперёк: и сколько им лет, и в каком социальном статусе, и какие у них интересы, и барьеры, и предпочтения. И конкурентов изучила: ну всё то же самое делают же, что и контора Никанора Ивановича, а у них продаётся лучше!

«Ну что с этим делать-то — опять сливать бюджеты в рекламу? Леночка ничего нового уже не придумает про наши железки, всё про то да потому… Но старается ж… Я и сам голову сломал… Похоже, не повезу я свою Пышечку на золотую свадьбу в Таиланд отдыхать, как обещал — не на что, зарплату бы работягам выплатить»… Прокручивая этот диалог в голове, Никанор Иванович не глядя залез правой рукой во второй ящик своего секретера, нащупал холодную железную флягу, накатил глоточек и набрал внутренний номер Леночки: «Елена Александровна, ну давайте тот макет рекламы, что вы на прошлой неделе показывали, рассылать в профильные СМИ. Деньги выделю».

Если бы Никанор Иванович вместе с Леночкой знали, что целевые персоны не всесильны, то давно бы пересмотрели свой подход к потребителю, опираясь на концепцию Jobs To be Done (JTBD). Это когда вместо глубокого (и часто бесполезного) анализа возрастов и сфер интересов потребителя нужно сосредоточиться на том, какую «работу» этот продукт может для него выполнить здесь и сейчас. Теория отнюдь не новая, но почему-то о ней мало кто знает и ещё меньше специалистов ей реально пользуются.

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

Что такое концепция jobs-to-be-done

June 5, 2016

Надя Поминова Инструменты

Когда около двух лет назад я впервые узнала про концепцию Jobs-to-be-done (работа, которая должна быть проделана), я была под большим впечатлением. С тех пор я часто ссылаюсь на неё, видео с рассказом Клейтона Кристенсена о том, как это работает, только на английском языке, что очень усложняло дело. Поэтому я подготовила русские субтитры к этому видео. Кто ещё не знает, что такое «работа, которая должна быть проделана», смотрите видео с русскими субтитрами или читайте расшифровку ниже.

Расшифровка видео

Здравствуйте, я Клэй Кристенсен, профессор Гарвардской школы бизнеса. Я приготовил несколько загадок, все они касаются инноваций.

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

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

Мой коллега задался другим вопросом. Какая работа заставляет клиентов прийти в этот ресторан и нанять коктейль? В один день мы остались в ресторане на 18 часов и всё подробно записали:

• в какое время покупают коктейли;
• во что одеты клиенты;
• были ли они по одиночке;
• покупали ли что-то кроме него;
• выпивали ли коктейль в ресторане или брали с собой.

Оказалось, что почти половину всех проданных коктейлей продавали до 8 утра. Покупатели приходили по одному и не брали ничего, кроме коктейля. Они брали его в машину и уезжали. Чтобы разузнать, ради какой работы они нанимают коктейли, на следующий день мы встали у выхода, и встречали людей с коктейлем в руке. Мы спрашивали их: «Извините, мне нужно разгадать загадку. Что за работа привела вас сюда и заставила нанять этот коктейль?» Они не знали, как ответить, и мы задавали им наводящий вопрос: «Вспомните прошлый раз, когда вы были в такой же ситуации, и та же самая работа должна была быть проделана, но вы не взяли коктейль. Что вы тогда взяли?»

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

«Хороший вопрос, что бы я нанял для этой работы, никогда не задумывался раньше. В прошлую пятницу я нанял бананы. Советую никогда не нанимать бананы. Съедаешь их за три минуты, и чувствуешь голод уже к 7:30. Если пообещаете не рассказывать жене, где-то пару раз в неделю я беру пончики. Но это неудобно. Съедаешь их быстро, пачкаешься кремом, пальцы липкие. Иногда я нанимаю булки, но они сухие и безвкусные. Приходится держать руль коленями, пока я намазываю булку джемом, и, если зазвонит телефон, это катастрофа! Однажды я нанял сникерс, но почувствовал себя таким виноватым, что больше не буду нанимать сникерс. Позвольте рассказать, почему я нанял коктейль. Он такой густой, что нужно минут двадцать, чтобы выпить его через трубочку. И кого в этом случает волнуют ингредиенты? Меня нет. Всё, что меня волнует, что я сыт всё утро, а стакан прекрасно ложится в мою руку».

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

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

Что сделали с молочными коктейлями

В этом видео Клейтон Кристенсен почему-то умалчивает о том, что они в результате предложили сделать. Информацию об этом можно найти в книге «Стратегия жизни». Он предлагает сделать коктейль гуще, а процесс покупки коктейлей вынести из помещения на улицу, сделать оплату быстрее.

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

Если бы они не изучили работу, которая должна быть проделана, а сделали бы коктейль для какой-нибудь условной средней группы, то ни одна работа не выполнялась бы.

Просмотров за последний месяц: 38,612

Jobs-To-Be-Done: как описать свою аудиторию

Разбор крутого метода описания аудитории Jobs-To-Be-Done (JTBD) от преподавателя нашей школы, маркетолога и директора по продажам и маркетингу FMCG – Сергея Молчанова.

Мнение основателя школы TargetGirl Анны Зайцевой не совпадает с мнением автора. Почему? JTBD – вовсе не лучшая альтернатива описанию профиля клиента: они ДОПОЛНЯЮТ друг друга. Ведь при выборе товара, у которого есть множество аналогов (жевательная резинка) мы выбираем не только исходя из решаемой задачи, но и из эмоциональной «окраски» бренда.

Впрочем, решайте сами – после прочтения статьи. Позже Анна напишет, как искать инсайты и расскажет, почему в одиночку Jobs-To-Be-Done в поле не воин.

 

Jobs-To-Be-Done

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

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

Концепция Jobs-To-Be-Done (далее JTBD) разработана и описана профессором Гарварда К. Кристенсеном. Чем она отличается от стандартного и привычного нам описания профилей потребителей?

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

Пример номер раз: вот Сергей, ему 38, он работает в средней компании, он сотрудник финотдела и зарабатывает очень хорошо. Его интересы – сноуборд, кино, детективы Л.Чайлда. Серёжа два раза в неделю ходит в спортзал и один раз на рукопашный бой. Он женат, два сына и у них дома есть кошка.

Очень понятный профиль клиента и знакомый многим. Даже описаны не только соц-дем параметры, но и интересы.

Пример номер два: вот Настя, ей 27. Замужем за руководителем среднего звена в госкорпорации и может себе позволить не работать. Посещает 4 раза в неделю спортзал, три раза в месяц салон красоты, обедает исключительно в ресторане. Имеет смартфон последней модели с крутой камерой. Любит эко продукты, йогу и воздерживается от мяса.

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

Пример номер три: Мужчина или женщина, от 23 до 44, в браке или в разводе, с 1 или 2 детьми, имеющие автомобиль или два, интересующиеся спортом и здоровым питанием…

Узнаете в этом тексте 95% формулировок, описывающих целевой сегмент аудитории?

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

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

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

Как использовать эту концепцию? Запоминайте 3 вещи:

 

1. Сам фреймворк (шпаргалка) для описания

Когда <клиентская ситуация> я хочу сделать <клиентская задача> чтобы <конечная цель клиента>

Пример: КОГДА у меня есть всего 5 минут, чтобы перекусить между переговорами, Я ХОЧУ съесть что-то простое и быстро, так чтоб это утолило голод, ТОГДА Я смогу продержаться до обеда и провести все встречи.

 

2. Возможный, но не лучший способ описания JTBD

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

 

3. Способ лучше – найти JTBD основываясь на данных по продажам или количественных исследованиях

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

 

Подведем итог. Чем хорош JTBD?

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

Отсюда вытекает второй плюс – JTBD можно найти через анализ данных. Через цифры уже имеющихся продаж или исследование. Когда мы работаем с оцифрованными данными, не остается места для иллюзий.

Понравилась концепция? Уже используете? Может потренируемся в комментариях? Пишите целевой сегмент своих клиентов через фреймворк JTBD. Проверим, везде ли применим такой подход или где-то надо по старинке.

 

Сергея Молчанов, преподаватель TargetGirl, маркетолог, директор по продажам и маркетингу FMCG

 

Jobs to be Done или всё о желаниях пользователей

1. Jobs to be Done – что это вообще такое
2. Зачем нам Jobs to be Done
3. Кому Jobs to be Done может помочь   
4. Две интерпретации Jobs to be Done – ставим точки над “i”
5. Чуть глубже в Jobs-As-Progress
6. Звучит круто, а как это применять на практике?

Представьте, что вы продаете фотоаппарат, который тут же проявляет и печатает снимки. Вы знаете, что ваш клиент — Настя, ей 27 лет, она учится в институте культуры и активно ведет Instagram. У вас на руках вполне себе подробное описание персоны, но какой из этих фактов повлиял на покупку фотоаппарата? Никакой. Но вы продавали этот фотик примерно всем, кто похож на Настю. А что если продажи начали падать или вы решили создать новый продукт? Как в этом случае понять, кто ваша целевая аудитория и зачем им покупать у вас? Решение кроется в теории Jobs to be Done. 

Jobs to be Done – что это вообще такое

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

Смысл теории в том, что люди не покупают продукты, а “нанимают” их для выполнения определенных задач. 

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

Теория “работ” предполагает, что глобальная цель каждого человека —  стать лучше, и продукт должен помочь в этом.

Подход отличается от Cusdev’а или создания персон. Вместо того, чтобы придумывать собирательный образ целевой аудитории и выяснять, как пользователь использует продукт, теория “работ” помогает исследовать пользовательские инсайты и трудности. 

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

С помощью теории “Работ”, мы можем узнать, что движет людьми в момент принятия решения о покупке, а значит у нас есть возможность создавать такие продукты, которые будут лучше отвечать на внутренние запросы клиентов. 

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

Зачем нам Jobs to be Done

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

Нужно изучить JTBD, если вы хотите: 

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

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

Кому Jobs to be Done может помочь   

Всем. 

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

Теория “работ” может помочь в разработке подрывных инноваций. Если продуктологи знают, какие “работы” есть у пользователей, значит они понимают, какой продукт им необходим. 

Скачать чек-лист:

Материалы по Jobs to be Done

Спасибо! Мы уже отправили всё на почту

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

Две интерпретации Jobs to be Done – ставим точки над “i”

Существуют две интерпретации JTBD, и у них принципиально разные взгляды к определению “работ”. Если вы действительно хотите связать свою жизнь с JTBD, вам следует знать, кому из последователей поклоняться 🙏 

Две версии Jobs to be Done: 

• Jobs-As-Progress (Работа как прогресс): Теорию разработали Клэйтон Кристенсен, Боб Моэста, Алан Клемент и др. 
• Jobs-As-Activities (Работа как процесс): Теорию разработал Энтони Ульвик. 

Но перед тем как перейти к разбору интерпретаций, давайте посмотрим на схему ниже.

На этой схеме изображена мотивационная иерархия Уильяма Пауэрса, автора теории перцептивного контроля: отношение между тем, к чему мы стремимся, и тем, что нам необходимо для этого сделать. То есть если я хочу быть вегетарианцем, потому что я зоозащитник и экоактивист, мне нужно приготовить себе вегетарианский ужин, а для этого мне нужно замочить хумус на целых 10 часов! В этой иерархии моей главной целью будет “Быть вегетарианцем” – это Be goal, задачей — “Приготовить вегетарианский ужин” (это Do goal), а действием — “Замочить нут”, и это Motor control goal. 

Теперь мы знаем, какие виды задач у нас есть и какой приоритет у каждой из них, но как они влияют друг на друга и какая зависимость между ними?

Если я не стану замачивать нут (ну камон, это же очень долго!), а просто почищу авокадо и отрежу себе кусок хлеба, это всё равно будет считаться за ужин, то есть действие не выполнено, а задача все равно достигнута. А если я не стану готовить ужин и пойду есть в вегетарианский ресторан, я не перестану быть вегетарианцем. То есть Be goals имеют наивысшую степень приоритетности и не всегда зависят от Do goals и Motor control goals. 

А теперь посмотрим на это с другой стороны: ваша главная цель — всё еще быть вегетарианцем, задача – сходить в вегетарианский ресторан, а подзадача – сесть в такси, дойти до ресторана и т.д. Вы садитесь в такси, приезжаете в ресторан, заказываете еду, съедаете её, а потом узнаете, что там была приправа из свинины, ведь вы в Китае, а тут без этого никак. Вы выполнили все необходимые задачи, но большая цель не была достигнута. 

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

Jobs-As-Activities Ульвика

Теорию разработал Энтони Ульвик

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

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

Концепция Ульвика предполагает, что пользователи хотят совершать действия и задачи. Он использует такие примеры “работ”, как “слушать музыку”, “просверлить дыру в стене”, “загрузить музыку”, “срубить дерево”. Задачи стоят во главе всего анализа. Любые эмоциональные соображения вторичны по отношению к функциональной работе:

“Эмоциональные работы определяют, как пользователь хочет себя чувствовать в результате выполнения основных функциональных работ. Социальные работы определяют, как пользователь хочет быть воспринят другими”

В интерпретации Ульвика, мы нанимаем продукт на работу, чтобы с его помощью выполнять задачи. А теперь вспоминаем схему с мотивационной иерархией. В ней задачи (Do goals) и действия (Motor control goals) имеют самый низкий приоритет и не всегда влияют на достижение глобальной цели “Стать лучше”.

Jobs-As-Progress Кристенсена

Теорию разработали Клэйтон Кристенсен, Боб Моэста, Алан Клемент и др. 

Все остальные (Кристенсен, Моэста, Клемент) считают, что человек нанимает продукт на работу, чтобы стать лучше. Я покупаю дрель не потому, что хочу просверлить дырку и не потому, что мне нужна дыра в стене. Я хочу красивый дом.

Кролик хочет не просто морковку, он хочет суперсилу, чтобы обогнать черепашку.

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

Когда Apple продавали iPod, он бил рекорды продаж, но компания решила выпустить на рынок новый продукт, который впоследствии убил бы плеер. Этим продуктом был iPhone и он действительно обвалил продажи iPod, но так Apple предугадала истинную потребность пользователей в одном девайсе и продлила себе рост. 

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

Модель Jobs-As-Progress предполагает, что пользователь ищет, покупает и использует продукт впервые, когда существуют расхождения между тем, как дела обстоят сегодня, и тем, какими мы хотим их видеть в будущем. Работа как прогресс – это про желание пользователя использовать рынок с целью разрешения “Be goal” расхождений. 

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

Итак, теперь вы знаете про две интерпретации теории и можете сами выбирать, на чью сторону встать. Оба подхода пытаются определить, что движет пользователями, когда они приобретают товары или услуги. Но Jobs-As-Activities видит работы как задачи, а Jobs-As-Progress — как прогресс. 

Нам больше нравится интерпретация Кристенсена, и мы хотим подробнее рассказать про Jobs-As-Progress. 

Чуть глубже в Jobs-As-Progress

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

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

Эта модель похожа на химическую реакцию: в результате соединения нескольких элементов совершается “магия” и создается что-то абсолютно новое. В нашем случае это работа, которую нужно выполнить. 

Начнем с первой части – синтеза JTBD. Синтез происходит, когда желания, ограничения, катализаторы (событие, которое вызывает желание) и набор решений соединяются вместе. Что значит энергия? Это настрой пользователя, когда он решается выйти из зоны комфорта и понять, что ему необходимо для осуществления прогресса. Так появляется Jobs to be Done.

После того как у пользователя сформулирована работа, он переходит к шагу “оценка выбора”. На этом этапе ему предстоит определить, какой из вариантов нанять на работу: 

1. Шопинг: пользователь начинает собирать информацию, искать что-то и выбирать в поисках лучшего решения работы. Шопингом может быть регистрация в триале или просто поиск в гугле по запросу “лучшая СRM”.
2. Переосмысление: чтобы стать лучше, пользователь нанимает на работу решения, которые когда-то уже пробовал раньше. Это как снова выпить валерьянки, чтобы успокоиться и уснуть. Если в процессе переосмысления пользователю не удалось достичь своей цели, он идет шопиться. 
3. Оценка компромисса: пользователь оценивает, от чего он готов отказаться ради нового решения и сколько готов потратить сил, денег, времени, усилий и т. д. 

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

Теперь вы знаете, как устроен круговорот принятия решения, и у вас есть возможность измерять, оценивать и предсказывать работы. 

Звучит круто, а как это применять на практике?

Дмитрий Капаев, сооснователь агенства USEFUL, которое проводит исследования пользователей по теории “работ”, в своем интервью рассказывает: “JTBD — это не фреймворк и не инструмент, это в первую очередь теория, которая помогает под правильным углом посмотреть на то, как люди принимают решения. В данном случае идет речь о том, как люди выбирают и в дальнейшем используют продукт, услугу или сервис. 

Теория “работ” не заменяет никаких существующих подходов и рабочих процессов. Если у вас в компании выстроены свои процессы, вы используете Customer Development, Lean, Hadi-циклы, CJM-карты — это все отлично дополняет саму теорию. 

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

Итак, мы знаем, зачем нам JTBD, слышали про две интерпретации, поняли, какая нам больше всего нравится, увидели модель работ и уже срочно хотим начать узнавать пользовательские инсайты и делать крутые продукты, но как?

Это была первая часть большого материала, посвященного JTBD. Во второй главе рассказываем, как применять теорию на практике. А пока скачивайте наш гайд, в котором мы собрали полезные материалы по теории “работ”. Гайд поможет еще больше углубиться в тему Jobs to be Done: здесь вы найдете ссылки на вебинары, кейсы, статьи и пару книг. 

Оставайтесь на связи!

Материал был подготовлен на основе вольной адаптации и перевода книги Алана Клемента “When coffee & kale compete?” 

Автор: Александра Каменских

Знакомлю читателей блога Carrot quest с лучшими зарубежными материалами.

Подключите Carrot quest

Первые 14 дней бесплатно

Присоединяйтесь к нам в соцсетях и мессенджерах

Тут рассказываем кейсы и хаки, которые не попадают в блог

Jobs to be done. Что за подход и какие задачи решает?

Что такое jobs to be done? Какие задачи можно решить с помощью этого инструмента? Чем он отличается от user story?

Странное дело получается, я уже давно написал про такой инструмент, как user story, а про jobs to be done совсем забыл вам рассказать. Вернулся к этой теме не просто так. Данный подход набирает популярность в профессиональной тусовке продактов и UX/UI спецов, поэтому ему нужно уделить особое внимание.

Jobs to be done: это

Jobs to be done (JTBD) – это подход к созданию и проектированию digital продуктов через задачи пользователей. В основе концепции лежит мысль о том, что пользователь “нанимает” наш продукт, чтобы решить свою задачу.

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

Пример

Представьте себе ситуацию: вы стоите в пробке, понимаете, что ехать еще очень долго и думаете о том, чем бы себя занять. Как раз “чем бы себя занять” и есть задача, которую вытаскивает jobs to be done.

Дальше вы думаете как ее решить. Музыка, телефон, насвистывание песенки, что-то еще? Вытащив задачу, мы можем создать или адаптировать под нее продукт.

Например, ваш продукт – мессенджер. Существенная доля пользователей водит автомобиль и подолгу стоит в пробке. Они переписываются со своими родными и близкими через приложение. Но в движении, это не очень удобно. Мы понимаем контекст и выдвигаем гипотезы:

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

Какие решения можно предложить:

• голосовой ввод сообщения
• отдельный режим интерфейса для водителей с крупными кнопками

Теперь у вас есть идеи на развитие, которые можно проверить. Проверяете, получаете положительный результат, применяете на весь продукт. Если результат отрицательный, достаете новые гипотезы. И так далее.

_

Простите, что прерываю чтение. Присоединяйтесь к моему telegram каналу. Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…

_

Jobs to be done: как создавать

В основе jobs to be done лежат исследования. Вам потребуется “выйти” к своим пользователям из офиса. Провести интервью и вытащить ситуации, в которых используется продукт. После этого необходимо будет проверить масштаб таких ситуаций. Вы проводите массовый опрос и понимаете размер сегмента пользователей со схожей задачей.

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

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

Jobs to be done: какие еще задачи решает

Помимо источника идей для создания новых и развития существующих продуктов, jobs to be done закрывает и другие задачи:

• мотивация
• конкуренты
• фокусировка

Про каждый расскажу подробнее.

Мотивация

У вас есть команда, которая работает над продуктом. Вы планируете стратегию развития, строите roadmap и с каждым следующим релизом выпускаете новый функционал. Все бы ничего, но где здесь про пользователя? То есть, вы права думаете, что вот прямо так экспертным путем, сидя в кабинете, вы нагенерите крутых идей? А завтра продукт улетит в топы сторов?

Нет. Чтобы делать для людей, нужно людей понимать. Jobs to be done – это про исследование реальных пользователей с реальным контекстом и реальными задачами. Понимая, что движет человеком в той или иной ситуации, мы синхронизируемся с ним. Мы чувствуем его и знаем “где болит”. А значит можем предложить для него лучшее решение.

Конкуренты

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

Если наш продукт стиральные машины, которые решают задачу “уход за бельем”, то и конкурентов можно разложить на три уровня:

• прямые – бренды других стиральных машин
• вторичные – отпариватели для белья
• косвенные – химчистки

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

Фокусировка

Jobs to be done помогает сфокусироваться на задаче пользователя. Когда вы смотрите на свой backlog через эти задачи, то можете легко расставить приоритеты. Эту доработку мы сделаем в первую очередь, потому что она окажет наибольшее влияние на нашего пользователя. Она лучше остальных решает его задачу.

У вас появляется фильтр, который направляет все ваши усилия в нужное русло.

Jobs to be done и user story

Слышал часто от знакомых, что мол user story это прошлый век, сейчас все jobs to be done используют. Мол эффективнее, круче, современнее. По факту, для меня оба инструмента полезны. Каждый обладает своими особенностями и нюансами. А говорить, что берите только этот или этот, я не возьмусь. Чтобы было проще понять основные отличия, нарисовал такую табличку.

Коротко по таблице:

• И user story и JTBD работают с контекстом пользователя. Но у второго его гораздо больше.
• Оба инструмента про задачу пользователя.
• User story хорошо работает, когда мы точно знаем свою целевую аудиторию.
• JTBD наоборот помогает ее найти через задачи.

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

Итого

Jos to be done отличный инструмент для создания и развития вашего продукта. Как мы разобрали выше, он закрывает кучу задач и может быть полезен в различных ситуациях. Не бойтесь погружаться в контекст, не бойтесь понимать своего пользователя, ведь именно он подскажет вам куда развивать продукт.

Алексей А.

---

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

---

Великолепная реклама от Александра Гудкова и рекламного агентства Nectarin. Зашли через офисные образы и проблему недостатка витаминов. Браво!

Вконтакте

Facebook

Twitter

Google+

Загрузка…

Intercom про Jobs-to-be-Done. Часть 3, заключительная / Mail.ru Group corporate blog / Habr

Заключительная часть о том, как концепция Jobs-to-be-Done меняет принципы создания и улучшения IT-продукта. Третья часть перевода книги «Intercom про Jobs-to-be-Done». Главы с седьмой по девятую.

Первая часть
Вторая часть

Глава 7. Отказываясь от персон: история о Job stories

Автор: Paul Adams

Мы в Intercom постоянно переосмысливаем внутренние процессы, чтобы создать выдающийся продукт. Поэтому задаемся вопросом: как выстроить процесс создания продукта, чтобы люди считали его ценным и удобным, а также любили его. Основное внимание мы акцентировали на исследованиях, для чего нанимали людей, обладающих исследовательским опытом. При этом каждый член продуктовой команды лично общается с клиентами: менеджеры продукта, дизайнеры и конечно исследователи. Мы также наняли директора по исследованиям, и сделали это намного раньше, чем делают большинство других стартапов. Им стал Sian Townsend, глава команды исследований Google Maps.

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

Мы были большими фанатами Jobs-to-be-Done, но все написанное было применено в основном к молочным коктейлям и шоколадным батончикам. Существовало только одно небольшое исследование, касающееся использования Jobs-to-be-Done для разработки ПО. Так мы создали наш собственный процесс на основе того, что уже знали.

Большую часть моей карьеры я использовал персоны и сценарии, чтобы понимать клиентов. Эти инструменты, популяризованные Аланом Купером в книге «Психбольница в руках пациентов», стали одними из самых широко используемых исследователями и дизайнерами. Алан Купер также написал невероятную книгу «Об интерфейсе», которую я рекомендую всем дизайнерам, присоединяющимся к нашей команде. Но прошу их пропустить раздел о персонах.

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

И мы в Intercom больше никогда не использовали персоны.

Ценность персон я впервые поставил под сомнение, когда перешел из Google в Facebook. Там накопили невероятный объём информации о том, как самом деле пользователи взаимодействуют с их продуктом. А общение с дата-саентистами не переставало учить новому.

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

К примеру, мотивы у матери троих детей из США, публикующей фотографии с семейного пикника, в основном такие же, как у корейского подростка, постящего фотки с вчерашней вписки. Цели и детали могут быть абсолютно разными, но мотивация одна. Персоны никогда не приведут к созданию одного и того же продукта для совершенно разных аудиторий. Лучшие в своём роде персоны фокусируются на достижениях, «что движет поведением людей», и на атрибутах. Но на практике большинство персон фокусируются только на атрибутах.

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

Проектирование от мотивации намного лучше проектирования от атрибутов. Это ключевое различие персон от Jobs-to-be-Done. Персоны — про роли и атрибуты, а Jobs-to-be-Done — про ситуации и мотивации. Персоны объясняют, что это за люди, какие они и что делают, но никогда полностью не объясняют, почему люди делают что-либо, хотя это намного важнее.

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

1. Люди разбираются в своих проблемах, но не в решении. При этом для них более естественно предложить решение в виде запроса на разработку фичи. Описать предлагаемое решение намного легче, чем проблему. Из-за этого приходится возвращаться к клиентам, чтобы задать вопросы и по-настоящему понять их проблему.
   
2. Отвечая, люди первоначально рассказывают о том, что хотят, на языке атрибутов, но не называют причину, почему это важно для них. Поэтому вам приходится продолжать копать вглубь понимания их мотивации. Главное понять, какую проблему клиенты на самом деле пытаются решить и почему нуждаются в её решении.
   

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

Кроме персон существует другой популярный инструмент — User stories, продвигаемый Agile-сообществом. Мы никогда не использовали User stories, потому что эмпирически они не кажутся обусловленными исследованиями. Они инженерные, и уж точно не обусловлены клиентом. Они созданы для того, чтобы описывать функциональность, а не мотивацию, которой люди обладают.

После размышлений над этой проблемой и отталкиваясь от первых принципов, мы изобрели Job stories. Тогда этот артефакт не имел названия. А позже Alan Klement придумал название для нас. Но процесс был готов и прекрасно нам подходил. Мы впервые опробовали Job stories, сокрушаясь в посте блога о «дриббблизации» дизайна. Мы долго и упорно думали о Jobs-to-be-Done, и это вылилось в создание нашего собственного процесса, сфокусированного на ситуациях, мотивациях и результатах:

[Когда ______] [я хочу ______] [то могу ______]

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

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

Перед тем, как начать любой проект, мы в Intercom создаём очень простой одностраничный бриф, который можно скачать. Он очень простой и должен занимать 1 страницу А4. Он включает раздел Job stories, помогающий нам не забывать о проблеме и возможностях, за которые беремся, а также дает возможность быть сфокусированными на протяжении всего проекта.

Персоны определённо имеют место быть. Я считаю их полезными для получения поддержки в политической игре, когда люди только на словах решают реальные потребности клиентов. Персоны также могут создать более сильные связи с текущими пользователями продукта. Но сделать их хорошо — трудоёмкий процесс. Персоны зациклены на различиях между людьми и сложны для запоминания и отсылки к ним. Оказывается, многие люди с различающимися атрибутами имеют очень схожую мотивацию. Её легко понять, как и то, что все, что вы пытаетесь запилить, можно объяснить в серии коротких запоминающихся предложений. Если это не убеждает вас, то вспомните, что персоны искусственно уменьшают размер рынка вашего продукта. Вот почему мы топим за Job stories.

Глава 8. Дизайн фичей с помощью Job stories

Автор: Alan Klement

Когда Дес попросил меня написать для блога «Внутри Intercom», я просто презентовал Jobs-to-be-Done моим партнёрам из Aim, рекламного маркетплейса для недвижимости.

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

А потом меня осенило. Без какой-либо отсылки к Jobs-to-be-Done я стал обращать внимание на наиболее успешные предложения, сделанные кофаундерами. Я рассказал о том, с чем наши клиенты мучаются, и описал, насколько их жизнь будет лучше, когда мы это исправим. Затем показал, чем их предложения хороши для конкретной дизайнерской задачи. В результате я описал работу, которую необходимо выполнить клиенту, и результат, когда работа сделана.

Используя язык Jobs-to-be-Done для коммуникаций, мы смогли утвердить наш первый дизайн всего за несколько минут. Назад пути уже не было.

***

Персоны и User stories имеют место быть, когда клиенты и продуктовые команды очень далеки друг от друга. Но это больше не проблема.

Традиционно ответ на вопросы «Кто является нашим клиентом?» и «Что клиентам нужно?» лежит на маркетинге, бизнес-департаменте или даже на отделе продаж. Когда информация собрана, её следует сформировать в понятный всем формат, а затем забросить в команду продуктовой разработки.

Во время этого водопадного процесса приносятся в жертву нюансы, необходимые для создания хороших продуктов: причины, тревоги и мотивации. Jobs-to-be-Done — это философия фокусирования на этих нюансах. Чтобы донести эту концепцию до конечного продукта, во время дизайна фичей, UI и UX следует использовать Job stories.

Провал персон

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

Провал User stories

«Я как пользователь могу пометить папки так, чтобы они не бэкапились, поэтому мой резервный диск не будет заполнен тем, что не нужно». У этой User story три большие проблемы:

1. Используются персоны.
   
2. Реализация объединяет мотивацию и ожидания.
   
3. Игнорируется контекст, обстановка и страхи.

Фичи часто не удаются. Если фича была определена с помощью User story, понять, почему она провалилась, будет непросто. Так случается, когда в решении были объединены мотивация и ожидания. Из-за этого объединения невозможно понять, что именно было ошибочным — проблема в реализации или в предположении о мотивации.

Введение в Job stories

Job stories, впервые упомянутые Полом Адамсом в блоге Intercom-а и разработанные здесь, — это совершенно другой подход к разработке фичей. Но как командам внедрить их в свой рабочий процесс?

Вот один из подходов:

1. Начинаем с высокоуровневой работы.
   
2. Определяем более мелкие работы, помогающие выполнять высокоуровневую работу.
   
3. Наблюдаем, как люди решают проблему сейчас. Это работа, которую они выполняют.
   
4. Используем Job story для определения причинно-следственных связей, тревог и мотивации того, что люди делают сейчас.
   
5. Создаём решение, которое решает эту Job story.
   

Для примера рассмотрим процесс проектирования продуктовой командой профиля продавца в рамках продукта, помогающего продавцам автомобилей оформить клиентам кредит.

Дизайн профиля

На раннем этапе создания дизайна команда обсуждает, как должен выглядеть профиль пользователя и какими фичами он должен быть наполнен. Для начала Сара, член команды, встаёт и рисует простой макет на доске. Указывая на него, она говорит: «Это профиль продавца».

Команда не впечатлена её решением. Задаётся серия вопросов «почему» про каждую часть макета. Даже после всех этих вопросов команда не принимает и не отвергает эту идею. Вот эти вопросы: «Зачем продукту этот профиль?», «Почему профиль должен находиться здесь, а не в другом месте?», «Какую информацию он должен показывать?», «В каких ситуациях он полезен?», «Какую работу выполняет этот профиль?»

Чтобы ответить на эти вопросы, описание фичи было переоформлено с помощью Job story.

Начинаем с высокоуровневой работы

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

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

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

Используем Job story, чтобы определить причинно-следственные связи, тревоги и мотивации того, что люди делают сейчас:

1. Когда продавцы машин и их клиенты взаимодействуют посредством продукта…
   
2. … клиенты хотят доверять компании, процессу и продавцу.
   
3. Продавцы хотят быть уверенными, что процесс комфортный для клиента…
   
4. …и он может в безопасности вводить свою финансовую информацию.
   

Это написано на языке Job story. Можно конкретизировать, добавив больше ситуационного контекста: когда и где всё это заполняется, дома или в дилерском центре. А также страхи каждой из сторон, связанные с профилем и его заполнением.

Создаём решение, которое выполняет эту Job story

Команда решает, какой дизайн у профиля должен быть, чтобы клиент выполнил свою работу. Отображение слишком малого объёма информации в профиле не решит изначальную работу, а большой её массив может привести к негативным последствиям. В итоге команда решает:

1. Во время использования продукта профиль продавца будет постоянно виден на экране, чтобы покупатель не испытывал страха по поводу того, что находится не рядом с продавцом.
   
2. В профиле должна быть фотография продавца, его должность, количество проданных автомобилей и стаж работы в компании, чтобы не возникало сомнений в надежности продавца и его опыте.
   
3. В профиле должны быть указаны способы связи с продавцом: номер телефона, e-mail и кнопка «задайте вопрос», чтобы клиент не опасался, что может заполнить форму неправильно.
   

Вот пример решения:

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

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

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

Абстрактные атрибуты, объединение реализации с мотивацией и ожиданиями сводит команды с ума. Если команда копает глубоко и изучает работу клиента, то создает решения более эффективно. Job stories лучше всего подходят для дизайна продукта.

Глава 9. Спрашивать «почему» — правильно

Автор: Dan Ritzenthaler

Пока я не проникся Jobs-to-be-Done, то с трудом определял корневую проблему так, чтобы она сводилась к простому утверждению. Как я могу просто и ясно выразить её перед членами команды? Нужно рассматривать проблему под разными углами для лучшего её понимания. И задавать вопрос «Почему?» — один из лучших способов погрузиться глубже в то, что клиенты пытаются сделать.

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

***

Я не смогу перестать задавать вопрос «почему?» на каждое ваше заявление, а затем… я опять спрошу «почему?». Это профессиональная деформация.

Вот, к примеру, вы купили электродрель. Почему? Да потому что хотите повесить пару фотографий в рамке. А почему вы хотите повесить фотографии? Наверное, чтобы сделать свой дом более обжитым. А почему это важно для вас?

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

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

Продуктивные уровни разговора

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

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

1. Во-первых, уровень пользы: что вы непосредственно делаете с вещью? Я использую дрель, чтобы сверлить дырки.
   
2. Во-вторых, уровень удобства: какой результат вы получаете? Я сделал дырки, чтобы повесить фотографии.
   
3. В-третьих, уровень желаний: что изменилось, когда я завершил мою работу? Я повесил фотографии и теперь у меня более обжитой дом.
   

Сказанное вне этих трёх уровней трудно отнести к продукту. К примеру, спрашивая: «Почему вы хотите более обжитой дом?», вы вряд ли получите важные для производителей дрелей ответы.

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

Уровень пользы

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

Где должны быть просверлены дырки? В бетоне? В дереве? В металле? Какого размера они должны быть: это должны быть узенькие дырочки для маленьких винтиков или широкие дыры для больших болтов?

Каким образом это может поменять свойства дрели? Другая мощность, крутящий момент, скорость? Может, выбор скоростей? Или разные размеры дрели? А, быть может, наличие съёмных свёрел?

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

Уровень удобства

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

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

Как это поменяло бы свойства дрели? Может, понадобились бы маленькие батарейки, так как она не часто используется? Или, возможно, нужен меньший мотор и корпус для снижения веса? Должно ли быть больше предустановок для домашних стен, чтобы уменьшить тревожность?

Эти вопросы раскрывают возможности дрели и способы сделать её более удобной. Но, к сожалению, они не раскрывают методов сделать дрель более привлекательной.

Уровень желания

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

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

Как это меняет свойства дрели? Нужна ли док-станция, чтобы было легко убрать её? Или она должна висеть на стене, чтобы быть всегда наготове? Должна ли дрель иметь привлекательный внешний вид, когда лежит на столе или на полке?

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

Не торопитесь

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

Заключение

Изначально мы в Intercom сделали большую ставку на Jobs-to-be-Done как на средство информирования о нашей продуктовой стратегии. А позже использовали его для выхода на рынок. Пять лет спустя эта концепция всё ещё находится в основе нашей продуктовой и маркетинговой стратегии. Мы построили всю компанию вокруг идеи, заключающейся в том, что люди сталкиваются с проблемами в жизни или работе, а для их решения покупают продукты.

Я не знаю ни одного направления нашего бизнеса, которое не изменил бы Jobs-to-be-Done. Продукт, маркетинг, продажи и поддержка сильно выиграли от концентрации на этой концепции. Изначально мы принимали решения на основе интуиции о разных причинах, по которым люди должны купить Intercom, но примерно через год провели исчерпывающее исследование о работах наших клиентов.

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

Наше единение с Jobs-to-be-Done всё ещё эволюционирует. Данная книга — это начало, коллекция лучших на данный момент наших размышлений над теорией. С ростом нашей компании и расширением потребностей клиентов, мышление тоже развивается. В течение пяти лет мы бы хотели написать несколько книг, в которых будут содержаться советы и мнения.

Если у вас имеется похожий опыт использования стратегий из книги, я был бы счастлив узнать об этом. Напишите мне на [email protected]

Спасибо, что прочитали.