Вторая часть перевода книги Intercom про Jobs-to-be-Done — это продолжение повествования о том, как концепция Jobs-to-be-Done меняет принципы создания и улучшения IT-продукта. Главы с третьей по шестую.
Глава 3. Больше чем матрасы: исследование пользователей программного обеспечения по принципам Jobs-to-be-Done
Автор: Emma Meehan
Когда я начала работать исследователем продукта в 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 определила четыре силы, отталкивающие и притягивающие к покупке. В нашем «матрасном» сценарии присутствуют следующие:
- Отторжение: «Этот матрас настолько некомфортный, что я несколько раз за ночь просыпался с болью в спине».
- Втягивание в новое решение: «Если я возьму новый матрас, то смогу выспаться, следовательно буду лучше чувствовать себя дома и на работе».
- Беспокойство: «Что если новый матрас будет не лучше старого? Я могу его попробовать только пару минут в магазине».
- Привязанность к текущему решению: «Я спал на этом матрасе ещё когда учился в институте».
Решение о покупке ПО может быть обусловлено как бизнес-целями, такими как увеличение вовлечения или выручки, так и личными целями, например, повышение уровня счастья. Однако хорошо спроектированный софт удовлетворяет все потребности. Вы можете поспорить, что на решение о приобретении ПО большее влияние могут оказать предыдущие покупки, чем привлекательность рассматриваемого инструмента. В случае с ПО четыре силы действуют так:
- Отторжение: «Мы получаем конверсию ниже, чем необходимо. Мы не можем позволить себе платить так много».
- Втягивание в новое решение: «Если мы переключимся на новый инструмент, обладающий бóльшим набором функций для повышения конверсии, то сможем достичь наших целей».
- Беспокойство: «Что если новый инструмент не сможет быть интегрирован, как надо? Ранее мы уже пробовали три тулзы, но ни одна не подошла».
- Привязанность к текущему решению: «У нас настроены рабочие процессы и интеграция, поэтому не хотелось бы делать это заново».
Создание модели принятия решения
Модель принятия решения описывает временной интервал, в течение которого человек или компания изучает все возможные решения, которые могут предоставить продукты для выполнения работы. Можно выделить активный и пассивный поиск. Активный поиск обычно начинается после разочарования в продукте. Пассивный поиск может занять недели или месяцы — до тех пор, пока пользователь не будет уверен в том, что продукт его полностью устраивает.
В случае с разработкой ПО, задавая вопросы на основе модели принятия решения, можно вскрыть ситуации, когда люди многократно принимали решение о покупке.
- Когда вы поняли, что хотите приобрести новое решение? Достаточно ли глубоко исследовали этот вопрос перед тем как прийти к выводу, что решение подходит для вашей компании?
- Когда вы впервые услышали о выбранном вами инструменте?
- Можете ли вспомнить, каким образом вы пришли к покупке этого специфического инструмента?
- Пробовали ли вы другие инструменты во время поиска? Если да, то какие?
- Как долго вы не могли решиться нажать кнопку «купить» на сайте продукта?
Таймлайн
Построение таймлайна событий помогает провести клиента по всем этапам покупки. Мы узнали, что в случае с приобретением ПО обычно существуют множественные таймлайны.
Ранее мы проводили интервью чтобы понять, почему компании переключаются с инструмента А на инструмент Б. А завершали его с двумя таймлайнами. Первый таймлайн о том, почему компания переключилась с инструмента А на инструмент Б, второй — почему перешли с Б на Г.
Повторю, что в принятии решения о покупке софта участвует множество людей. Но вам необходимо найти того, от кого зависит большая часть решения. Часто можно услышать: «Я не работал в компании, когда покупали ПО, но я больше всех пользуюсь этим решением!»
«Я не работал в компании, когда они перешли на инструмент А».
Это как брать интервью у родителя, купившего матрас для своего ребёнка. Полезно разговаривать с ребёнком, чтобы он рассказал, насколько хорош матрас, но на самом деле вы хотите выяснить у его родителя, почему он купил матрас именно в этом магазине.
Если говорить о покупке ПО, то главную фигуру в принятии решения можно раскрыть, задав следующие вопросы:
- Что вы сделали для того, чтобы компания перешла к этому продукту? Какое влияние оказали?
- Кто принимал решение о переходе? Эти люди ещё работают в компании? Какие у них роли?
Знание всех действующих лиц, принимавших решение, создаёт более полную картину для понимания, где и какие изменения следует внести и как заточить продукт под работу, для выполнения которой выбирают решение.
Больше, чем матрасы
Jobs-to-be-Done может быть отличным инструментом, помогающим понять, почему компании «нанимают» и «увольняют» продукт, а также определить направления для внедрения инноваций. Но помните: что подходит для физических продуктов, нельзя напрямую использовать для софта. Покупка ПО многомерна, в ней участвует несколько закупщиков с разными сроками принятия решения. Адаптируя техники интервью под ваши нужды, вы получите фреймворк, подходящий для любой современной софтверной компании.
Глава 4. Переключайте клиентов
Автор: Des Traynor
Бóльшая часть покупок совершается по привычке без тщательного изучения альтернатив. Например, люди заказывают один и тот же кофейный напиток в одной и той же кофейне каждое утро, потому что цена изменения привычки высока. Люди редко переключаются, но когда они это делают, за этим решением стоит любопытный набор движущих сил. Будь то кофе или софт, бизнес выбирает простейший путь и просто старается сделать так, чтобы их продукт выглядел привлекательнее, чем чьи-либо ещё. Внешний вид продукта — это всего лишь одно составляющее из всех, побуждающих переключаться.
Говоря о переключении, мы говорим о борьбе со страхом или сомнениями перед пробой вашего продукта, а также о существующих проблемах текущего решения. Есть довольно весомые причины, почему люди всё ещё хотят пользоваться Microsoft Word, неважно насколько хорош ваш текстовый редактор.
Мотивировать клиентов переключиться можно, как с дружбой и отношениями, так с софтовым продуктом — надо определить противоречия и работать над их решением. Обратите их внимание на бессмысленность текущего решения и на безопасность переключения — это уменьшит беспокойство. Если вы справитесь с этим, то убедите клиентов в необходимости переключения.
***
«Сделать так, чтобы тревогу заглушала только покупка… вот задача для рекламы»
Дэвид Фостер Уоллес, Infinite Jest
Так можно сказать не только о рекламе, но и обо всем маркетинге. Маркетинг повышает осведомлённость, напоминает о существовании вашего продукта и распространяет новости о нём. Но маркетинг выполняет кое-что ещё — он побеждает инертность.
Почему клиенты меняют продукт
Люди не ненавидят прогресс — они просто движутся по инерции. Она останавливает их даже в том случае, когда покупка вашего продукта логична.
Людям не доставляет удовольствия управлять проектами с помощью электронных писем, отслеживать расходы в файликах типа «Расходы-март-12-версия3-финал.xls» или делать заметки со встречи в редакторах для написания кода. Для них переключение просто не важно.
Переключение — дело, как видите, непростое. Клиенты не покупают продукт — они переключаются на него. Большинство бизнесов пытаются мотивировать к переключению с помощью более приятного дизайна, лучшей производительности или количеством фичей. Но это затрагивает только качество вашего продукта, один кусочек пазла.
ReWired Group определили четыре действующие силы, две из которых на вашей стороне, а две — против вас.
Вы можете посмотреть на этот рисунок с точки зрения привлечения клиента — как мы можем заставить больше людей переключиться на наш продукт? Или посмотреть со стороны удержания — как мы можем быть уверены, что никто от нас не уйдёт?
Реклама позволяет манипулировать этими четырьмя силами:
- Повышение отталкивания: продемонстрируйте, насколько плох текущий продукт.
- Повышение притягательности продукта: расскажите о преимуществах вашего продукта, о том, как он помогает решать проблемы клиентов.
- Уменьшение страха и неопределённости изменений: убедите клиентов в том, что переключение пройдет легко и быстро.
- Сокращение привязанности к статус-кво: устраните клиентскую иррациональную привязанность к текущей ситуации.
Вспомните рекламную кампанию Apple «I’m a Mac», прошедшую около двух лет назад. Она создана исключительно в соответствии с перечисленными силами и стала невероятно эффективной. Внимание в ней акцентировалось на проблемах Windows (1), были наглядно продемонстрированы преимущества Mac (2), показано, насколько легко переключиться на него (3), ну а те, кто не переключился, представлены лохами, уменьшив их привязанность (4) к старым привычкам.
Проще говоря, сделали так, что тревожность можно заглушить только покупкой.
Девятикратный эффект
В широко цитируемой статье «Нетерпеливые продавцы и дубовые покупатели» John T. Gourville представил свой «Девятикратный эффект». По его мнению, клиенты в 3 раза переоценивают то, что они уже имеют В то же время компании также переоценивают в 3 раза свою инновационность. Вот как это выглядит:
Чтобы понять, почему инерция настолько велика, достаточно посмотреть на сравнение, которое делают клиенты при переключении.
Несоответствие показывает, почему новый продукт, который незначительно лучше существующего решения, редко преуспевает. Отсюда вывод: любому новому продукту надо быть в 10 раз лучше, чтобы его выбрало большинство. Только в этом случае переключение станет самоочевидным. Все разработчики мечтают об этом.
Чтобы завладеть клиентом, учитывайте все четыре силы при продвижении продукта. Бывает, что ваш продукт более чем хорош, но одна из сил мешает вам. Предусмотрите это в рекламе, и вы заметите улучшения.
Поймите, что клиенты переоценивают текущее решение, так же как и вы переоцениваете качество вашего продукта. Это означает, что продукт с незначительными улучшениями не взлетит. Лидером станет только «Десятикратный продукт».
Глава 5. Где завершается работа и начинается следующая
Автор: Des Traynor
Перед софтверными компаниями постоянно встает вопрос: «Стоит ли добавлять ещё одну фичу?» Стандартный ответ — да. Если вы хороши в создании ПО, то хотите решать все проблемы в мире с помощью программ.
В Intercom мы научились понимать, где заканчивается работа нашего продукта. Следуя Jobs-to-be-Done достаточно строго, вы можете попытаться закрыть весь рабочий день клиента с помощью вашего продукта. Вы могли начать с разработки тайм-трекера, затем добавить функцию выставления счетов, далее — возможность оформления закрывающих документов. И пока вы осознаете это, вы уже создали идеальное решение для очень маленькой группы пользователей. Поэтому понимание, где ваш продукт заканчивается, очень важно.
***
Важнейшей задачей продукт-менеджера является определение момента, когда его продукт закончится и клиента возьмёт на себя другой продукт.
Если ваш продукт обладает слишком малым функционалом, то не стоит тратить средства на его установку, даже без учёта его стоимости. Также если продукт выполняет слишком много операций, он будет сталкиваться с уже существующим софтом или рабочим процессом, удовлетворяющим пользователей. Это проблема Златовласки — вам нужен продукт, который в самый раз.
Понимание рабочего процесса вашего продукта
Возьмём для примера тайм-трекер. В абсолютном минимуме это просто сумма в колонке с цифрами. Если это весь функционал вашего ПО, то оно абсолютно бесполезно. Excel или Google Таблицы уже выполняют эту работу. Простота в данном случае не имеет смысла. Даже гениальный дизайн не поможет такому продукту отработать затраты на содержание.
В максимуме тайм-трекер может содержать управление проектом, бюджетирование, управление подрядчиками, выставление счетов, документооборот и мониторинг сотрудников. Такое приложение решает множество связанных задач, за счет чего наступает на пятки уже используемым продуктам. В данном случае это Xero, Wrike, Basecamp, Teamwork и т. д.
Продукт должен решать задачи на протяжении всего рабочего процесса. У него есть точки начала и конца. Чтобы понимать, где должны быть эти точки, необходимо представлять рабочий процесс в целом. Давайте рассмотрим это на примере команды, ежедневно заказывающей обед.
Если вы создаёте приложение, с помощью которого команда ежедневно может заказывать обед, рабочий процесс должен выглядеть так:
- Кто-то проголодался.
- Он или она сообщает об этом остальным.
- Начинается обсуждение — куда-нибудь пойти или оформить доставку.
- Далее обсуждается, где заказать еду.
- Меню разных ресторанов передаются от сотрудника к сотруднику.
- Принимается решение.
- Для сбора всех блюд назначается один человек.
- Он размещает заказ.
- Уточняется время доставки и стоимость.
- Проходит время.
- Приезжает и съедается еда.
- Подсчитывается общая сумма заказа и ищется не заплативший коллега.
- Деньги собираются сегодня или сбор откладывается на завтра.
- Кто-то пишет о еде в Twitter или Facebook, а кто-то постит в Instagram еды. Остальные напишут отзыв на Yelp.
- Все возвращаются к работе.
Когда вы понимаете весь рабочий процесс, то можете сфокусироваться на наиболее выраженном, болезненном участке, где ваш продукт может помочь, или на фрагменте, который с помощью продукта можно сделать веселее или интереснее. Спросите себя: «Мой продукт витамин или болеутоляющее?»
Где вам начать?
Ваш продукт должен начинать действовать с первого шага, на котором добавит ценности. В нашем примере с обедами начался, вероятно, это четвёртый шаг. Более раннее начало приведет к тому, что это будет что-то вроде чата или e-mail. Идея сомнительная.
Приведем реальный пример. Instacart — сервис доставки продуктов питания из магазинов. Создатели пытались повторить всю цепочку снабжения продуктовых магазинов: покупка складов, грузовиков и т.д. Но не добавили к ней ценности. Первым пунктом, где они могли добавить ценности, было размещение онлайн-заказа из продуктовых магазинов — то, с чем большие ритейлеры традиционно борются. Понимая весь рабочий процесс и точку, где Instacart мог добавить ценности, они создали великолепное решение.
И сделали это, используя текущую инфраструктуру магазинов продуктов питания, вместо того чтобы создавать всю цепочку с нуля.
Другие продукты также хорошо с этим справляются. Так, Instagram начинается с импортирования ваших социальных связей, тайм-трекер — с импорта проектов с Basecamp. Хорошие API и импортирование помогают пользователям легко начать работу.
Где вам закончить?
Бюджет, время или деньги должны ограничивать, но никогда не описывать границы вашего продукта. Большой бюджет должен определять, насколько хорошо будет решена проблема, но не спектр проблем для решения. Попытка охватить весь рабочий процесс от начала до конца и все типы пользователей близка к невыполнимой.
Ваш продукт должен остановиться, когда:
- лидеры рынка (например, Apple, Netflix, Expedia) уже следят за вашим продуктом, а вы и не собирались останавливаться;
- создано множество способов использования вашего продукта большим количеством типов пользователей (расчёт зарплаты в тайм-трекере будет непростой фичей);
- вовлечены отличные от изначальных конечные пользователи (менеджеры, бухгалтеры и т.д.);
- он разросся в направлении, где не даёт никакой ценности.
Определение и уничтожение бесполезных шагов
Если пользователь завершил работу с вашим приложением, и его следующим действием станет скачивание файла, который можно отправить с помощью e-mail, то это бессмысленное действие. Если это делается для экспорта расходов пользователя в CSV-файл, чтобы скачать и пересохранить в XML, а затем отправить бухгалтеру — это тоже бессмысленное действие. Если завершение проекта обозначает скачивание множества файлов, их архивирование и отправку клиенту с целью безопасного хранения — это действие так же бессмысленно. E-mail почти всегда является источником бессмысленных действий и редко несёт достаточно информации («кто-то оставил коммент») или не может быть связан с понятными действиями — «подтвердить» или «отметить как завершённое».
Если ваш пользователь прокликивает какую-то серию шагов, не анализируя и не принимая решений, это должно быть убрано.
Будущие итерации
Всегда затыкайте бреши перед расширением продукта. От перехода с коробочной версии к SaaS выигрывают надёжные и законченные продукты, а не забагованные и раздутые. Расширение продукта для решения большой проблемы, может, и здорово, но оно должно быть выполнено на устойчивом фундаменте. Если ваш основной продукт не целостный, то добавление новых фичей всё только ухудшит.
Много написано о стремлении к простоте, но не всё так просто: придание продукту простоты принципиально отличается от создания простого продукта.
Придание простоты означает удаление неуместных сложностей, благодаря чему пользователь сможет решать проблемы максимально эффективно. В то же время создание простого продукта означает сокращение его границ и выбор минимального отрезка в рабочем процессе, на котором продукт может быть ценным. Такой подход минимально возможного продукта создаёт риск стать узкоспециализированным решением, или, что хуже, фичей, но не продуктом.
Когда целитесь в «простой продукт», знайте, где подвести черту.
Глава 6. Плохой продукт может делать хорошую работу
Автор: Des Traynor
Большинство продуктов одержимы запутанностью своей тематики. К примеру, погодные приложения фокусируются на объёме осадков, силе ветра и на всех видах прогнозов, которые мало кого интересуют. Обычно пользователи хотят получить ответы на простые вопросы: «Пойдёт ли дождь?» или «Насколько будет тепло?»
Мы в Intercom заплатили кровью за этот урок. Запущенные нами карты стали невероятно популярны. Понять, почему так, мы не могли, но были счастливы видеть вовлечённость пользователей. На деле же оказалось, что люди использовали фичу для очень специфичной работы. Это было поразительно, так как мы создавали карту не для этого.
Парадоксально, но мы сделали плохую карту, которая стала хорошей фичей. И мы многое поняли.
***
Клиенты постоянно будут удивлять вас креативностью подхода к использованию вашего продукта, и делать это будут неосознанно — просто адаптируя ваш продукт к своим нуждам.
Помните приведённое ранее высказывание Питера Друкера про клиентов, которые редко покупают то, что компания продаёт? Таким образом, чтобы улучшить продукт, сначала надо понять, как он используется.
Объясним на примере.
Почти сразу после запуска Intercom мы добавили карту, чтобы пользователи могли видеть, где находятся их клиенты.
Это была классическая «это круто, но мы не знаем, зачем» фича. Трафик демонстрировал быстро возрастающую популярность, но продвигать карту как фичу оказалось тяжело, так как возникли сложности с пониманием, а для чего, собственно, она нужна.
Были предположения, что её можно использовать для того, чтобы:
- понять, где находится больше клиентов, но многие менеджеры продукта уже владели данной информацией;
- увидеть количество клиентов в определенном городе, однако список пользователей подходит для этого гораздо лучше;
- увидеть количество пользователей в выбранной стране, но и здесь список оказался удобнее.
Так какими же достоинствами обладает карта помимо впечатляющего внешнего вида? Перечислим три направления, для которых она использовалась.
- Для демонстрации на выставках и конференциях.
- Для публикации в Twitter.
- Для презентации инвесторам.
Улучшения, базирующиеся на использовании
Мы планировали улучшить карту перед тем, как узнали, каким образом ее используют. Собирались сфокусироваться на:
- географической точности;
- кластеризации;
- улучшении границ стран и городов;
- прочих картографических улучшениях
На все эти «улучшения» могли уйти месяцы разработки, но также всё могло завершиться ухудшением продукта, потому что клиент покупал не то, что мы продавали. Это была не карта, а экспонат.
Что мы могли сделать для того, чтобы карта подходила для настоящей работы?
- В первую очередь, придать ей бóльшую привлекательность.
- Предусмотреть автоматическое сокрытие нежелательной информации, чтобы можно было безопасно ею делиться.
- Сделать расшаривание удобным.
Так мы создали прекрасную анимированную карту с уникальным урлом, который легко расшарить.
Плохая карта делает хорошую работу
Полностью фокусируясь на том, как фича используется, игнорируя тематику, к которой она принадлежит, или тип фичи, быстро понимаете, каким образом её можно улучшить. Вместо попытки обратиться к гипотетическим рынкам возможных клиентов, вы можете запилить улучшения, которые сработают незамедлительно.
Автор: Александр Иванов
