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

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

Позвольте мне объяснить.

Для приложения Asana[2] мы придумали секретную опцию: после выполнения какой-либо задачи на экране запускалась праздничная анимация с единорогом. Клиенты были довольны. Кому может не понравиться настоящий единорог, летающий по экрану?

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

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

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

Однако одной моей веры оказалось недостаточно, ведь я не могла заставить всех делать то, что мне хочется.

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

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

Надежда, которую зажигает эта книга

У хорошего PM есть цели. Есть они и у нашей книги (а это тоже продукт). Вот эти цели.

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

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

В Google я пришла по программе APM. Здесь я продолжала узнавать много нового о создании потрясающих продуктов. При этом сложность принимаемых решений росла. Моя работа больше не вписывалась в понятную структуру с четко расписанными проектами и установленными сроками. Теперь я должна была взаимодействовать с целой командой, чтобы решить, какими проектами заняться и когда выпускать продукт на рынок. От меня ожидали, что я буду управлять стейкхолдерами и стратегией, а еще своей собственной карьерой. Я как губка впитывала информацию, которой меня пичкали менторы, но мне все равно казалось, что, как только что-то начинало получаться, я сразу все портила.

Наша цель – создать руководство, которого никогда не было у наших учеников.

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

За восемь лет число сотрудников Asana превысило 500 человек, я стала руководителем команды из 20 PM и вела roadmap[3] продукта. Я запустила программу APM от Asana и стремилась все делать так же правильно, как делали мои менторы, и даже круче (и при этом не допускать их ошибок).

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

За эти годы я очень многому научилась и сильно выросла. Меня наставляли и поддерживали удивительные люди. Я совершала ошибки и училась на них. Я добивалась серьезных успехов и извлекала из них уроки. Я составляла схемы карьерного роста и нанимала PM. Все это нашло отражение в менторстве и поддержке PM – как выпускников колледжей в рамках программы APM, так и уже состоявшихся специалистов, желающих выйти на более высокие позиции. А теперь все мои наработки доступны и в виде книги.

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

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

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

О мифических существах

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

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

Как пользоваться книгой

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

В книге Андерса Эрикссона (Anders Ericsson) и Роберта Пула (Robert Pool) «Peak: Secrets from the New Science of Expertise»[4] авторы исследуют вопрос о том, как люди развивают свой потенциал и достигают высокого уровня мастерства. Их главный вывод – опыт человека зависит от качества его мысленных представлений. Например, когда гроссмейстер смотрит на шахматную доску, он видит не разбросанные по ней фигуры, а целиком всю игру, в которой белые сыграли ферзевый гамбит, а черные от него уклонились.

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

С опытом в ответ на жалобу инженера по поводу технического долга[5] вы скажете: «Так это же классический конфликт roadmap, вызванный приоритизацией несопоставимых задач в одном ранжированном списке, и его легко решить, создав roadmap по принципу сбалансированного портфеля»[6]. Это не совсем похоже на «уклонение от ферзевого гамбита», но тоже сойдет.

НАВЫКИ PM

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

В этой книге мы сгруппировали навыки, необходимые успешному лидеру по продукту, по пяти категориям:

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

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

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

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

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

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

Для каждого навыка мы выделили:

• Обязанности: то, что вы должны делать.

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

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

Обязанности и практики роста, актуальные на более высоких ступенях карьеры, отмечены знаком 

.

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

ПРОФЕССИОНАЛЬНЫЕ НАВЫКИ

Для успешной карьеры недостаточно быть отличным PM и уметь запускать классные продукты.

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

Мы рассмотрим следующие темы:

• Карьерная лестница PM.

• Как получить повышение.

• Постановка карьерных целей.

• Работа с руководителем.

• Оптимальный цикл перформанс-ревью.

• Нетворкинг.

• Возможности карьерного роста за пределами продакт-менеджмента.

• Вопросы и ответы от успешных лидеров по продукту.

Карьерная лестница PM

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

Почему?

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

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

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

В главе 32 «Карьерная лестница» (с. 337) мы подробно описали, что представляет собой каждый уровень и как его достичь. Мы охватили все позиции от APM до руководителя по продукту и описали типичный для каждого уровня объем работ, степень самостоятельности и влияния.

Если у вас мало времени…

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

Я НОВИЧОК В УПРАВЛЕНИИ ПРОДУКТОМ

Если вы новичок в продакт-менеджменте, поздравляю. И добро пожаловать!

• Начните с главы 2 «Роль продакт-менеджера» (с. 22) – изучите основы жизненного цикла продукта и то, чем занимается PM на каждом этапе.

• Прочтите главу 3 «Первые 90 дней» (с. 31) – сосредоточьтесь на том, как проводить вводные совещания. Роль PM в разных командах немного отличается, поэтому важно уметь строить разговор так, чтобы узнать, чего от вас ждут коллеги.

• Просмотрите раздел «Обязанности» для каждого навыка PM, чтобы получить более глубокое представление о должности.

Я НЕ МОГУ ПОЛУЧИТЬ ПОВЫШЕНИЕ

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

• Начните с главы 32 «Карьерная лестница» (с. 337), узнайте, чем один уровень должности отличается от другого, и получите конкретные советы о том, как добиться повышения.

• Не пропустите главу 34 «Навыки для карьерного роста» (с. 418).

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

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

Основы можете пропустить – для вас есть информация поважнее.

• Пробегитесь по главе 32 «Карьерная лестница» (с. 377), чтобы получить представление о том, как меняются роли на верхних уровнях продакт-менеджмента.

• Изучите обязанности и точки роста для каждого навыка PM, отмеченного знаком

• Прочтите часть 7 «Навыки управления людьми» (с. 313) – это поможет вам в вопросах оптимизации операционной деятельности.

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

Сосредоточьтесь на областях, в которых вы хотите совершенствоваться.

• Изучите раздел «Практики роста» для каждого навыка PM.

• Проверьте, вся ли информация из разделов «Обязанности» и «Концепции и фреймворки» вам известна.

• Загляните в раздел «Обучение на основе обратной связи» (с. 426), чтобы научиться извлекать максимальную пользу из замечаний и комментариев.

Я ХОЧУ ПОЛУЧИТЬ ДОЛЖНОСТЬ PM

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

• Изучите основные навыки в разделах «Навыки работы с продуктом» (с. 43), «Навыки реализации» (с. 131), «Стратегические навыки» (с. 193) и «Лидерские качества» (с. 242).

• Ознакомьтесь с главой 49 «Как получить работу PM» (с. 531), где обсуждаются вопросы на собеседовании.

• И прочтите нашу первую книгу «Cracking the PM Interview: How to Land a Product Manager Job in Technology»[8], в которой основное внимание уделяется подготовке к собеседованию.

Приятного чтения!

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

Не стесняйтесь, пишите нам по адресу [email protected] и следите за нами в интернете:

• twitter.com/jackiebo

• facebook.com/jackie.bavaro

• https://medium.com/@jackiebo

• twitter.com/gayle

• facebook.com/gayle

• https://medium.com/@gayle

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

Одни полагают, что это мини-версия гендиректора. Другие – что это специалист по работе с клиентами. Кто-то считает его неким звеном, объединяющим команду в единое целое. А кто-то видит в нем сходство с дирижером оркестра. Некоторым кажется, что это человек, отвечающий за стратегию, а кому-то – что он занят исследованием пользовательской аудитории и реализацией проектов.

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

Вот наш ответ на вопрос, кто такой продакт-менеджер:

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

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

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

Продуктовая триада

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

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

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

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

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

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

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

Жизненный цикл продукта

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

В реальной жизни эти этапы накладываются друг на друга, происходят не по порядку или повторяются снова и снова. У каждой компании своя версия порядка действий, но общая схема такова:[10]

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

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

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

ИССЛЕДОВАНИЕ ПРОДУКТА

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

Что же пошло не так?

Вы пропустили этап исследования продукта (product discovery) и восприняли распоряжение вашего VP слишком буквально. Нужно было копнуть глубже и разобраться, какая проблема его заботила изначально.

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

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

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

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

Отличным примером такого провала стала война форматов видеозаписи VHS и Betamax в 1970-х годах. Качество изображения у Betamax было явно лучше, но оказалось, что клиентов больше заботила доступность и возможность записать на носитель двухчасовой фильм. Время записи у кассет Betamax ограничивалось всего одним часом. Более тщательная проработка исследования продукта могла бы направить Betamax в нужное русло.

Видеокассеты Betamax и VHS

К стандартным задачам на этапе исследования продукта относятся:

• Изучение запросов на добавление новых функций.

• Анализ показателей воронки продаж.

• Опрос клиентов.

• Тестирование идей.

• Обсуждение долгосрочной стратегии.

• Изучение конкурентов.

• Анализ рынка.

• Проведение мозговых штурмов.

• Запуск дизайн-спринтов (пятидневных сессий, во время которых прорабатываются идеи и тестируются прототипы продукта. – Примеч. ред.)[12].

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

ОПРЕДЕЛЕНИЕ ПРОДУКТА

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

Что пошло не так?

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

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

К стандартным задачам на этапе определения продукта относятся:

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

• Выбор целевого клиента.

• Составление пути клиента (customer journey).

• Определение показателей успеха.

• Создание ви́дения продукта.

• Составление предварительной дорожной карты (roadmap).

• Определение первоначальных сроков.

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

ДИЗАЙН ПРОДУКТА

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

В данном сценарии вы не рассмотрели разные варианты решений и не протестировали бумажные прототипы на этапе дизайна (design phase).

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

К стандартным задачам на этапе дизайна относятся:

• Написание спецификации.

• Определение функционала.

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

• Вайтбординг[13] с дизайнерами и инженерами.

• Предоставление обратной связи по дизайну.

• Исследование юзабилити продукта.

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

РАЗРАБОТКА ПРОДУКТА

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

К стандартным задачам на этапе разработки относятся:

• Составление тикетов (запросов) на разработку.

• Определение показателей, которые следует измерять и отслеживать.

• Расстановка приоритетов по исправлению багов.

• Регулярная помощь коллегам по команде в затруднительных ситуациях.

• Практическая проверка функций по мере их создания и предоставление обратной связи.

• Предоставление актуальной информации стейкхолдерам и руководству.

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

ЗАПУСК ПРОДУКТА

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

Многое на этапе запуска может пойти не так. И именно PM должен проследить за тем, чтобы все прошло хорошо. Ведь вы не хотите в день запуска обнаружить, что продукт полон багов и выводит из строя серверы один за другим. Вряд ли службы продаж и поддержки будут рады изменениям, которые они не смогут объяснить клиентам. И маловероятно, что вам понравится перспектива отправки тысячам клиентов писем с просьбой загрузить приложение, которое еще не доступно в AppStore (Как? Оно же там было!).

К стандартным задачам на этапе запуска относятся:

• Выполнение этапа валидации: догфудинг[14], бета-тестирование, A/B-тесты и тесты на устойчивость.

• Организация процесса обеспечения качества (quality assurance, QA).

• Работа с партнерами и проверка их готовности к запуску продукта (в том числе наличия всех разрешений).

• Сотрудничество с маркетологами по вопросам вывода продукта на рынок.

• Обучение менеджеров по продажам и сотрудников службы поддержки.

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

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

АНАЛИЗ ПРОДУКТА

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

К стандартным задачам на этапе анализа (debrief) относятся:

• Ретроспективная оценка того, что было сделано правильно, а что нет.

• Анализ метрик запуска.

• Изучение отзывов клиентов о запуске.

• Определение очередности «мер быстрого реагирования» на основе обратной связи от клиентов.

• Оценка успешности запуска.

• Информирование всех сотрудников компании о результатах запуска.

• Составление плана дальнейших действий (следующей итерации).

Время и энергия, которые вы потратите на «разбор полетов», помогут вам вырасти как PM и укрепить свой авторитет.

ДРУГИЕ ВИДЫ ДЕЯТЕЛЬНОСТИ

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

С этой точки зрения перед PM встают следующие задачи:

• Подбор кандидатов на вакансии и проведение собеседований.

• Менторство других PM.

• Написание подробных отзывов о работе коллег.

• Участие в таких корпоративных процессах, как постановка целей и подготовка текущих отчетов.

• Обзор спецификаций других PM.

• Ответы на вопросы других команд.

• Презентация продуктов важным клиентам.

• Регулярные встречи с клиентами.

• Обмен полученным опытом.

• Участие в процессах в масштабах всей компании.

• Выступления на общих собраниях.

• Участие в обсуждениях стратегии.

• Участие в отраслевых конференциях.

• Отслеживание передового опыта в области продакт-менеджмента.

Как стать хорошим продакт-менеджером

Хорошие PM – это те, кто создает классные продукты. В начале карьеры вас могут хвалить за развитие навыков и проявление потенциала, но в конечном итоге ваш уровень будет измеряться эффективностью продуктов, которые вы создаете[15].

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

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

На то, чтобы стать хорошим PM, могут уйти годы практики и опыта.

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

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

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

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

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

Вам придется взять на себя больше стратегических обязанностей. Это похоже на выбор между яблоками и апельсинами[16] при прогнозировании развития фруктового рынка. Вы будете браться за несколько проектов одновременно, что вынудит вас идти на серьезные компромиссы (при этом угодить всем заинтересованным сторонам абсолютно невозможно). Все будут требовать от вас roadmap и стратегии. А когда вашу команду попросят взяться за какую-нибудь абсурдно амбициозную задачу, вы зададитесь единственным вопросом: «Где найти для всего этого время?»

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

Примерно тогда вы и почувствуете себя хорошим PM.

Вы сможете расслабиться и наслаждаться успехом или сделать еще один рывок к руководящей должности. Удачи!

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

В первую неделю работы Клэр попросила инженеров из своей команды предоставить ей для ознакомления все, над чем они в тот момент работали. Она знала, что CEO[17] беспокоится о качестве продукции, поэтому тщательно протестировала продукты, выявила десятки багов и внесла несколько предложений по улучшению юзабилити. «Отлично! – подумала она. – Я уже приношу пользу».

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

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

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

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

Она подошла к каждому из коллег и извинилась за то, что торопила события: «Приятно познакомиться. Мы можем начать заново? Расскажите мне немного о себе». Она поговорила со своей командой и узнала, чего от нее ждут. Она встретилась со своим руководителем и составила подробный список того, что нужно сделать, когда и с каким результатом. Затем она забила свой график встречами с клиентами, а в свободное время изучала документы по стратегии и панели мониторинга работы над проектом (дашборды).

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

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

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

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

Выделите время на то, чтобы заложить крепкий фундамент для дальнейшей работы в команде:

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

• Изучите информацию о продукте и о заказчиках.

• Выясните, чего от вас ожидают.

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

• Сформируйте прочные отношения с коллегами.

• Заслужите доверие.

• Одержите несколько «быстрых побед».

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

ПРЕИМУЩЕСТВА НОВИЧКА

У новичка в команде есть огромные преимущества.

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

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

Конечно, у положения новичка есть и свои недостатки; у вас пока нет никакой репутации, и это серьезно осложняет вашу работу. Но не волнуйтесь – вы еще заслужите доверие коллег!

ПЛАН ОНБОРДИНГА НА 30/60/90 ДНЕЙ

В первую неделю или две целесообразно составить план онбординга на 90 дней и обсудить его со своим руководителем.

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

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

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

• Другие PM внутри команды.

• Менеджеры на уровне вашего руководителя.

• Ключевые стейкхолдеры.

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

• Все, с кем полезно познакомиться.

Ниже представлен примерный план онбординга.

Первые 30 дней

HR и знакомство с компанией

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

• Изучить материалы о стратегии и ценностях компании.

PM и команда разработчиков

• Разобраться в процессах.

• Получить доступ к инструментам.

• Узнать о текущих планах и потребностях команды.

• Наблюдать за работой действующего PM.

Наблюдение за действиями своего ментора

• Сидеть с ним рядом.

• Присутствовать на его встречах.

• Следить за тем, как он ведет общение.

Знакомство с коллегами

• Разослать приветственное сообщение.

• Провести вводные встречи один на один.

• Проходить ежедневные пятиминутки с ментором.

• Еженедельно встречаться один на один с руководителем.

Повышение экспертности по продукту и работе с клиентами

• Участвовать в созвонах отдела продаж, выездных встречах и исследовательских сессиях.

• Читать или отвечать на обращения пользователей в службу поддержки.

• Использовать продукт, фиксировать первые впечатления, просмотреть руководство пользователя.

Планируемый результат

• Выполнить стартовый проект: запустить A/B-тест к третьей неделе.

Первые 60 дней

Команда разработчиков

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

Знакомство с коллегами

• Продолжать встречаться с коллегами.

Повышение экспертности по продукту и работе с клиентами

• Продолжать встречаться с клиентами.

Планируемый результат

• Проследить за намеченным на 10 сентября запуском.

• Создать новый квартальный roadmap для команды к 12 сентября.

Первые 90 дней

Команда разработчиков

• Осуществлять руководство командой без контроля со стороны предыдущего PM.

Повышение экспертности по продукту и работе с клиентами

• Продолжать встречаться с клиентами.

Планируемый результат

• Достичь поставленных перед командой OKR.

ВВОДНЫЕ СОВЕЩАНИЯ

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

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

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

Непосредственный руководитель

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

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

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

Примерный список вопросов руководителю:

• Каков ваш стиль работы?

• Какой вы видите нашу совместную работу?

• Как вы предпочитаете общаться: лично или письменно?

• Что вас больше всего раздражает? Что вы любите?

• Каковы ваши главные цели на этот год?

• Как я могу помочь в достижении этих целей?

• Есть ли что-нибудь еще, что я должен о вас знать?

Вопросы о роли и ожиданиях:

• Какой вы видите мою роль?

• Что значит быть хорошим PM?

• Как для вас выглядит успех?

• Чем, по-вашему, я должен заняться в свои первые 90 дней в должности?

• Каковы самые важные ожидаемые результаты?

• Какой проект я должен взять в работу в первую очередь?

• В каких сферах я могу проявить инициативу, а где должен следовать текущему плану?

• Каких подводных камней мне стоит избегать?

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

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

• Существует ли принятая схема продвижения по карьерной лестнице? Могу ли я с ней ознакомиться?

• Есть ли у вас какие-то другие ожидания?

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

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

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

Ментор

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

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

В дополнение к вопросам, описанным выше в разделе «Непосредственный руководитель», вы также можете спросить:

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

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

• Следуют ли сотрудники официальным процедурам? Если они нарушают правила, то когда и почему?

• Действуют ли какие-то негласные правила или культурные нормы?

• Кто является хорошим примером для подражания?

• Состоите ли вы в какой-нибудь группе по интересам с другими коллегами? Можете порекомендовать мне какую-то из них?

Высшее руководство

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

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

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

Вот несколько «безопасных» вопросов для первой встречи:

• Что вы думаете о целях компании?

• Есть ли что-то, что не дает вам уснуть?

• Какая самая сложная задача сейчас стоит перед вами?

• На ваш взгляд, есть ли какие-то конкретные задачи, которые я должен выполнять на данной позиции?

• От чего зависит успех PM в этой компании?

Коллеги по команде

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

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

Знакомство:

• Расскажите о себе. (Вы живете рядом с офисом? Занимаетесь чем-то интересным вне работы? Как предпочитаете развлекаться? Вы любите путешествовать? И т. д.)

• Как вы оказались в этой компании?

• Над чем вы сейчас работаете? Расскажите о своих любимых прошлых проектах. Над чем бы вы хотели поработать?

• Каковы ваши главные цели на этот год?

Согласование ожиданий:

• Какой вы видите нашу совместную работу? Чего вы ожидаете от меня?

• Что вам нравилось и не нравилось в работе с тем, кто занимал мою позицию раньше? Что вас больше всего раздражает?

• Как часто вы хотели бы проводить наши встречи?

• Как вы предпочитаете давать и получать обратную связь?

• Хотели бы вы что-то изменить в моем плане на 30/60/90 дней?

Возможности:

• Что вы думаете о команде? Как продвигаются дела?

• Хотели бы вы что-то изменить в работе команды?

• Что я могу сделать в первую очередь, чтобы помочь команде?

Все остальные

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

Общие вопросы:

• Расскажите о себе.

• Над чем вы работаете? Расскажите о своих любимых прошлых проектах. Над чем бы вы хотели поработать?

• Каковы ваши главные цели на этот год?

• Какой вы видите нашу совместную работу? Что вам нравилось и не нравилось в работе с моим предшественником?

• Могу ли я чем-то помочь вам прямо сейчас?

ЧТО НУЖНО СДЕЛАТЬ

Воспользуйтесь преимуществом новичка и посмотрите на вещи свежим взглядом

Как сказал Брайан Джоуэрс (Bryan Jowers), VP по продукту:

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

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

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

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

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

Заслужите доверие

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

Добейтесь быстрого успеха с самого начала

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

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

Найдите способ почувствовать себя частью компании

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

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

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

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

ЧЕГО ДЕЛАТЬ НЕ СТОИТ

Не стоит с самого начала говорить людям, что они все делают неправильно

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

Не давайте категоричных отказов – скажите: «Да, но…»

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

Не пытайтесь сразу что-то серьезно менять

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обязанности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это заставило нас полностью перестроить наш roadmap. И мы смогли запустить успешный продукт гораздо быстрее, чем ожидалось».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ШУТКА О ГЕНЕРАТОРЕ

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

Вызвали ремонтника. Тот прислушался к тому, как работает установка, и поставил крестик мелом на одной из деталей. «Проблема здесь», – сказал он. Инженеры осмотрели указанное место, поняли, в чем дело, и устранили неполадку. Когда ремонтник выставил счет на $10 000, компания отказалась платить и запросила его расшифровку. Ремонтник с радостью выполнил просьбу и ответил так:

Мел: $1.

Знание, где поставить крестик: $9 999.

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

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

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

РАБОТА, КОТОРУЮ НУЖНО СДЕЛАТЬ (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. Как вы докажете, что IP-адреса соответствуют местоположению людей, если вы не знаете, где именно они находятся?

Вероятно, существует много ответов на этот вопрос. Я поступила так.

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

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

Я подумала, что те же самые пользователи также периодически искали конкретные рестораны или магазины. Теперь вопрос заключался в следующем: когда они искали конкретные адреса, они совпадали с почтовым индексом или с 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, рассказал о том, почему важно повышать эффективность экспериментов:

«Хорошие PM учатся на ошибках… а лучшие меньше ошибаются.

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

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

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

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

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

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

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

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

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

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

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

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

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

Как правило, они представляют данные за неделю или месяц (например, удержание клиентов за первую неделю) или дают разбивку значений на одного клиента (например, средний доход на одного пользователя, или 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-тестирование невероятно полезно, потому что оно дает реальную информацию о том, как люди действуют на самом деле, а не о том, как они, по их мнению, поступят. Оно наиболее точно отображает действительный эффект от вашего продукта.

Такие мелочи, как надпись на кнопке в форме регистрации, могут значительно повлиять на важные показатели, например количество зарегистрировавшихся пользователей. С другой стороны, 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, но и заработала репутацию человека как раз с отличными аналитическими способностями. Хотя это не значит, что я стала экспертом по электронным таблицам или умею мгновенно извлекать смысл из числовых показателей.

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