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

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

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

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

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

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

Чувствовать, чего хотят клиенты, – основной навык, необходимый каждому PM. Вы должны развивать глубокое понимание и эмпатию, чтобы безошибочно определять возможности продукта и находить решения, отвечающие потребностям пользователей[18].

Обязанности

РАЗГОВАРИВАТЬ С ДЕЙСТВУЮЩИМИ И ПОТЕНЦИАЛЬНЫМИ ПОЛЬЗОВАТЕЛЯМИ

Пользователи – это люди. Что мы делаем, чтобы узнать человека получше? Мы с ним разговариваем!

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

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

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

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

Копайте глубже

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

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

В Xanar учли это и просто уравновесили манипулятор. Он не стал легче (на самом деле технически он был даже тяжелее), но зато его управляемость сильно возросла.

Как оказалось, люди не всегда знают, чего они хотят. Они чувствуют «боль» и превращают ее в конкретное решение. И отчасти ваша задача состоит в том, чтобы это решение трансформировать обратно, то есть выслушать запрос, а затем выявить лежащую в его основе проблему. Она-то и становится в итоге «jobs to be done» – «работой, которую нужно выполнить» (с. 49)[19].

Чем глубже PM вникает в проблему, тем ему проще понять клиента и направить команду в нужном направлении в поисках эффективного решения.

Чтобы тщательнее проработать тему, попробуйте задать пользователю такие вопросы:

• Расскажите, как вы собираетесь использовать запрашиваемую функцию. Что происходит перед ее применением? Что происходит после?

• Является ли это действие частью более масштабной задачи?

• С какими трудностями вы сталкиваетесь при выполнении этого действия?

• Пробовали ли вы раньше решить эту проблему? Что не сработало? Как вы решаете эту проблему сегодня?

• Если мы создадим продукт по вашему запросу, вы сразу же начнете его использовать или понадобится что-то еще?

• Вот как я понимаю вашу проблему: […]. Я ничего не упустил?

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

ПРОВЕРЯТЬ СВОИ ПРЕДПОЛОЖЕНИЯ

Непроверенные догадки – опасная вещь. Новые PM часто слишком уверены в своих идеях и решениях и даже не допускают мысли о неудаче.

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

Луи Лека (Louis Lecat), руководитель по продукту в компании Algolia, рассказал, как проверка его предположений с помощью прототипа серьезно повлияла на конечное решение:

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

Предлагаем учесть следующие моменты при проверке предположений:

• Почему пользователи предпочитают именно ваш продукт.

• Какой функционал обязателен, а какой – нет.

• Сколько времени и усилий пользователи тратят на изучение продукта.

• Какова серьезность «мелких» недоработок юзабилити.

• Насколько просто найти ту или иную функцию.

• Насколько пользователи готовы к активному использованию нового продукта.

О способах проверки предположений читайте в разделе «Исследование пользователей» (с. 53).

ПЛАНИРОВАТЬ СТРАТЕГИЧЕСКИЕ ИССЛЕДОВАНИЯ ПОЛЬЗОВАТЕЛЕЙ ДЛЯ ПОИСКА НОВЫХ ВОЗМОЖНОСТЕЙ

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

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

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

СОЗДАВАТЬ КУЛЬТУРУ, ОРИЕНТИРОВАННУЮ НА ПОЛЬЗОВАТЕЛЯ

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

В компании Twilio обнаружили, что стажировка в службе поддержки клиентов значительно повышает эмпатию сотрудников. Джейсон Насси (Jason Nassi) написал по этому поводу:[20]

Вот несколько способов сделать поведение команды более ориентированным на пользователя:

• Требуйте, чтобы все PM время от времени отвечали на запросы, поступающие в службу поддержки.

• Ведите рейтинг среди коллег по количеству визитов к клиентам.

• Каждую неделю устраивайте для команды встречи с клиентами.

• Введите в повестку собраний команды регулярный обмен новой информацией о клиентах.

• Добавьте раздел «Информация о клиентах» в шаблон спецификации.

• Спрашивайте о потребностях клиента в ходе обзора продукта.

• Будьте образцом для подражания – сами проводите встречи с клиентами и делитесь полученными знаниями.

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

Практики роста

МЫСЛИТЕ, КАК НОВИЧОК

Суть успеха в работе с продуктом состоит в том, чтобы хорошо в нем разбираться. Когда его использование становится привычным и простым (что часто бывает в практике PM), легко забыть, каково это – знакомиться с новым для себя продуктом.

Старайтесь как можно чаще ставить себя на место того, кто будет пользоваться продуктом впервые. Опробуйте все возможные функции, представляя, что вы с ним не знакомы. Что могло бы вас запутать? Какие описания или значки кажутся непонятными? Если вы сделаете это внимательно, вам удастся быстро выявить проблемы, с которыми могут столкнуться новые пользователи.

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

УСТАНОВИТЕ СВЯЗЬ МЕЖДУ ВЫБОРОМ ПРОДУКТА И ЗНАНИЕМ ПОТРЕБНОСТЕЙ КЛИЕНТА

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

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

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

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

РАЗВИВАЙТЕ ИНТУИЦИЮ

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

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

РАССТАВЛЯЙТЕ ПРИОРИТЕТЫ

Нужно ли устранять все обнаруженные вами проблемы с юзабилити продукта? Это сложный вопрос. И ответ – как это часто бывает в жизни (и в управлении продуктами) – таков: все зависит от ситуации.

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

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

Не надо полагать, что качество не имеет значения. Имеет и еще как! Но главное здесь – баланс. Хороший PM понимает, когда обнаруженная проблема с юзабилити важна настолько, что нужно отложить запуск продукта на три недели.

РАСПРОСТРАНЯЙТЕ ЗНАНИЯ О ПОТРЕБНОСТЯХ КЛИЕНТОВ

Отличить опытного PM от новичка можно по тому, как он раскрывает актуальную информацию о клиентах.

Первый обычно действует так:

• В ходе совещаний приводит примеры из жизни.

• Указывает другим PM на интересные пользовательские исследования.

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

• Предоставляет руководству полученные сведения и их стратегический анализ.

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

ДОКАПЫВАЙТЕСЬ ДО СУТИ, КОТОРАЯ ПОМОЖЕТ ВСКРЫТЬ ПРОБЛЕМУ

Примерно так и выглядит глубокое понимание потребностей клиента – вы должны видеть связи между фактами и знать, какая информация важна в конкретной ситуации.

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

Концепции и фреймворки

РАБОТА, КОТОРУЮ НУЖНО СДЕЛАТЬ (JTBD)

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

Идея, которую популяризовал Клей Кристенсен (Clay Christensen), одновременно проста и сложна. Он объясняет ее так:

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

Первым на ум приходит наивный ответ – он хочет послушать музыку (да конечно!). Если бы это было так просто, достаточно было бы сделать приложение для прослушивания старых, полюбившихся пользователю композиций. В крайнем случае, можно добавить возможность самостоятельно составлять плейлисты.

Более развернутый ответ (в зависимости от конкретного приложения и пользователя) звучит так: «Я устраиваю вечеринку и хочу создать приятную атмосферу. Мне нужно то, что понравится моим друзьям и поднимет всем настроение». И этот ответ ведет нас к новому вопросу: «Как создать плейлист под определенное настроение?»

Методология «Работа, которую нужно сделать» (Jobs To Be Done, JTBD) используется для изучения мотивации и поведения клиентов[21].

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

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

Говоря с потенциальным клиентом, постарайтесь выяснить, для какой «работы» он хочет «нанять» ваш программный продукт. И не останавливайтесь на этом, копните глубже. Спросите почему.

ПУТЬ КЛИЕНТА

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

Рассмотрим упрощенный пример пути клиента для приложения Netflix.

• Осведомленность: я узнал (возможно, много лет назад), что Netflix существует.

• Рассмотрение: я выяснил, что на Netflix есть мой любимый сериал. Я подумываю о том, чтобы оформить ради этого подписку. Но стоит ли оно того? Может, лучше просто купить фильм на Amazon?

• Покупка: я решил оплатить подписку на Netflix.

• Удержание: продолжаю платить за Netflix (потому что он мне нравится… или потому, что я забыл отменить подписку).

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

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

РЕКОМЕНДАЦИИ ПО ЮЗАБИЛИТИ ПРОДУКТА

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

Золотым стандартом в области удобства использования программных продуктов стали эвристические правила, созданные компанией Nielsen Norman Group.

10 основных принципов юзабилити[22]

Эти принципы, описанные Джейкобом Нильсеном (Jakob Nielsen), называют эвристическими, потому что они представляют собой общие универсальные правила, а не специальные указания по юзабилити продукта.

1. Видимость статуса системы

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

2. Соответствие системы и реальности

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

3. Пользовательский контроль и свобода действий

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

4. Последовательность и соответствие стандартам

У пользователя не должно возникать сомнений по поводу значения слов, ситуаций или действий. Следуйте принятым для конкретной платформы стандартам.

5. Предотвращение ошибок

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

6. Распознавание вместо запоминания

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

7. Гибкость и эффективность использования

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

8. Эстетичность и минимализм дизайна

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

9. Распознавание, диагностирование и исправление ошибок

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

10. Справка и документация

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

Помимо перечисленных выше правил, существует несколько общих рекомендаций, которые следует запомнить:

• Ограниченное внимание: в жизни пользователи обращают на пользовательский интерфейс (user interface, UI) намного меньше внимания, чем вам кажется. Люди подсознательно игнорируют большие кричащие баннеры и любые другие элементы, похожие на рекламу. Они не читают длинные абзацы и даже предложения. В любой момент их могут прервать или отвлечь. Если им не будет четко понятна последовательность действий, они даже не попытаются в ней разобраться.

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

• Доступность: около 4 % населения страдают той или иной степенью дальтонизма, а около 2 % населения имеют другие нарушения зрения[23]. Тестирование продукта на совместимость с программами считывания с экрана, предназначенными для слабовидящих и людей с цветовой слепотой, позволит избежать потери некоторых пользователей. Важные объекты UI желательно не только выделить цветом или обозначить изображением, но и снабдить альтернативным текстом. В придачу ко всему от так называемого универсального дизайна, который применяют, чтобы сделать продукт доступным для людей с ограниченными возможностями, выигрывают и обычные пользователи[24].

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

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

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

Большинство исследований (за исключением некоторых опросов) направлены на изучение качественных, а не количественных показателей[25]. Они помогают получить ответ на такие вопросы, как «Какие критерии учитывают клиенты при принятии решения о покупке?», но совершенно не подходят для вопросов типа «Каков процент людей, которых волнует цена продукта?».

Результатом изучения пользователей становятся выводы, рекомендации и новые модели.

ТИПЫ ИССЛЕДОВАНИЙ ПОЛЬЗОВАТЕЛЕЙ

Существует бесчисленное количество видов пользовательских исследований. Вот самые распространенные из них[26].

Полевые исследования

• Что это: полевое исследование – это изучение пользователя в его естественной обстановке, на рабочем месте (если речь идет о бизнес-версии ПО) или дома (если рассматривается ПО для личного использования). В ходе такой проверки вы наблюдаете за человеком в реальной жизни. Например, можно увидеть, какой у него компьютер или как часто ему приходится отвлекаться.

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

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

Дневниковые исследования

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

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

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

Интервью

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

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

• Что важно помнить: на интервью люди ведут себя нарочито оптимистично (например, отвечают: «Конечно, я бы использовал эту функцию»). Чтобы получить более реальный ответ, просите привести конкретные примеры из прошлого (например, «Расскажите, пожалуйста, когда вы в последний раз создавали дашборд?»).

Опросы

• Что это: опрос – это список вопросов, рассылаемых текущим или потенциальным клиентам. Можно сделать прямую рассылку или воспользоваться такими инструментами исследования рынка, как SurveyMonkey Audience или Google Surveys. Они имеют доступ к широкому кругу людей и позволяют задавать простые отборочные вопросы, чтобы отсеять нецелевую аудиторию до прохождения основного опроса.

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

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

Тестирование концепции и юзабилити продукта

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

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

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

Чтобы найти участников для таких тестов, вы можете разместить на своем сайте всплывающее окно опроса, например с помощью инструмента Ethnio. Другой вариант – использовать UserTesting.com для набора участников, которые будут проходить тест в асинхронном режиме. Оба подхода помогут вам быстро привлечь людей и получить результаты исследований.

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

Совместный дизайн

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

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

• Что важно помнить: не ждите, что клиент создаст за вас полноценное решение. Его вариант может пролить свет на его собственные идеи, но вряд ли будет учитывать все условия и сценарии использования.

Сортировка карточек

• Что это: участники получают карточки с разными позициями, и они должны разложить карточки по группам и дать этим группам названия. Например, им нужно решить, где посетитель сайта университета будет искать карту кампуса: на странице «Жизнь в кампусе» или «Как добраться»? Сортировку карточек можно проводить лично или удаленно с помощью онлайн-инструментов.

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

• Что важно помнить: количество карточек должно быть ограниченным, чтобы не перегружать участников исследования.

Бета-версия программы

• Что это: предоставление ограниченному числу пользователей раннего доступа к новым функциям программы в обмен на честный отзыв. Бета-версия позволяет опробовать идеи на реальных пользователях и получить обратную связь до официального запуска продукта.

• Когда применять: бета-версии программ – прекрасный способ поддержки пошаговой разработки. Они позволяют показать клиентам решение задолго до его полной реализации. К примеру, пользователи могут опробовать созданный отдельно для каждого из них скрипт (а не скрипт, встроенный в приложение UI). Обычно бета-пользователи готовы попробовать не до конца проработанный UI или прочесть справочный раздел «Начало работы».

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

Как запустить бета-версию программы

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

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

Как получить обратную связь

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

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

ПОДБОР УЧАСТНИКОВ ПОЛЬЗОВАТЕЛЬСКОГО ИССЛЕДОВАНИЯ

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

Чтобы узнать мнение текущих или потенциальных клиентов, разместите на своем сайте приглашение пройти опрос, используя такие инструменты, как Ethnio или Intercom. Отзывы случайных людей проще всего собирать через специальные сайты (например, UserTesting.com) или поставив стенд в каком-нибудь кафе.

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

КАКИХ ОШИБОК СЛЕДУЕТ ИЗБЕГАТЬ

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

Вы задаете неправильные вопросы

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

Дерево решений (с. 86) служит для этого отличным инструментом – оно помогает спрогнозировать возможные ответы и последствия для каждого из них. Если кто-то из стейкхолдеров настроен скептически, покажите им дерево решений до начала исследования, чтобы они убедились в правильности ваших вопросов.

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

• Если все прошло хорошо: переходим к более точному прототипу.

• Если все прошло плохо: возможно, причина в низком качестве прототипа. Переходим к высокоточному прототипу для более успешного тестирования.

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

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

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

Вы воздействуете на ответы участников

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

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

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

Вы взяли слишком много участников для юзабилити-теста

Существует простое и надежное правило – брать в среднем пять участников для тестирования юзабилити продукта[27]. Если их больше, эффективность выявления проблем снижается, при этом их все еще недостаточно много, чтобы отвечать на количественные вопросы.

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

Вы не воспринимаете исследователей пользователей как партнеров

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

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

Основные выводы

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

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

• Исследование пользователей – это недорого: реальное поведение клиентов полно сюрпризов, а исследования пользователей стоят (относительно) дешево. Не тратьте месяцы на инженерную проработку идей, которые можно подтвердить исследованием. Существует широкий выбор подходов к изучению пользователей помимо тестирования юзабилити продукта. Поговорите со специалистами, прежде чем решать, можно ли ответить на ваш вопрос при помощи исследования.

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

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

Однако здесь есть подвох, и не один.

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

Здесь в игру вступают количественные (числовые) данные. PM использует количественные данные и метрики, чтобы узнать, как в действительности ведут себя люди, а также выявить новые возможности и измерить успех.

Обязанности

ИЗУЧИТЬ КЛЮЧЕВЫЕ ПОКАЗАТЕЛИ УСПЕХА ВАШЕЙ КОМПАНИИ

Что для вас означает успех? Это интересный вопрос как для отдельно взятого человека, так и для организации. И, как выясняется, компании (и команды) отвечают на него по-разному.

Поэтому, как только вы приходите в команду (неважно, джуниор вы или сеньор), вам необходимо изучить актуальные метрики. Как ваша компания измеряет успех? А продукт? Какие показатели его использования считаются высокими?

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

В вашей компании должен быть дашборд, показывающий все нужные метрики в динамике. Если его нет, создайте его вместе со своей командой! Оптимизировать показатели невероятно сложно, если трудно понять, что они означают (см. «Создать дашборд для своей команды» на с. 61).

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

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

НАУЧИТЬСЯ ПОЛУЧАТЬ ДАННЫЕ САМОСТОЯТЕЛЬНО

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

Как это делать, зависит от компании. В одних компаниях действуют настраиваемые дашборды, и каждый PM может создать свой собственный дашборд. Это здорово! В других вы можете пользоваться только инструментами SQL. Тоже неплохо.

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

СОЗДАТЬ ДАШБОРД ДЛЯ СВОЕЙ КОМАНДЫ

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

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

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

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

• Уменьшите шум: подумайте, как можно разбить или отсортировать метрики, чтобы снизить разброс значений и шум. Например, вы хотите узнать количество пользователей, оставивших комментарии, а не количество самих комментариев. Если показатели количества и качества ежедневных новых пользователей сильно разнятся (например, из-за появления статей в прессе или попадания продукта в рекомендации магазина приложений), большинство графиков можно настроить так, чтобы они не учитывали пользователей, не прошедших качественный отбор. К примеру, можно оставлять только тех, кто завершил настройку или пользовался приложением по крайней мере три дня.

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

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

• Показывайте средние значения за 7 дней: некоторые продукты отличаются своим непостоянством и могут резко набирать популярность благодаря вирусной публикации или какому-то другому событию. И чтобы лучше разобраться в тенденциях, полезно просмотреть среднее значение за 7 (или 14, 28 и т. д.) дней. Это касается и продуктов, объем использования которых варьируется в зависимости от дня недели.

РЕГУЛЯРНО ПРОВЕРЯТЬ ПОКАЗАТЕЛИ СВОЕЙ КОМАНДЫ

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

• Как поменялись графики для тех или иных показателей по сравнению с предыдущим периодом? Они пошли вверх или вниз? Что вызвало эти изменения?

• Отмечается ли влияние недавних продуктовых или маркетинговых изменений на показатели?

• Превысил ли какой-либо показатель свой порог настолько, что это стоило бы отметить?[28]

• Прослеживаются ли какие-нибудь долгосрочные тенденции? Можно ли увидеть, какие показатели подтверждают или опровергают продуктовую стратегию?

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

ИЗУЧАТЬ ДАННЫЕ

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

Однажды моя команда в Google решила использовать IP-адреса пользователей, чтобы выдавать релевантные по местоположению результаты поиска на запросы типа «пиццерия». Мне казалось, что IP-адреса для этого было достаточно. Но как я могла это доказать? Мы не горели желанием сразу же проводить эксперимент – он не смог бы показать, как точно можно предсказать местоположение пользователя по IP-адресу. А множество ошибочных результатов поисковой выдачи сильно бы раздражали клиентов.

Проявите любопытство и изучите, какие данные доступны в вашей компании. Это могут быть дашборды Google Analytics, необработанные логи пользователей, отчеты NPS[29], журналы поиска – все, к чему у вас есть доступ. Начните с любых вопросов, пришедших вам в голову, независимо от того, связаны ли они непосредственно с вашими проектами или просто с чем-то интересным для вас. Ищите что-то необычное, затем попробуйте разобраться, что это может означать и чем было вызвано. Если вы найдете нечто интересное, обязательно поделитесь этим с другими людьми.

СФОРМИРОВАТЬ КЛЮЧЕВЫЕ ПОКАЗАТЕЛИ УСПЕХА ВАШЕЙ КОМПАНИИ

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

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

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

Смотрите также разделы «Значимые показатели против метрик тщеславия» на с. 66 и «Пиратские метрики» на с. 67.

ОТВЕЧАТЬ ЗА ПРИБЫЛИ И УБЫТКИ

В некоторых компаниях PM-сеньор отчитывается за то, какие прибыли и убытки (P&L) показывает их структурное подразделение. Это означает, что они выходят на другой уровень ответственности, где им приходится работать не только с командой разработчиков, но и с другими группами, например отделом продаж или маркетинга. PM в данной позиции отвечает не только за создание отличного продукта, но и за то, чтобы тот приносил достаточную прибыль и не вызывал лишних затрат.

Если вы отвечаете за P&L, вам приходится вести бюджет своей команды с кем-то из отдела финансов. Бюджет содержит плановые и целевые показатели на год, обычно с разбивкой на кварталы или месяцы. В нем учитывается количество людей, которых вы собираетесь нанять на каждую позицию, затраты на рекламу и другие издержки. Также он включает в себя доход, прогнозируемый на основе дохода предыдущего периода, сезонности, численности персонала отдела продаж, маркетинговых мероприятий и запуска продуктов[30].

Может показаться, что правильный прогноз получить невозможно; но, к счастью, он и не требуется. Илай Лернер (Ely Lerner), отвечающий за P&L в Yelp, поделился своей точкой зрения:

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

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

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

Анализ движущих факторов может показаться сложным. Но, как сказал Сачин Рекхи (Sachin Rekhi), руководитель по P&L в LinkedIn, такой анализ улучшает продуктовую интуицию и способен сделать из вас хорошего PM:

«Теперь, выдвигая инициативу, вы будете думать о том, какой движущий фактор она будет стимулировать и как сильно. Понятно, что вы не можете быть точны на 100 %, но в конце каждого квартала вы сможете оценить, что действительно было сделано, и интуитивно понять, какие дополнения и изменения продукта привели к тем или иным значимым показателям».

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

Практики роста

ИСПОЛЬЗУЙТЕ БЕНЧМАРКИ ДЛЯ ОСМЫСЛЕНИЯ ДАННЫХ

В начале карьеры я думала, что PM должен держать в голове множество разных сведений о продукте, и меня это очень пугало. Я не могла понять, зачем помнить наизусть количество пользователей продукта или темпы роста прибыли от его продаж. Мне сразу вспоминался урок истории, где я с трудом пыталась запомнить какие-то важные даты. Иногда я даже сомневалась, создана ли я для того, чтобы быть PM.

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

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

При изучении данных выберите некую контрольную точку, чтобы понимать, как интерпретировать те или иные значения.

УЧИТЕСЬ ИНТУИТИВНО ПОНИМАТЬ ДАННЫЕ

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

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

ПОВЫШАЙТЕ КАЧЕСТВО ЭКСПЕРИМЕНТОВ

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

Нунду Джанакирам (Nundu Janakiram), директор по продуктам для пассажиров Uber, рассказал о том, почему важно повышать эффективность экспериментов:

Если какой-то из экспериментов провалился, не торопитесь – подумайте, как можно было выявить проблемы раньше. Хорошо ли вы спланировали и провели эксперимент? Можно ли было проверить идею при помощи прототипа, прежде чем проводить тесты?

Концепции и фреймворки

ЗНАЧИМЫЕ ПОКАЗАТЕЛИ ПРОТИВ МЕТРИК ТЩЕСЛАВИЯ

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

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

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

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

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

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

Как правило, они представляют данные за неделю или месяц (например, удержание клиентов за первую неделю) или дают разбивку значений на одного клиента (например, средний доход на одного пользователя, или ARPU – average revenue per user). Увеличение таких показателей будет с большей долей вероятности отражать реальное улучшение ситуации.

ПИРАТСКИЕ МЕТРИКИ

Один из самых запоминающихся наборов правильных показателей – тот, что Дейв Макклюр (Dave McClure) назвал «пиратскими метриками» (в английском языке первые буквы их названий образуют забавную аббревиатуру AARRR)[32]. Это показатели жизненного цикла клиента, и называются они «метриками воронки» (некая метафора дырявой воронки, из которой капает вода). Идея в том, что сверху воронки вы помещаете большое количество клиентов, но потом постепенно теряете их на каждом следующем этапе. Те, кто доберется до самого дна воронки и не «утечет», как раз и дадут реальный доход.

• Привлечение (acquisition): новые пользователи продукта, например число подписок или загрузок в месяц.

• Активация (activation): количество довольных пользователей; для каждого продукта оно представлено своим показателем. Например, для Facebook это может быть добавление семи и более друзей. Для SurveyMonkey – получение не менее пяти ответов на рассылку опроса. Как правило, это месячный показатель конверсии, то есть процент новых пользователей, перешедших от знакомства с продуктом к его использованию.

• Удержание (retention): число клиентов, повторно использующих продукт. Отслеживается в виде таких показателей, как количество активных пользователей в день (DAU, daily active users), в месяц (MAU, monthly active users) или их соотношение (DAU/MAU). Также сюда относятся метрики использования, такие как количество минут просмотра видео на YouTube.

• Рекомендации (referral): готовность клиентов советовать продукт другим пользователям. Можно оценивать, например, по количеству отправленных приглашений. Многие компании также отслеживают индекс потребительской лояльности (NPS, net promoter score), рассчитываемый на основе ответов на вопрос: «Какова вероятность, что вы порекомендуете наш продукт?» Этот вопрос показывает, насколько успешным может быть сарафанное радио.

• Доход (revenue): объем дохода. Например, стоимость подписки, приобретение продукта или продажа рекламы. Здесь важно отслеживать пожизненную ценность клиента (lifetime value, LTV), чтобы сравнить ее со стоимостью его привлечения (cost of acquiring a customer, CAC). Существует универсальное правило – соотношение LTV: CAC должно быть не менее 3: 1. Когда действующий клиент отменяет подписку, это называется оттоком.

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

A/B-тестирование и статистика

A/B-тестирование, также известное как сплит-тестирование или онлайн-эксперимент, представляет собой живой эксперимент с имеющейся базой пользователей. Одна случайная выборка пользователей получает одну версию продукта, так называемый вариант, а другая – второй вариант. Затем вы сравниваете, какой из вариантов лучше сработал для достижения ваших целей, например увеличения кликабельности или конверсии. Как правило, по завершении теста версия, показавшая лучшие результаты, распространяется среди 100 % пользователей.

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

Некоторые A/B-тесты сравнивают две альтернативы какой-то функции, например синий или зеленый цвет кнопки. Другие сопоставляют текущее положение дел с возможными изменениями, такими как добавление окна поиска в верхней части страницы.

Такие мелочи, как надпись на кнопке в форме регистрации, могут значительно повлиять на важные показатели, например количество зарегистрировавшихся пользователей. С другой стороны, A/B-тестирование увеличивает сроки выполнения проекта и может сбить с толку пользователей или вызвать у них раздражение, если они заметят, что видят разные версии продукта. К применению А/В-тестирования нужно подходить очень разборчиво – используйте его, только чтобы проверить изменения чувствительных к интенсивному трафику компонентов продукта, которые будут иметь преимущественно краткосрочный эффект[33].

ЧТО НУЖНО ЗНАТЬ О СТАТИСТИКЕ

• Принцип, лежащий в основе A/B-тестирования, достаточно прост – сравнить две вещи и выбрать ту, что лучше. Все!

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

Представьте, что вы пытаетесь определить, «честная» ли у вас монетка, то есть дает ли она равную вероятность выпадения орла и решки. После 20 бросков количество орлов равно 60 %. Значит, монета «нечестная»? Трудно сказать. Однако, если вы подбросите монетку 1000 раз и орел выпадет снова в 60 % случаев, вы можете сделать вывод, что монета, вероятно, и правда не совсем «честная».

Чем дольше идет эксперимент, тем выше наша уверенность в правильности результата. Однако здесь есть нюанс. Эксперименты отнимают много времени, поэтому не стоит проводить их дольше, чем необходимо.

Это касается и A/B-тестов. Проверять варианты А и В нужно так долго, пока не появится уверенность в правильности выбора, но не затягивать их настолько, чтобы нельзя было принять решение или испробовать другие варианты.

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

Чтобы определить статистическую значимость, можно вычислить одну из следующих величин: доверительный интервал (confidence interval) или p-значение (p-value). Обе они помогают понять, является ли результат статистически существенным, но доверительный интервал дает дополнительную информацию о диапазоне возможных значений.

Доверительный интервал

Предположим, что мы хотим узнать средний рост учащихся в школе. Чем больше детей мы измерим, тем ближе наши расчеты будут к фактическому среднему значению. Допустим, мы измерили рост 50 случайных учеников, и с вероятностью в 95 % (стандартное значение, используемое большинством компаний) получили доверительный интервал от 122 до 132 сантиметров. Это значит, что с вероятностью в 95 % фактический средний рост – если бы мы измерили рост всех учеников в школе – составляет от 122 до 132 сантиметров[34]. Однако все еще существует вероятность в 5 %, что мы ошибаемся, и средний рост выше или ниже этого диапазона.

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

Если эксперимент с вероятностью в 95 % показывает доверительный интервал количества зарегистрированных пользователей в 10–12 %, это означает, что вариант B увеличил количество новых регистраций на 10–12 %. Отлично! Если бы вместо этого он показывал диапазон от –12 до –10 %, это был бы провал.

Часто доверительный интервал охватывает сразу отрицательные и положительные значения, а также ноль, например от –4 до 3 %. Это значит, что нам неизвестно, привело ли изменение продукта к росту или снижению показателей. Поскольку доверительный интервал включает в себя ноль, изменение может дать как отрицательный результат – потерю до 4 %, так и положительный – прирост до 3 %.

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

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

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

P-значения

Другой вид расчетов, о которых вы могли слышать, это вычисление р-значения. Оно отражает вероятность получения результатов эксперимента при проигрышном или нейтральном изменении метрик. Большинство компаний в качестве порогового значения используют 0,05 (5 %), что соотносится с 95 % доверительной вероятности.

Доверительный интервал и р-значение напрямую связаны. Если р-значение ниже 0,05, нижний предел доверительного интервала при вероятности в 95 % будет выше нуля. Большинство PM предпочитают работать с доверительным интервалом, так как он дает больше информации о наилучшем и наихудшем сценарии событий.

Остерегайтесь p-хакинга

Применять пороговое значение 5 % нужно аккуратно, иначе это вызовет некоторые проблемы.

Предположим, что в результате А/В-тестирования редизайна приложения выяснилось, что с вероятностью в 95 % произошел рост использования чата. Наверняка это что-то значит, верно?

И да, и нет. Если мы на 95 % уверены, что к такому росту привел именно новый дизайн, все равно остается 5 % вероятности того, что наблюдаемое изменение было случайным.

Теперь представьте, что мы пытаемся оценить потенциальное воздействие нововведений на десятки функций: чат, профили пользователей, поиск, группы, события, экспорт данных и т. д. Установив возможный порог ошибки в 5 %, мы, скорее всего, увидим воздействие на одну из десятков функций с вероятностью в 95 %[35].

Это так называемый p-хакинг (p-hacking) – попытка выудить нужные вам значения и связи из общего объема данных. Если долго мучиться, что-нибудь получится. Просто случайно (см. «P-хакинг на примере комикса xkcd» на с. 73).

Что же делать? Действуйте методично.

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

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

СТАТИСТИКА И ЭКСПЕРИМЕНТЫ

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

• Чтобы получить более точную информацию о влиянии обновлений на метрики, эксперимент следует проводить дольше. Если вам нужен рост показателя, скажем, на 1 %, потребуется провести довольно длительный эксперимент. Выявить улучшение на 50 % можно намного быстрее. Поработайте со своим специалистом по обработке данных, чтобы определить, реально ли получить изменения метрик с нужной вам точностью.

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

• Чем больше экспериментов вы проводите или чем больше показателей отслеживаете, тем выше вероятность того, что вы получите аномальный результат – показатель, который будет выглядеть как статистически значимый успех или провал, но на самом деле будет нейтральным. Это означает, что не нужно проводить кучу случайных экспериментов просто так. Иначе вы потеряете возможность определить, какое изменение точно сработало.

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

Основные выводы

• Ключевые показатели успеха продукта являются проявлением стратегии: одни продукты ориентированы на то, чтобы завоевать долю рынка, в то время как другие нацелены на повышение прибыльности. Для каких-то продуктов успехом считается их использование раз в месяц, а для иных – несколько раз в день. Убедитесь, что отслеживаемые вами метрики согласуются с предполагаемой стратегией.

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

• Активно работайте с данными: убедитесь, что в вашем продукте ведется журнал действий пользователей, и регулярно его просматривайте. Изучайте данные, старайтесь найти новые возможности для развития продукта. Задавайте вопросы, проявляйте любопытство.

• Проводите эксперименты, но не злоупотребляйте ими: эксперименты отлично подходят для выявления серьезных ожидаемых изменений. Но нельзя проверять сразу сотню идей в надежде, что какая-то из них сработает. Проведение множества хаотичных экспериментов значительно увеличивает шансы получить ложноположительный результат.

P-хакинг на примере комикса XKCD

Публикуется с разрешения неизменно потрясающих xkcd (https://xkcd.com/882/).

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

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

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

Оказалось, что мои опасения были беспочвенными. Я не только преуспела в команде Google Search, но и заработала репутацию человека как раз с отличными аналитическими способностями. Хотя это не значит, что я стала экспертом по электронным таблицам или умею мгновенно извлекать смысл из числовых показателей.

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