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

Два основных блока:

1. Откуда взять идею (фидбек, метрики, конкуренты).
2. Как выбрать нужную идею, приоритизация.

Как происходит процесс

Выстраиваем иерархию целей. На верхнем уровне находятся:

1. Цели компании: чего на данный момент хочет компания (владельцы, стратегический менеджмент), в том числе, от вас, как от одного из руководителей. Далее, у компании есть набор сервисов, внутренних или внешних, и следующий уровень —
2. цели и метрики конкретного сервиса, который вы представляете. На третьем уровне определяем
3. идеи под цели и метрики сервиса – фичи, которые хотели бы реализовать, и которые скоррелированы с метриками вашего сервиса. Этапы:
   
   а) сбор,
   б) категоризация,
   в) приоритизация.
   
   После этого получаем
4. планы по релизам, которые уже отправляем в разработку.

1. Цели компании

Цели меняются с ростом продукта. Продукт проходит несколько стадий (от зарождения до стагнирования), и на каждой стадии фокусные метрики меняются вместе с целями.

1 стадия: хороший продукт

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

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

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

2 стадия: хороший рост

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

• привлечение – насколько хорошо приходят новые пользователи,
• referral — как хорошо текущие пользователи приводят своих друзей,
• A/B – тест — вы увидели, что 100 человек зашли на страницу, и только 2 совершили целевое действие, тогда вы что-то меняете и 50 человек отправляете на старую версию, а вторую половину на новую, и сравниваете,
• оптимизация конверсии — работа с воронкой платных лидов,
• тестирование различных каналов и аудитории.

Это стадия перестройки продукта от аудитории начинающих к массовому пользователю.

3 стадия: монетизация

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

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

Важно понимать, на каком этапе находится ваша компания.

2. Цели и метрики сервиса. Являются частью целей компании

Теперь, смотрим, как соотнести цели компании и цели конкретного сервиса. В качестве примера возьмём видеосервис ВКонтакте. Сама компания находится на третьей стадии, ключевые цели компании:

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

Под эти метрики компании мы подстраиваем метрики видеосервиса, это:

1. монетизация видео и
2. среднее время просмотра видеозаписи.

В целом, это можно визуализировать – применяется инструмент иерархия метрик.



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

Из вариантов активностей пользователя конкретно к нашему видеосервису относится время просмотра видео. Что влияет на эту метрику сервиса, от чего зависит время просмотра видео среднего пользователя? Оно зависит от того:

1. сколько видеозаписей пользователь посмотрел сегодня и
2. длительность просмотра каждой видеозаписи, в среднем.

Это уже метрики первого уровня. Спрашиваем себя, что влияет уже на эти метрики, например, на длительность просмотра влияет:

1. длительность видео и
2. % досмотра каждого видео.

Это уже метрики второго уровня.

Далее, каждую из метрик расписываем вглубь, разбиваем на составные метрики, которые детализируют составные части сервиса. Запуская фичу, мы уже сможем видеть, на какую метрику она повлияет напрямую. Допустим, запустили качество 1080 для видео. Это метрика качества видео, она влияет на качество контента, что, в свою очередь, повлияет на длительность просмотра и, следовательно, на активность пользователя. 2 уровень влияет на 1 уровень, а 1 влияет на метрики сервиса – направление именно такое.

Дополнительные моменты:

1. Схему рисуем вместе с руководителем и аналитиками. Это можно делать при помощи MindMaster или Mind42 – и там, и там можно работать онлайн вместе с командой.
2. Если продукта ещё нет, кажется, что иерархию делать не надо? Надо, ведь мы решаем, какие функции в нём будут нужны – иерархия метрик особенно актуальна!
3. Если компания большая, а продукт 25 уровня – расписываем все 24 уровня от глобал до уровня сервиса, и потом уже расписываем конкретно уровни продукта.
4. Если продукт новый – важно не угадать числа и значения метрик, а понимать, откуда возьмутся деньги, и какие действия будут происходить. Если это интернет-магазин – будут заказы, будут заходы в каталог, добавления в корзину и т.д. Для каждого экрана нового сервиса нужно сказать, какая там ключевая метрика –нужна иерархия метрик.
5. Чтобы понять какая именно фича повлияла на метрики – пригодится A/B-тест.
6. Качественные метрики лучше переводить в количественные, по возможности.
7. Метрики можно заимствовать от бизнесов из других отраслей, со схожими воронками.

3. Идеи под цели и метрики

А. Сбор идей. Откуда брать идеи

1. Пользователи: они есть, они в курсе продукта, и они хотят что-то от продукта получить.
2. Команда: долго живет на проекте, долго слушала пользователя, и, по-хорошему, является одним из пользователей сервиса, который мы создаём.
3. Конкуренты, другие рынки, ребята из нашей области: можно подглядеть, подумать, почему они делают то или иное, какие фичи запускают.

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

Как можно с ними общаться, какие есть инструменты. Основные:

— Фидбек, который прилетает в обратной связи: в мэйлах, звонках, сообщениях в техподдержку, и который обрабатывается и, в идеале, структурируется в компании.

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

— Тулы:

• Userbrain.net (закупаете трафик – пользователь получает задание, и вы можете смотреть, как он используют продукт, понимать, насколько хорошо он справляется с кейсами и получать моментальную обратную связь,)
• Flinto.com (рисуете в фотошопе прототип, закидываете в тул и проставляете кликабельные области – наблюдаете за поведением)
• UserVoice (ставится на сайт и собирает фидбек: люди голосуют за фичи, и популярные поднимаются наверх)
• KanoSurvey (приоритизация фичей)
• optimizely.com (A/B эксперименты)
• wootric.com (опросы на сервисе)
• Отзывы и форумы
• Обзвон (мессенджеры, Skype)

Что нужно понимать на данном этапе?

• Важно не только получать обратную связь от пользователей, но и давать им обратную связь – запускать цикл обратной связи, когда пользователь вам что-то предложил, вы это услышали, зафиксировали, и ответили пользователю. Можно это делать как публично, так и лично, главное, дать понять, что вы учитываете пожелания, иначе поток фидбека со временем иссякнет – так что важно поддерживать канал и относится к нему бережно.
• Будьте готовы, что нее все рады фичам (большинство не рады). Что с этим делать?
  
  
  1. если фича небольшая – внедрять её нужно мягко, не ломая сценарий пользователя;
  2. если большая — готовить людей заранее, открытость вам только в плюс. Даже для больших изменений обычно достаточно 15-20 касаний продукта пользователем.

Есть качественные и количественные методы сбора информации от пользователей.

Качественные методы 10-20 человек:

• фокус-группы — собираем 5-10 пользователей для работы в группе и смотрим, как они обсуждают, — способ помогает выиграть в скорости получения информации
• наблюдения — при запуске прямых трансляций ВК выдавали пользователям телефон и смотрели, как они себя ведут, что получается и не получается, что обсуждают друг с другом, а также, полезен
• CustDev (интервью + UX) – показываем продукт и просим пользователя прогнать несколько кейсов, или когда нет продукта – тестируем проблематику и спрашиваем, как он раньше решал свою проблему.

Количественные методы 100-1000 человек.

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

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

Чем качественные методы отличаются от количественных исследований? Во-первых, тут разные цели; во-вторых, качественные более быстрые. Гораздо быстрее опросить десять людей и получить фидбек, который, скорее, расширит воронку идей, однако, на основании 10 человек принимать какое-то решение – неправильно, так как, выборка незначительная. Зато, можно подсмотреть нестандартные идеи, о которых вы не думали и которые нужны, возможно, другим пользователям. Количественные же методы – это больше про сужение и определение. Они делаются на большом масштабе, и им уже можно доверять.

Идеи команды

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

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

У нас есть ключевые цели, удовлетворяющие принципам SMART, и понимание, что мы хотели бы сделать со своим сервисом. Например, увеличить число просмотров видео на 30%, тогда задаём себе вопрос:

• кто? Кто во всём мире, необязательно в команде разработки, может повлиять на эту цель? Часто на этом этапе мы кого-то упускаем. Задав вопрос, можно обнаружить, что влияет маркетинг и авторы блогов. Расширили число групп влияния на метрику. Далее:
• как, каким способом они могут на это повлиять? Авторы могут заливать чаще контент. Они могут рассказывать своим коллегам. После этого уже смотрим,
• что мы можем сделать для этого? И расписываем, какой следующий шаг. Чтобы авторы чаще заливали контент, возможно, стоит сделать отложенный постинг, когда они подготовят много видеозаписей, и потом, когда будут заняты – им можно будет не пропускать публикацию своих готовых постов. Если хотим, чтобы они делились с коллегами, надо сделать для них, например, доступную статистику, чтобы они могли ею поделиться и т.д.

Идеи от конкурентов, их пользователей и с других рынков

Составляем список конкурентов. Где их посмотреть? Источники:

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

Ещё есть пара инструментов для слежения за новостями и конкурентами.

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

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

Третья история про открытые отчёты, которые публикуют все публичные компании. И если кто-то из ваших конкурентов – публичная компания – то можно за ними подглядывать. Например, по теме прямых трансляций представлял интерес один китайский видео-дейтинг-сервис, Момо. В их финансовой отчетности было видно, как компания зарабатывала каждый год стабильно немного, а потом внезапно в 16 году резко заработала много — оказалось, они встроили себе фичу, которая принесла много денег. Полезно узнать о таком – можно проследить механики, которые конкуренты внедрили и которые принесли им существенный доход.

Б. Категоризация

Составляем таблицу с фичами.



Мы определили ключевые метрики из иерархии, которые хотим прокачивать: кол-во просмотров, авторов, уникальные зрители и время просмотра. Теперь, по каждой метрике в таблице определяем количественный показатель, который мы хотим получить по метрике и, далее, раскладываем идеи/проекты из пула по выбранным метрикам, делая развесовку по проектам. Затем, нужно провести приоритизацию фич, составить план по месяцам и определить, что из них пойдёт в ближайший релиз.

В. Приоритизация

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

1 шаг. Быстрая приоритизация.

Для быстрой – полезен инструмент poker planning. Польза против трудозатрат.

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

Есть ещё более долгий формат быстрого способа — больше факторов, которые нужно просчитать, используется дополнительно – rice scoring.



По столбцам вписываем

• проект / фичу,
• количество людей, которых затронет эта функциональность — Reach,
• насколько для них это будет полезно, от 1 до 3 – Impact,
• насколько вы уверены в этой идее – Confidence, в процентах, и
• затраты со стороны разработки, в часах или днях, — Effort, и считаем Rice score – путём умножения первых трех показателей друг на друга и деления их производного на затраты.

Смотрим, какая из фичей вылетает в топ. Из 50-100 останется 10-15.

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

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

2 шаг. Медленная приоритизация.



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

1. Составляем формулу оценки прибыльности фичи, закладываем количество людей и денег. Коэффициенты, которые мы точно не знаем, например, сколько людей попробуют новую фичу, мы выделяем жёлтым – их прогоним через вероятности.
2. При помощи экспертов или коллег прикидываем сценарии для пессимистичного, реалистичного и оптимистичного вариантов исхода – что произойдет, и какова вероятность, что произойдёт именно так – после чего считаем среднюю величину, и подставляем в формулы, уже понимая, сколько фича принесет с учетом вероятности.
3. Оцениваем стоимость разработки.
4. Считаем ROI, и если он нас устраивает, заносим фичу в план релиза по месяцам.

Резюме по приоритизации

1. Выбираем топ 3 ключевые метрики, на месяц или на квартал, видим, что эти метрики влияют на деньги и понимаем, что можем прокачать эти метрики.
2. Собираем гипотезы для их прокачки (пользователи, аналитика, команда, конкуренты).
3. Если рынок новый и аналитики нет – больше делаем акцент на качественный метод, общаемся с пользователями и смотрим на конкурентов.
4. Делаем быструю оценку и отбрасываем слабых кандидатов.
5. Делаем детальную оценку оставшихся кандидатов (например, по ROI).

На этом, основной материал подошёл к концу. Далее, мы подготовили для вас интересные вопросы и ответы, не вошедшие в текст.

Вопросы и ответы

• Как выкручиваться, если CEO и инвесторы хотят доработку, а я знаю, что проект не взлетит? – 1) пообщаться детальнее и понять их мотивы; 2) предложить альтернативу, которая может быть полезна и вам и им 3) пройтись вместе по модели rice score.
• Как быстро можно увидеть эффект от запуска новой фичи? – Зависит от того, какую фичу вы внедряете, если делаете что-то для улучшения позиции сайта в поисковиках – раньше чем через две недели бессмысленно. А если функциональность, которую пользователи увидят моментально – то сразу. Может быть и такое, что в краткосрочном периоде увеличится глубина, а в долгой перспективе пользователи начнутт отказываться. Мерить нужно не только краткосрочно, но и вдолгую. Срок удлиняется, когда мы фичей хотим переучить пользоваться. Привыкание может длится пару месяцев.
• Как рассказывать про продукт внутри компании? – Внутренний блог, в котором регулярно освещаем: что делаем, зачем делаем, как делаем. Коммуникация есть периодическая, а есть регулярная. Есть механизм рассылок – это оперативная коммуникация. Может быть что угодно: рассказы, отстраненные в виде отчета либо живые – объявления, развешенные по офису, посиделки с пирожками.
• Для подсчёта объёма аудитории по каждой фиче требуется огромное количество времени, как вы с этим живёте? – Оценка может быть долгой только в начале, затем драйверы все уже видны и легко считаемы, и работает накопительный эффект. Можно, задав себе ряд вопросов, просчитать пессимистический вариант и дальше уже прикидывать. Один раз разработал Фреймворк – потом есть эксель, где всё просчитывается. Главное, задавайте себе вопрос: что я могу сделать, чтобы в следующий раз всё было быстрее. Ни один план не высечен в камне – всё постоянно меняется, нужно быть готовым регулярно переприоритизировать.
• Методы проверки гипотез? – Опросы, черновые прототипы.
• Если нет целей? – Надо придумать.
• Как мотивировать внешних тестировщиков? – 1. Признание от вашей команды. 2. Определённая тусовочка прикольных ребят. 3. Если вы топ – возможность попасть к вам в штат будет мотивацией. 4. Сувенирка. 5. Внимание, в обмен на профессионализм.