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

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

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

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

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

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

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

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

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

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

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

Один из самых запоминающихся наборов правильных показателей – тот, что Дейв Макклюр (Dave McClure) назвал «пиратскими метриками» (в английском языке первые буквы их названий образуют забавную аббревиатуру AARRR)[32]32
  Для получения дополнительной информации см. https://www.slideshare.net/dmc500hats/startup-metrics-for-pirates-long-version.


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

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

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

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

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

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


[Закрыть].

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

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

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

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

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

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

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

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

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

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


[Закрыть]. Однако все еще существует вероятность в 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]35
  Если понятнее не стало, представьте игральный кубик с 20 гранями, пронумерованными от 1 до 20. Я предсказываю, что если его бросить, то выпадет число 13. Будет круто, если я угадаю, да? Но если я брошу кубик еще 100 раз, а 13 выпадет только раз или два, будет уже не так впечатляюще.


[Закрыть].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 6
Аналитический подход к решению задач

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

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

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

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

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

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

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

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

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

ВНЕСТИ ЯСНОСТЬ

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

Лили Раховин (Lili Rachowin), PM-лид в Asana, взяла на себя ответственность за процесс принятия решений. На обсуждении вопроса она представила таблицу, в которой были собраны все известные факты и цифры, а также некоторые новые данные, которые мы еще не рассматривали. Она утверждала, что, поскольку это был первый перевод, наиболее важным фактором была готовность клиентов спокойно относиться к ошибкам в нем. Раньше эта мысль нам в голову не приходила, но мы с ней согласились. Предложение Лили было незамедлительно одобрено.

Раховин внесла ясность в неоднозначную проблему.

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

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

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

• Улучшением каких показателей нам стоит заняться?

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

• Как увеличить доход?

• Как увеличить объем использования этой функции?

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

• Почему графики показали падение показателей в определенный день?

В целом эти и другие неоднозначные проблемы можно разделить на два основных типа:

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

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

Давайте рассмотрим и те, и другие.

Поиск решений

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

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

Например, проблему «Как увеличить доход?» можно разбить на следующие составляющие:

• Новые и существующие клиенты: как увеличить число платежеспособных клиентов или как заставить существующих пользователей платить больше?

• Размер ставки: какие небольшие оптимизационные мероприятия и крупные инициативы вы можете предложить?

• Источники дохода: как повысить доход от подписки и от рекламы?

• Тип клиента: как увеличить доход с каждого пользователя и пользовательского профиля?

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

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

• Географический фактор: зафиксированы ли изменения в разных странах?

• Линейка/область продуктов: наблюдалось ли снижение показателей по всем нашим продуктам (или по всем компонентам нашего продукта) или оно было локальным?

• Воронка: отмечался ли спад только в одной части воронки?

• Источник: исходила ли причина падения показателей от какого-то конкретного реферального источника?

• Тип клиента: затронуло ли изменение только пользователей какого-то одного типа?

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

Принятие решений

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

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

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

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

• Низкий или высокий риск.

• Низкий или высокий уровень инвестиций.

• Краткосрочная или долгосрочная выгода.

• Ориентированность на рост или на доход.

• Проектировать или покупать.

• Любое другое распределение по группам.

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

Дополнительные подходы к структурированию проблем описаны в разделе «Концепции и фреймворки» на с. 84.

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

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

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

ПОМОГАТЬ В СОРТИРОВКЕ И ВОСПРОИЗВЕДЕНИИ БАГОВ

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

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

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

• Ущерб для пользователей: может ли баг нанести серьезный или долгосрочный ущерб пользователям? Не возникнет ли риск нарушения безопасности или конфиденциальности их данных? Могут ли они потерять данные?

• Ущерб для компании: может ли баг нанести крупный или долгосрочный ущерб компании? Может ли это серьезно навредить ее репутации?

• Влияние на показатели: оказывает ли баг серьезное воздействие на ключевые показатели компании? Влияет ли на затраты или доходы? Вредит ли привлечению, активации, удержанию, доходу или рекомендациям (модель AARRR)? Является ли он причиной большого количества обращений в службу поддержки?

• Масштаб воздействия: скольких пользователей затронул этот баг? Пропорционально ли он повлиял на важных (платежеспособных или крупных) клиентов? Больше или меньше пользователей он затронет в будущем?

• Обходные пути: существуют ли способы обойти баг? Найдет ли пользователь обходной путь самостоятельно?

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

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

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

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

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

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

СИСТЕМНОЕ МЫШЛЕНИЕ

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

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

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

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

Вот некоторые типы взаимосвязей, о которых полезно помнить:

• Циклы обратной связи: будут ли полученные сейчас результаты использоваться в качестве вводных данных на следующем этапе?

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

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