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

Желаемые результаты

В теории работ есть понятие, которым человек описывает желаемое состояние, в которое хочет попасть. Это Desired Outcomes, или желаемые результаты. Можно упрощённо сказать, что это метрики (критерии успеха), которыми человек будет замерять эффективность того решения, которое было нанято. Одна из ключевых вещей во всей теории с моей точки зрения.

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

Направление изменения + Метрика + Объект + Контекст

Можно немного упростить эту формулу (для более легкого восприятия):

Направление изменения + Метрика + Уточнение контекста

Примеры направлений изменения:

• Уменьшить
• Увеличить
• Минимизировать
• Максимизировать
• Сократить
• Не допустить изменений

Примеры метрик, которые человек захочет изменить:

• Время
• Деньги
• Уверенность
• Шанс (возникновения чего-то)
• Ошибки
• Полнота
• Количество
• Качество
• Вероятность

Пример

Возьмем одну работу из примера выше:

«Вовлечь ребенка в использование полезных и развивающих приложений на смартфоне».

Какие тут могут быть желаемые результаты:

• Сократить количество конфликтов на почве использования телефона.
• Исключить необходимость контроля за ребенком (сколько сидит в телефоне).
• Повысить пользу от «залипания» ребенка в телефоне.
• Снизить время, проводимое ребенком во «вредных» приложениях.

Ну вот человек нанял какое-то решение на эту работу. А затем оценивает, насколько сократилось количество конфликтов или насколько удалось снизить время. Так себе получилось изменить эти метрики? Ест немалая вероятность, что человек задумается о смене решения. То есть вроде бы «работа» и закрыта (ребенок вовлечен), но вот желаемых результатов добиться не удалось. Это открывает перед нами возможность либо поиска точек роста существующего продукта, либо точек фокуса при создании нового продукта.

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

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

«Наш продукт (или наша новая фича) поможет вам сократить количество конфликтов с детьми на почве использования телефона».

Поэтому, одними из ваших задач должны быть:

1. Раскопать и подтвердить желаемые выгоды человека.
2. Придумать решение, которое поможет добиться этих выгод.

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

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

Сформулируйте ценностное предложение, как я описывал выше, и ответьте на вопрос «Зацепило?» Если нет, то это вряд ли тот самый желаемый результат. Скорее, просто приятный бонус. Выберут ли ваше решение ради небольшого бонуса?

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

Реальный пример → Сервис для проверки юридических лиц. Один из желаемых результатов для работы «проверить платежеспособность нового контрагента при заключении с ним первого договора» команда сформулировала следующим образом:
«Минимизировать риски неисполнения обязательств по договору». Звучит цепляюще, но как мы докажем человеку, что именно благодаря нам эти риски были минимизированы? Проверяйте себя!

У Тони Ульвика в его Outcome-Driven Innovation фреймворке есть способ получить количественную информацию о выгодах, чтобы помочь вам принять правильное управленческое решение. Прочитайте статью Тони Ульвика (особенно 3 и 4 параграфы) — в ней описан количественный подход к оценке потенциала желаемых результатов и поиска точек роста на основании результатов.

Проблемы и барьеры

В рамках теории работ мы тоже рассматриваем проблемы и барьеры пользователей. Только это немного особенные проблемы.

Мы рассматриваем проблемы и барьеры, которые мешают человеку выполнить работу (совершить прогресс) самостоятельно или мешают нанять какое-то новое решение (по сравнению с тем, что человек использует прямо сейчас). Это могут быть:

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

Пример

Продолжим рассматривать работу «Вовлечь ребенка в использование полезных и развивающих приложений на смартфоне».

Какие тут могут быть проблемы и барьеры, мешающие совершению прогресса:

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

Зачем нам рассматривать эти проблемы и барьеры?

1. Эти проблемы могут помешать человеку нанять наш продукт. Мы должны каким-то образом в продукте или в коммуникации с человеком решить или утилизировать эти проблемы.
2. Это отличные точки роста для нашего продукта. Если прямо сейчас при использовании наших конкурентов человек наталкивается на эти проблемы, мешающие совершеннию прогресса, то мы можем легко перетащить человека в свой продукт, если он (продукт) позволит эти проблемы решить. Человек с радостью сменит текущее решение на наше.

Описание пользователей

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

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

Кроме того, имея связь «работа – люди» мы можем дополнительно себя проверить в разрезе желаемых результатов и проблем и понять, не забыли ли мы чего-то.

Пример

Продолжим рассматривать работу «Вовлечь ребенка в использование полезных и развивающих приложений на смартфоне».

Как можно описать пользователей, у которых возникает подобная работа:

• Родители старой закалки (консерваторы). Или родители с современным взглядом на воспитание.
• Нянечки, бабушки, старшие братья и сестры, сидящие с детьми.
• Те, кто знает о наличии полезных приложений: «сами с усами» или те, кому кто-то подсказал приложение.
• Уверенные пользователи смартфонов (проводят в них много времени). Или те, кто не особо понимает, как все работает в смартфонах (неискушенные пользователи).
• Семьи с несколькими детьми. Как это влияет? Младшие видят, что у старших нет никаких ограничений. Или старшие могут давать младшим попользоваться «вредными» приложениями со своего телефона.
• Занятые родители, которые не могут уделить достаточно внимания этой «работе» (не хватает времени на вовлечение). Или у них есть время, но не хватает аргументов, чтобы убедить детей.

Как структурировать и проверить все данные о работах

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

Можете сделать себе такой же, если пользуетесь Miro или Google Docs. Тут дело не в особой структуре или канвасе. Суть в том, чтобы вы не забыли подумать обо всех важных составляющих «работы». У Михаила Руденко тоже есть интересный канвас для описания JTDB. Советую посмотреть примеры и собрать для себя лучшую версию.

Как проверить работы?

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

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

Далее вы проводите исследование, состоящее из нескольких частей:

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