В «Яндексе» я работал аналитиком. Ко мне приходили с вопросами, я искал на них ответы с помощью данных, а потом делился результатами с командой. При этом я не имел особого влияния на продукт, я не принимал решения, лишь давал советы.
После прихода в Zeptolab моя деятельность изменилась достаточно сильно. Теперь я не только работал с данными, но и влиял на продукты. Спустя некоторое время я начал работать над новой для компании игрой в роли продакт-менеджера. Это была мобильная игра , которую в феврале 2015 года мы запустили на весь мир.
Прошло почти два года, на протяжении которых я совмещаю продуктовую и аналитическую деятельность, так что пора подвести промежуточные итоги и сформулировать, чему я научился за это время.
Каждую неделю я стараюсь выделять время, чтобы обдумать то, что я сделал и что я узнал. По итогам я делаю небольшие заметки с наблюдениями. Эта статья — это обработанные заметки за прошлые два года.
Этот материал опубликован в 2015 году. Рекомендуем начать знакомство с GoPractice с более актуальной серии об основах продакт-менеджмента.
Урок 1. Принимать решения — это сложно
Будучи аналитиком, я изучал данные и давал рекомендации. На этом сфера моей ответственности заканчивалась, финальные решения принимал кто-то другой.
Теперь я сам или почти всегда сам принимаю решения и сам несу ответственность за них. С одной стороны, это то, чего мне так не хватало раньше, с другой стороны, принимать решения оказалось сложно, и вот почему.
Чтобы глубже разобраться в том, как создаются, развиваются и масштабируются продукты, пройдите обучение в GoPractice.
→ Программа «Профессия: продакт-менеджер» поможет вам перейти в продакт-менеджмент из смежной роли или индустрии.
→ В «Симуляторе управления продуктом на основе данных» вы научитесь принимать решения с помощью данных и исследований при создании продукта.
→ В «Симуляторе управления ростом продукта» найдете пути управляемого роста и масштабирования продукта.
→ В «Симуляторе SQL для продуктовой аналитики» поймете, как применять SQL для решения продуктовых и маркетинговых задач.
→ В мини-симуляторе «Генеративный AI для продакт-менеджеров» вы научитесь применять генеративный AI для создания продуктов, решив практический бизнес-кейс.
→ В «Симуляторе управления ML/AI-проектами» научитесь применять технологии машинного обучения с пользой для бизнеса.
→ Не знаете с чего начать? Пройдите бесплатный тест для оценки навыков управления продуктом. Вы определите свои сильные стороны и слепые зоны, получите план профессионального развития.
→ Еще больше ценных материалов и инсайтов — в телеграм-канале .
Во-первых, объективный (выраженный в цифрах) фидбек на твою деятельность приходит с большой задержкой. Часто понять, правильное ты принял решение или нет, можно лишь спустя достаточно длительное время. Сначала надо решить, что делать, потом сделать, потом зарелизить, накопить данные — и лишь тогда можно оценить результат.
Подобный временной разрыв в обратной связи оказался еще и достаточно сложным в плане эмоциональной и нервной нагрузки. Большую часть времени ты находишься в состоянии неопределенности — состоянии очень некомфортном.
Уже длительное время каждое мое утро начинается с проверки цифр. Хорошие цифры поднимают настроение (если изменения сработали и цифры выросли, то это очень крутые ощущения), зато если ты понимаешь, что результата нет и ты впустую потратил силы и время команды, то плохое настроение обеспечено.
Во-вторых, тебе часто приходится принимать решения в условиях ограниченной неполной информации. Не всегда есть возможность накопить достаточное количество пользователей, чтобы получить статистически значимые результаты, а иногда у тебя просто нет возможности проверить свои предположения.
В-третьих, будучи продакт-менеджером, ты решаешь задачи, у которых нет правильного решения. Ты никогда не знаешь, насколько правильным было выбранное направление, даже если результаты улучшились. Возможно, ты движешься к локальному максимуму, а глобальный находится в другом направлении.
В-четвертых, в каком-то смысле намного проще, когда тебе говорят, что делать. В этом случае ты просто делаешь свою работу, а ответственность за полезность потраченного тобой времени автоматически перекладывается на заказчика (хотя будучи аналитиком, я часто был недоволен бессмысленностью вопросов, с которыми ко мне приходили, но хотя бы всегда был тот, кого в этом можно было обвинить). Когда ты продакт-менеджер, то часто встаешь перед дилеммой: «А насколько полезно то, чем я занимаюсь, есть ли способ потратить время с большей пользой?» Более того, твои решения влияют и на то, насколько полезно тратят время другие люди.
Возможность принимать решения — это круто, но, как и во всем, у этого есть своя обратная сторона.
Урок 2. Сакрального секретного знания не существует
Когда-то давно я думал, что у руля успешных компаний и продуктов стоят особенные люди, что они обладают каким-то сакральным знанием, знают, что хорошо, а что плохо, что следует делать, а что нет.
Оказывается, никакого сакрального знания нет. Когда работаешь над продуктом, то еще более отчетливо это видишь. Видишь, что заранее никто не знает, что сработает, а что нет, и корреляции точности предсказаний с занимаемой должностью здесь никакой нет. ДО всегда есть те, кто за и те, кто против, причем все находят логичные доводы в пользу своей позиции. ПОСЛЕ мнения людей достаточно забавно видоизменяются с учетом появившейся дополнительной информации.
Другой аспект отсутствия сакрального знания состоит в том, что никто тебе не подскажет, что правильно, а что нет, что сработает, а что нет. Ты — последняя инстанция. Если ты что-то упустил или о чем-то не подумал, то, скорее всего, никто больше об этом не подумает.
Урок 3. Лучше, когда над продуктом работают несколько человек
В командах, в которых я работаю, на продукт обычно влияют несколько человек. И, с моей точки зрения, это хорошо. Особенно хорошо, когда у этих людей общие ценности и разные дополняющие друг друга профессиональные компетенции.
У людей есть склонность быть слишком лояльными к тому, что они придумали. Наличие других людей, которые не предвзяты к твоей идее, помогает трезво оценить ее, найти все минусы и потенциальные проблемы, выявленные на всех уровнях, а не только в тех аспектах, в которых ты силен.
Это похоже на процесс разработки, когда программист реализует определенную функциональность, а тестировщик проверяет все кейсы в поисках ситуации, где это не будет работать.
Урок 4. Должен быть понятный механизм принятия продуктовых решений
Когда появляется несколько человек, влияющих на продукт, то может начаться перетягивание одеяла, что негативно скажется на работе всей команды. Поэтому должен существовать понятный и прозрачный механизм принятия решений в случае, если взгляды расходятся. А такое бывает достаточно часто.
В случае финальные решения по продукту принимали три человека, включая меня. Если наши взгляды расходились, то решение принималось с помощью голосования.
Урок 5. Продакт-менеджер ≠ генератор идей
Этот урок я выучил у геймдизайнера King of Thieves — Жени Яйленко. Ключевая польза человека, работающего над продуктом, вовсе не сводится к придумыванию идей.
Идеи — это лишь базовый материал для построения и развития продукта. Очень важный материал, но лишь базовый. С этим материалом еще надо хорошенько поработать, чтобы из него получилось что-то дельное.
В идеале придумывать идеи должна вся команда. Даже если вы (продакт-менеджер) хороши в генерации идей, любая увлеченная команда из 10 человек повысит поток идей как минимум в несколько раз. Поэтому вам лучше потратить часть времени на то, чтобы организовывать среду и процесс, где вся команда вовлечена в придумывание идей, а не только вы.
Когда идеи собраны, то именно тут и начинается продуктовая работа. Собранные идеи нужно обработать, развить, приоритизировать, оценить их потенциал, найти пути их максимально дешево и эффективно проверить, найти способы органично встроить их в существующий продукт, учитывая все его особенности, продумать все потенциальные проблемы и подводные камни. Я уже не говорю про детальное описание того, что надо делать, для команды, чтобы потом не приходилось переделывать.
Практически любой продукт — это сложная система. Сложная в том смысле, что в продукте есть множество неочевидных взаимосвязей, и, меняя что-то в одном месте, можно неожиданно испортить что-то в другом. Главная сложность работы с новыми идеями — это поиск путей интегрировать их в существующий продукт, не испортив уже работающих его частей и желательно не создав новых проблем.
Не менее важно добавлять новые вещи в продукт, сохраняя его цельность и логическую стройность. Добавлять новые фичи ценой создания новых сущностей и всевозможных исключений — тупиковый путь.
Еще один негативный аспект собственных идей — предвзятость к ним. Собственные идеи всегда кажутся лучше, чем они есть на самом деле. Поэтому, работая над продуктом, надо учиться объективно смотреть на вещи и критично оценивать свое творчество, хотя это совсем не просто.
Урок 6. Тестируйте ключевые вещи как можно раньше и как можно дешевле
Это очень очевидное утверждение, про которое вы, наверняка, читали в разных модных книгах, вроде Lean Startup. Но когда дело доходит до реальной разработки, то часто об этом забываешь. Ты слишком сильно увлечен и уверен в своем продукте, чтобы что-то там тестировать (обычно эта уверенность быстро проходит после первого запуска, поэтому не тяните с ним). Давайте рассмотрим пару примеров.
Если вы делаете мобильную игру, то логично, что ее будут качать из аппстора. Если ее будут качать из аппстора, то одной из важных метрик будет конверсия на уровне магазина приложений. Какая часть пользователей из тех, кто попал на страницу вашего приложения в аппсторе, в итоге скачают его?
Чтобы протестировать этот важный аспект вашего продукта, не надо ни программировать, ни даже детально продумывать продукт. Достаточно нарисовать скриншоты, придумать описание для несуществующей игры и протестировать их с помощью одного из сервисов вроде .
Если вы хотите добавить в игру мультиплеер, то опять же совсем не обязательно его реально делать. Особенно если ваша задача в том, чтобы понять, как он повлияет на продукт и ключевые метрики, а не в том, чтобы дать команде сложную техническую задачу.
Для проверки будет достаточно создать для пользователя ощущение, что он играет против реальных соперников. Это на порядок дешевле, чем делать полноценный мультиплеер. Если все сработает и вы получите результаты, которые оправдывают разработку этой фичи, то тогда можно инвестировать в нее время и ресурсы разработки. Если же результаты не оправдают ожиданий, то вы сэкономите кучу времени.
Но проблема в том, что когда ты «творишь» продукт и несешь за него ответственность, то трезвость мышления резко пропадает. Ты становишься уверен, что мелкие незначительные вещи могут кардинально повлиять на опыт пользователя и на ключевые метрики. За редкими исключениями это не так.
Урок 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. Ритм важнее
Частые релизы — это хорошо. Многие в это не верят, ведь хочется довести продукт до идеального состояния прежде, чем выдать пользователю. Но в большинстве случаев это лишнее. Я сам раньше был таким, но сейчас исправляюсь.
Во-первых, пользователь, скорее всего, не заметит принципиальной разницы между вашим «хорошо» и «очень хорошо», а часто даже между «нормально» и «хорошо». А вам подобный полишинг будет стоить много времени.
Во-вторых, если то, что вы сделали, не заработает, то какой смысл вкладываться в доведение этого до идеального состояния?
В-третьих, то, что вам кажется важным перед релизом, уже через пару дней после вам будет казаться надуманной проблемой. Релиз откроет вам истинные проблемы.
В-четвертых, ритм слишком важен, чтобы жертвовать им в пользу раздувания скоупа и допиливания мелких деталей. Поясню почему.
Частые релизы важны для команды как с эмоциональной точки зрения (зарелизить продукт всегда приятно), так и с точки зрения качества итогового результата.
Во-первых, вы не строите воздушные замки на воздушном фундаменте. Вы относительно быстро получаете обратную связь на сделанные изменения, что позволяет вам твердо стоять на земле и принимать достаточно объективные решения.
Во-вторых, если сделанные фичи в каком-то виде заработали, то часто из-за вечно мешающего нашим планам реального мира они все равно требуют изменений и доработок.
В-третьих, подобный процесс, когда новые фичи релизятся постепенно, позволяет делать намного более устойчивые и стабильные приложения. Проблемы находятся и решаются на ранней стадии, не разрастаясь и не поражая большую часть продукта.
В-четвертых, так вы быстрее и лучше учитесь. Если вы добавили три больших фичи, то оценить влияние каждой из них очень сложно. Если лишь одну, то когортный анализ позволит вам быстро определить ее влияние на ключевые метрики.
Поэтому если после того, как итерация запланирована, начинает разрастаться скоуп (все равно почти никогда не получается все предусмотреть), то новые и старые задачи надо заново приоритизировать и то, что не помещается в сроки, переносить на следующую итерацию.
Причем под новыми задачами я понимаю лишь неучтенные детали по уже запланированным вещам. Совсем новые задачи лучше сразу перекидывать на следующий апдейт.
