В первой части материала мы начали обсуждать уроки, которые я выучил за последние два года работы в роли продакт-менеджера игры .
Давайте продолжим.
Этот материал опубликован в 2015 году. Рекомендуем начать знакомство с GoPractice с более актуальной серии об основах продакт-менеджмента.
Урок 11. Ваш продукт должен начать жить как можно раньше
На протяжении первого года разработки , в конце каждой недели игра выкладывалась на Testflight, а потом мы всей компанией играли в нее на выходных. В понедельник мы встречались и обсуждали результаты итерации, что понравилось, а что нет.
Позже мы запустили игру на одном небольшом рынке и получали обратную связь уже не только от сотрудников компании, но и от реальных игроков.
Очень важно, чтобы продукт, который вы разрабатываете, начал жить как можно раньше, чтобы его начали использовать реальные люди. Это помогает и в плане генерации идей, и в плане понимания продукта, и в плане стабилизации приложения с технической точки зрения.
Запускаться надо как можно раньше. Если продукт не готов к публичному запуску, то запустите его в закрытой бете. Если не готов к закрытой бете, то запустите внутри компании и используйте сами.
Урок 12. Не забывайте о пользователях
Иногда за метриками и прочими вещами мы забываем, что создаем продукты для пользователей. Обратите внимание на какое-нибудь обсуждение, где вы говорите о монетизации, о Retention, о технических сложностях, о планах по доходам, но ни слова не говорите о ваших пользователях, о том, что важно для них.
В «Яндексе», например, часто говорят о пользователях. Есть даже специальный термин — «счастье пользователя». И по задумке все должны работать на это счастье. Только вот порой «счастье пользователя» становится просто словами без смысла, которые используют вместо того, чтобы об этих пользователях реально подумать.
Не забывайте ставить себя на место пользователя, не забывайте, для кого вы делаете то, что делаете.
Урок 13. Метрики продукта можно улучшить на порядок
Я раньше не верил, что метрики продукта можно улучшить на порядок. Не верил, потому что своими глазами ни разу не видел подобных примеров.
Но теперь я знаю, что это возможно. Мы с командой улучшили ключевую метрику King of Thieves (на момент написания статьи) примерно в 40 раз с момента первого релиза.
И да. В первой версии были инапы, более того, она была очень похожа на ту игру, которую вы увидите, скачав сейчас. Просто нам потребовалось время, чтобы собрать отдельные части игры в цельную и рабочую систему.
Урок 14. Не забывайте попап Rate me
Как ни странно, но суть этого урока не в том, чтобы не забывать добавлять попап Rate me, а в том, что фидбек пользователей будет очень сильно влиять на вас. Позитивный даст вам сил и энергии двигаться дальше, негативный же испортит настроение и подтолкнет к неправильным эмоциональным решениям.
Те, кто чем-то недоволен, чаще идут писать отзыв, чем те, кому все нравится. Поэтому показанный в правильный момент попап Rate me направлен, в первую очередь, на тех, кому все нравится.
Перед релизом King of Thieves из-за ограничений по срокам, мы вынуждены были выбирать, что делать, а что нет. Поэтому в первую версию King of Thieves на iOS попап Rate Me не был добавлен.
В итоге средняя оценка для ряда крупных рынков оказалась на уровне 3,5. В потоке отзывов, который приходил в специальный канал в Slack, часто попадался негатив, что сильно влияло на настроение команды, а также на принимаемые нами решения. Даже несмотря на то, что цифры по вовлечению и возвращаемости были очень хорошими, запуск был подпорчен пользовательским негативом.
В Android и в китайскую версии приложения мы успели добавить попап Rate Me. Средняя оценка для них в итоге составила 4,5 звезды (добавленный попап — единственное изменение).
После добавления попапа Rate Me в апдейте iOS версии оценка в новой версии также подскочила до 4,5. Число позитивных отзывов в Slack резко выросло, а негативные затерялись на их фоне.
Будьте готовы, что негативные отзывы ваших пользователей вполне могут испортить вам настроение и подтолкнуть к неправильным решениям. Так что заранее настройтесь не принимать их близко к сердцу (это не значит, что их надо игнорировать), а также не забывайте добавлять попап Rate me в ваши приложения.
Урок 15. Казалось бы, все в твоих руках, но нет
Продукт — это сложная система. Воздействуя на какую-то из ее частей, ты часто с большим трудом можешь предсказать результат подобного воздействия, из-за большого числа взаимозависимых циклов обратных связей. В итоге, несмотря на то что ты создаешь этот продукт, часто ты не знаешь, как повлиять на определенные его аспекты.
Например, King of Thieves — это многопользовательская игра с более или менее реальной экономикой. Несмотря на то что мы детально вымеряли и тестировали внутреннюю экономику игры во время софт-лонча, в момент запуска все пошло совсем не по плану. Резкий приток пользователей создал дефицит золота в игре. Казалось бы, в чем проблема? Надо всего-то добавить золота в игру.
Но в реальности у тебя есть лишь косвенные инструменты воздействия на мир продукта. Более того, ты плохо можешь просчитать то, какой эффект окажут твои изменения (ведь можно неожиданно создать избыток золота, что ничем не лучше). В итоге мы правили баланс на лету и в риалтайме внимательно следили за ключевыми показателями, характеризующими экономику игры (благо Mixpanel позволяет это делать).
Теперь я отчетливо понимаю, насколько сложно, например, управлять компанией или страной, где у тебя нет ни возможности моментально воздействовать на рычаги управления, ни возможности быстро получать обратную связь с результатами этого воздействия.
Урок 16. Маленькие и большие ошибки
В свете прошлого пункта хочется немного поговорить про ошибки. То, что я понял про ошибки, — они неизбежны, но у них есть забавная особенность.
Большие ошибки в маленьком продукте — это все еще маленькие ошибки. Зато маленькие ошибки в большом продукте — это большие ошибки.
Продукт с несколькими тысячами пользователей дает тебе на порядок больше свободы, чем продукт с миллионной аудиторией. Поэтому не торопитесь масштабироваться. Лучше совершите побольше ошибок, пока вы маленькие.
Урок 17. Продукт есть произведение его отдельных частей, а не сумма
Вы можете создать продукт с очень высоким Retention и замечательной монетизацией, но если рынок этого продукта мал, то на выходе вы получите примерно ничего.
Вы можете создать продукт с высоким Retention, нацеленный на огромный рынок, но не найти каналов его распространения — в итоге опять будет ничего.
Вы можете создать виральный продукт на большом рынке, но если у него плохой Retention, то вы быстро всех растеряете и на выходе получите 0.
Ваш продукт — это не сумма его отдельных частей, а их произведение. Если где-то 0, то несмотря на все остальные его части, на выходе тоже будет 0. Поэтому одна из ваших ключевых задач как продакт-менеджера — четко понимать, где сейчас узкое место вашего продукта (а их может быть и несколько). И именно исходя из этого понимания строить приоритеты и планы.
Когда вы разрешаете одно из узких мест, то обычно появляется новое дальше по воронке, а порой спустя время старая проблема вновь начинает себя проявлять (например, если выросла стоимость привлечения).
Редко удается удалить узкое место в один подход. Чаще работа над узкими местами требует под собой процесса. Именно этот процесс во многом определяет вектор развития продукта.
Урок 18. У вас должен быть план, а не видение
Многие думают, что у продакт-менеджера должно быть видение. Видением можно называть разные вещи, но если говорить о том, что обычно им является, то я с этим не согласен. С моей точки зрения, видение чаще вредит, чем приносит пользу, ограничивая мышление, и одновременно отрывая от реальности.
Мне больше нравится, когда говорят о планах. Но план — это не фантазии изложенные в виде какого-нибудь «роудмапа» (это как раз больше похоже на видение). План — это дерево возможных путей развития продукта, где часто используется конструкция «если…, то». План — это в определенном смысле живой организм, который развивается и меняется с появлением новой информации о рынке, пользователях, продукте.
Преимущества такого подхода:
- Вы продумываете не один путь развития, в который вы верите (часто безосновательно), а много разных путей. Возможно, ваше видение (ваш первый план) окажется хуже других вариантов.
- Вы не игнорируете потенциальные риски и слабые места вашего видения (первого плана), а ищите способы их верификации (как можно быстрее и дешевле проверить рисковые места плана) и их решения.
- Когда что-то идет не по плану (а это происходит регулярно), то в обычной ситуации ограниченные сроки и общая паника не позволяют вам нормально подумать и принять осмысленное решение о том, что и как делать дальше. При таком подходе на этот случай у вас уже будет база, от которой можно отталкиваться.
Если проводить аналогию, то видение — это луч света в темноте. Вы ничего не видите и не знаете, что за его пределами. У вас нет ни малейшего представления, что будет, если шагнуть вправо или влево. Наткнувшись на препятствие по пути, вы не понимаете, что вы можете сделать.
Когда вы продумываете и быстро тестируете возможные варианты развития вашего продукта, то вы пытаетесь максимально осветить территорию и примерно понять, как устроена окружающая местность, куда можно и следует двигаться, а какие пути являются тупиковыми и опасными.
Подробно и интересно про пути развития продукта написал Аркадий Морейнис в своей статье «.
Еще пару слов про видение. В определенном виде оно конечно же у вас должно быть. Но ваше видение скорее отвечает на вопрос «Зачем?», чем на вопросы «Как?» и «Что?».
Урок 19. Вам должно очень нравиться то, что вы делаете
Я с ужасом представляю, если бы я работал над продуктом, который мне не нравится. На сегодняшний день я начинал играть заново в King of Thieves уже примерно 20 с лишним раз, а всего мой стаж в этой игре составляет почти 2 года.
Поэтому подумайте хорошо перед тем, как ввязываться в разработку чего-либо. Вам это должно очень нравиться, в противном случае вы быстро потеряете мотивацию, и ваша эффективность устремится к нулю.
Урок 20. Не копируйте бездумно
Один из популярных способов нарушить правило из прошлого пункта — попробовать скопировать другой успешный продукт.
Во-первых, вы моментально ограничите себя и свое мышление.
Во-вторых, ваша мотивация, скорее всего, будет финансовая, а столкнувшись с первыми трудностями, вам ее не хватит, чтобы их преодолеть.
В-третьих, делать что-то новое намного увлекательнее и веселее.
В компании Zeptolab есть очень хорошее правило: мы делаем игры, стараясь привнести в игровую индустрию что-то новое. И King of Thieves — замечательный пример нового продукта на рынке мобильных игр. Это сложный путь, так как приходится решать множество задач, с которыми раньше никто не сталкивался, а значит негде подсмотреть решение. Но зато это интересно.
Если рассматривать вопрос копирования не с точки зрения мотивации, а с точки зрения продукта, то тут есть еще одна проблема. Скорее всего, вы скопируете не то, что делает или сделало копируемый продукт успешным.
Обычно построение продукта происходит эволюционно. В процессе создатели изучают свое творение, многое пробуют и экспериментируют. Это обеспечивает им прочный фундамент, на который они опираются при развитии. Более того, многие продуктовые решения принимаются не только исходя из цифр и данных, но и исходя из ценностей компании и людей, которые над продуктом работают.
Когда вы копируете, то часто ориентируетесь на внешние атрибуты, не понимая, что лежит под ними внутри, что и для чего сделано, что работает, а что нет. Что еще более усложняет задачу копирования — то, что работало год назад, может уже не работать сейчас.
Вы почти всегда видите лишь финальную точку существования продукта, за которой скрыт длинный эволюционный путь к этому состоянию. Поэтому, копируя, вы с высокой вероятностью возьмете лишь оболочку, потеряв при этом стержень, который эту оболочку удерживает.
Достаточно забавно читать обзоры и рекомендации по King of Thieves от других профессиональных геймдизайнеров и продакт-менеджеров. Их оценки и рекомендации часто выглядят весьма логичными (особенно с учетом влияния на наше мышление ряда популярных игр из топа гроссинга), но с первой попытки им редко удается докопаться до сути, хотя были и весьма неплохие попытки (например, вот неплохая версия из Wooga).
Чаще всего то, что рекомендуют, мы уже либо пробовали, либо обсуждали и по тем или иным причинам от этого отказались. Часто люди фокусируются на внешних мелких деталях, которые не имеют существенного потенциала и влияния, иногда предлагают решения, которые улучшают один аспект игры, ломая при этом другой. Человеку со стороны, даже много игравшему в игру, даже с профессиональной экспертизой, сложно докопаться до реальной причины наличия тех или иных механик в игре, не зная всю длинную историю развития продукта, не имея доступа к метрикам и данным, ко всем тем неудачным версиям продукта, которые появлялись в процессе разработки.
Это ни в коем случае не камень в чей-либо огород. Основная мысль в том, что изучение продукта извне редко позволяет понять что, как и почему работает, даже при наличии необходимых знаний и экспертизы, что постепенно возвращает нас к вопросу копирования.
Часто хочется, не сильно задумываясь, взять и скопировать что-то из другого успешного продукта, потому что «там это работает». Но лучше этого не делать, не стоит копировать бездумно.
Я не говорю, что всегда надо изобретать велосипед, но важно прочувствовать то, как работает понравившаяся вам механика в другом продукте, потом понять, насколько и в каком виде это нужно и применимо в вашем случае. Лишь после этого думать над тем, стоит ли ее заимствовать, или вам она не подходит.
Урок 21. Вы можете стать экспертом вашего продукта, но не продакт-менеджмента
Если достаточно долго и весьма успешно работать над каким-то продуктом, то знания и умения, полученные в процессе этой работы, окажутся применимы только к этому конкретному продукту и не очень применимы к другим.
Каждый новый продукт — это новая вселенная со своими законами. Вам придется все начать с нуля. Это исследовательская работа, и ваш успех в прошлом исследовании имеет мало влияния на новое. Наверное, поэтому делиться опытом в таких сферах, как разработка продуктов или геймдизайн, — задача нетривиальная.
Набор подходов и методологий может быть весьма схожим, но только знание этих подходов и методологий не делает вас экспертом продакт-менеджмента. Я знаю, как писать ручкой на бумаге, я хорошо умею делать это правой рукой, но когда беру ручку в левую, мои знания мне мало помогают.
С работой над продуктом все очень похоже. С каждым новым продуктом вы будете начинать все с нуля, вы будете брать ручку в другую руку и учиться всему заново.
Мы все, если повезет, эксперты продуктов, над которыми работаем. Но уж точно не продакт-менеджмента.
Урок 22. Будут те, кто лучше знает что, как и когда надо делать
Одна из особенностей работы продакт-менеджером состоит в том, что всегда найдутся люди, которые будут лучше вас знать:, как и что надо было делать в продукте (будучи аналитиком, я нередко выступал в этой роли). С этим надо смириться. Ключевая проблема, что вы так и не узнаете, кто прав, а кто нет (см. урок 2).
Единственный вариант — создать несколько копий вашего продукта (а лучше мира) и провести эксперимент. Но об ограничениях lean подхода мы уже поговорили (см. урок 7).
Между теми, кто дает советы/рекомендации, и вами есть ряд принципиальных различий:
- Степень погружения того, кто дает советы обычно существенно меньше, поэтому его картина происходящего либо более однобока, либо более поверхностна;
- Любой подобный совет в большинстве случаев — просто идея, а ценность идеи вне контекста всех других идей, задач и активностей обсуждать сложно (про применимость идей к продуктам мы уже поговорили в первой части статьи);
- В большинстве случаев ответственность несете вы, а не тот, кто дает рекомендации, что ставит вас в принципиально разные позиции.
Часто подобные советы — это просто завуалированный пользовательский фидбек. Именно так и стоит их рассматривать. Если задавать правильные вопросы, то можно быстро понять, откуда у человека появилось определенная позиция или уверенность. Подобные разговоры стоит рассматривать как глубинные интервью с вашими пользователями, которые вам помогут посмотреть на продукт с другой стороны.
Урок 23. Быть одновременно продакт-менеджером и аналитиком — непростая задача
Ключевая задача аналитика — быть объективным. Ключевое желание продакт-менеджера — принять правильное решение, которое улучшит продуктовые метрики и приблизит его к цели.
Когда эти две роли соединились во мне, то задача аналитика и желание продакт-менеджера начали конфликтовать. Очень хотелось статистически незначимый рост назвать сработавшим улучшением, а всякое нежелательное снижение списать на шум в данных.
У некоторых продакт-менеджеров есть склонность запоминать и использовать лишь те цифры, которые выставляют их в хорошем свете и игнорировать другие. С таким паттерном в поведении я нередко сталкивался в «Яндексе». Это плохо, причем в первую очередь для продуктов, над которыми эти люди работают, а значит для пользователей, которые их используют.
Ухудшение продуктовых метрик в результате каких-то изменений — это такая же полезная информация, как и их рост. Не стоит сильно привязываться к сделанному в продукте. При необходимости надо признавать ошибку и откатываться назад.
С другой стороны то, что у меня есть аналитическая экспертиза, сильно помогает. Это позволяет встраивать метрики и работу с данными в процессы разработки и принятия решений, что делает нас более гибкими, быстрыми и обучаемыми.
Урок 24. Метрики — это важно, но это далеко не все
Как аналитик я очень люблю метрики. Но несмотря на их важность, это лишь один из способов сбора информации о неизведанном мире вашего продукта.
Отзывы, личное общение с пользователями, грамотно составленные опросы, записи видео использования вашего продукта — все это очень важные источники информации, без которых вы многое потеряете.
Каждый из этих источников информации хорошо отвечает на определенные типы вопросов. Поэтому надо с умом использовать все доступные инструменты изучения продукта и ваших пользователей, не зацикливаясь лишь на цифрах.
Урок 25. Оценить работу продакт-менеджера — нетривиальная задача
Казалось бы, очевидно, что продакт-менеджера надо оценивать по успешности продуктов, в создании которых он поучаствовал. Но на самом деле, это плохой способ оценки.
Давайте проведем мысленный эксперимент и воспользуемся для этого методом Монте Карло.
Будем считать, что за свою профессиональную карьеру моделируемый продакт-менеджер запускает 10 продуктов. Его профессионализм будем измерять тем, какая часть из этих продуктов будет успешна. Пусть успешный продукт — это продукт, который принес прибыль.
Но вот только размер этой прибыли — величина случайная, равномерно распределенная на интервале от 10k$ до 10 млн $ (в реальности она, конечно, не распределена равномерно, но для целей нашего эксперимента этого упрощения будет достаточно).
Сформируем три группы продакт-менеджеров (по 100 человек каждая):
- хорошие продакт-менеджеры — с вероятностью 40% создают успешный продукт;
- нормальные продакт-менеджеры — с вероятностью 30% создают успешный продукт;
- плохие продакт-менеджеры — с вероятностью 20% создают успешный продукт.
А теперь запустим механизм генерации результатов профессиональной деятельности этих 300 продакт-менеджеров за всю их жизнь. Суммарную прибыль, которую принесли созданные ими продукты за всю жизнь, вы можете найти ниже.
В нашем эксперименте самым успешным оказался «нормальный» продакт-менеджер, а вовсе не «хороший». Еще интереснее то, что многие «хорошие» заработали для своих компаний намного меньше, чем «плохие».
В работе продакт-менеджеров (как и еще в ряде сфер) слишком большее влияние на итоговый результат оказывает случайность, поэтому способ оценки продакт-менеджера по успешности его продуктов весьма сомнителен.
Если честно, то я не знаю, как правильно оценивать работу продакт-менеджеров. Наиболее объективно, с моей точки зрения, качество работы конкретного сотрудника может отражать динамика метрик продукта, которым он занимается (именно метрик продукта, а не метрик роста).
Если эта тема вам интересна, то рекомендую почитать Нассима Талеба.
Урок 26. Команда — основа любого продукта
В Zeptolab и в частности на проекте King of Thieves мне очень повезло с командой. И, наверное, главный урок за эти два года продуктовой деятельности для меня состоит в том, что команда — это фундамент и основа любого продукта. Без сильной команды все остальные уроки становятся бессмысленными.
За время создания King of Thieves все много раз шло не так, но в итоге все получалось, и все благодаря сильной и увлеченной команде.
В заключение. Продакт-менеджер — понятие растяжимое
Быть продакт-менеджером игры — совсем не то же самое, что быть продакт-менеджером SaaS-сервиса.
Быть продакт-менеджером в одной компании — совсем не то же самое, что быть продакт-менеджером в другой.
Само понятие продакт-менеджер сильно зависит от контекста и от особенностей конкретного продукта и принятых в компании процессов и правил.
В любом случае, надеюсь, что извлеченные мной уроки будут вам полезны.
