Уроки по пути из аналитика в продакт менеджеры (часть 1)

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

После прихода в Zeptolab моя деятельность изменилась достаточно сильно. Теперь я не только работал с данными, но и влиял на продукты. Спустя некоторое время я начал работать над новой для компании игрой в роли продакт менеджера. Это была мобильная игра King of Thieves, которую в феврале 2015 года мы запустили на весь мир.

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

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

Вторая часть статьи.

Также призываю вас поделиться своим опытом в комментариях.

продакт менеджер King of Thieves

Урок 1. Принимать решения – это сложно

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

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

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

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

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

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

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

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

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

 

Урок 2. Сакрального секретного знания не существует

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

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

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

 

Урок 3. Лучше, когда над продуктом работают несколько человек.

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

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

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

 

Урок 4. Должен быть понятный механизм принятия продуктовых решений

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

В случае King of Thieves нас было три человека, кто принимал финальные решения по продукту. Если наши взгляды расходились, то решение принималось с помощью голосования.

 

Урок 5. Продакт менеджер != придумыватель идей

Этот урок я выучил у геймдизайнера King of Thieves – Жени Яйленко. Ключевая польза человека, работающего над продуктом, вовсе не сводится к придумыванию идей.

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

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

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

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

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

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

 

Урок 6. Тестируйте ключевые вещи как можно раньше и как можно дешевле.

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

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

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

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

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

Но проблема в том, что когда ты “творишь” продукт и несешь за него ответственность, то трезвость мышления резко пропадает. Ты становишься уверен, что мелкие незначимые вещи могут кардинально повлиять на опыт пользователя и на ключевые метрики. За редкими исключениями, это не так.

 

Урок 7. Слова “lean”, “data-driven” и “эксперимент” – не оправдание для бездумного тестирования всего подряд.

“Эрик Райс как-то сказал, что самый популярный способ извратить метод Lean Startup – это беспорядочно бросать любое г…но об стену, надеясь что что-то прилипнет” – как-то написал в своем фейсбуке Аркадий Морейнис. Не знаю, говорил ли это Эрик Райс или нет, но фраза замечательно отражает суть этого пункта.

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

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

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

Мы долго разрабатывали King of Thieves, много итерировали и экспериментировали по пути, но:

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

2. Приток новых пользователей ограничивает число экспериментов, которые вы можете провести. Для каждого эксперимента нам требовалось как минимум по 1000 пользователей (чаще больше) на каждый из альтернативных вариантов. При стоимости скачивания мобильного приложения на уровне 3-4$ на развитых рынках, вы можете оценить во сколько обходятся эксперименты.

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

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

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

 

Урок 8. Сначала машина должна поехать.

Когда вы создаете продукт с нуля, то главное испытание на первых этапах – найти что-то, что заработает (некоторое предверие product/market fit).

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

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

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

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

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

 

Урок 9. Продукт – это не набор фичей.

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

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

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

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

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

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

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

 

Урок 10. Ритм важнее.

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

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

Во-вторых, если то, что вы сделали, не заработает, то какой смысл вкладываться в доведение этого до идеального состояния?

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

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

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

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

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

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

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

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

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

 

Продолжение вышло в свет

Это первая часть статьи.  Чтобы узнать о выходе следующей части статьи присоединяйтесь к Facebook группегруппе ВконтактеТвиттеру или подписывайтесь на рассылку по почте.

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

 




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

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



Запись опубликована в рубрике Без рубрики, Маркетинг, Менеджмент, Мобильная разработка, Предпринимательство. Добавьте в закладки постоянную ссылку.
  • Спасибо за отличную статью!

    • Олег Якубенков

      Пожалуйста!

  • Victor Nedilko

    Спасибо. Очень интересно и информативно

    • Олег Якубенков

      Пожалуйста, скоро будет вторая часть

  • Leon Artamonov

    Понравилось сравнивать написанное со своим опытом. Согласен почти с каждым пунктом – все очень похоже на правду.
    С каждым новым постом блог становится все интереснее =)

    • Олег Якубенков

      Спасибо, рад, что понравилось

  • krendel122

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

    • Олег Якубенков

      По поводу оценки потенциала идей.

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

      В большинстве случаев задачи будут попадать в следующие категории:
      1) привлечение пользователей
      2) удержание пользователей
      3) монетизация пользователей
      4) повышение виральности (можно в 1 отнести тоже)

      Дальше вы берете идеи и оцениваете диапазон ее влияния на конкретные метрики.

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

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

  • Konstantin Gavrilenko

    Выписал тезисы, которые нужно периодически перечитывать. Спасибо!

  • Алла Храмцова

    спасибо, Олег! Готова подписаться под каждым тезисом. Я вот несколько сомневалась, правильный ли я продвигаю подход в разработке наших продуктов, когда решения по нему принимает не один человек, а 2-3. Казалось, что это размывание ответственности, хотя именно так получается находить наиболее интересные решения и поддерживать мотивацию команды. Ваши аргументы теперь окончательно убедили, что всё ок :)

    • Олег Якубенков

      Все именно так и есть :)

  • Dmitry Zlokazov

    Спасибо! Развейте плиз мысль, не совсем понял:

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

    • Олег Якубенков

      Дмитрий, добрый день
      Хороший вопрос, но на него достаточно сложно абстрактно ответить

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

  • Renat Abyasov

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

    Ведь если отбросить душевные страдания и самобичевание, что останется?

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