Мы продолжаем рассказывать о ключевых качествах для успешного менеджера по продукту, по мнению продуктовой команды Wrike. В шестой (!) части данной серии мы пообщаемся с Антоном Стожко. Антон работает associate product manager 1,5 года, куда перешел из команды Customer Support.
— Привет, Антон! Предлагаю сразу начать с ключевого вопроса: какие, на твой взгляд, три ключевых качества менеджера по продукту, который хочет быть успешным в своей роли?
— Самый топ – это умение планировать и приоритизировать. План и приоритет – это не столько менеджмент продукта, а личная культура или даже гигиена. План важен, потому что помогает бороться с неизвестностью, а ее мало, кто любит и большинство пытается избегать. Но если хочешь развивать бизнес, придется иметь с ней дело. А приоритет важен, потому что никогда не будет ресурсов сделать все и полностью (хорошая новость — это и не требуется). Главное, делать самое важное в свое время.
— А как можно развить эти навыки? Можно ли сказать, что они идут от чувства ответственности за происходящее в твоей команде и твоем бизнесе?
— Ну, точно не за все происходящее, а только за то, что находится в твоей зоне ответственности. Развивать их можно, как и все остальное – через повторения. Небольшая оговорка: трудно научиться хорошо планировать, пока сам не станешь продактом. Особо не видно всей необходимости в той или иной деятельности, не понятна настоящая ценность. Wrike здесь сильно меня встряхнул: я понял, что личного времени не так много, как я думал, а список приоритизированных задач стремится к бесконечности. У меня до сих пор перед глазами очередь запросов в Support, где я начинал.
Чтобы развивать данные навыки, нужно пытаться применять эти принципы на абсолютно все происходящее. Дела на день, планы на отпуск, ответы на сообщения из трех-четырех каналов, планы команды на квартал. Далее нужно научиться переносить навыки на деятельность других людей: на команды и их планирование, на продакт-менеджеров и их видение.
Заметил, что классный толчок планированию и приоритизации дает способность сначала представить “идеальное состояние”. Когда дела сделаны, решения приняты, фичи зарелижены, метрики достигнуты. Как только идеальное состояние на определенный момент времени сформировалось в голове, можно начинать разматывать клубок.
— А как его разматывать?
— Задавая вопросы, конечно. Это как раз второй ключевой навык – умение задавать вопросы себе и другим: “Что нужно, чтобы это произошло?”, “Чего не хватает?”, “Что непонятно человеку без контекста?”. Большие и невнятные вопросы разматываются на мелкие и конкретные вопросы. Опять же, не надо отвечать на все сразу. Помним про первый принцип.
Про важность умения задавать вопросы написано, наверное, во всех книжках про продукт, только там большой фокус на вопросе "Why?". Спорить не буду — customer research тема полезная, но остальные вопросы не менее важны. Стейкхолдерам часто интересно: "что и когда?", команде интересно: "зачем и в каком порядке?", всем интересно: "что и почему?".
Особенность работы продакта в том, что в кармане не всегда ответов больше, чем вопросов. Но стремление к получению ответов — и есть секрет борьбы с рутиной.
— Насколько широко формулируются задачи, над которыми тебе необходимо работать как продакт оунеру в рамках стратегии? Тебе транслируется лишь общее видение или какие-то более конкретные вещи? К примеру, типичной ли является ситуация, когда к тебе обращаются: “Мы хотим, чтобы в этой части продукта было вот так”. И потом ты собираешь команду и говоришь: «Ребята, делаем так».
— У меня есть любимая метафора про молот и наковальню. Вот продакт живет там, где они встречаются и искры летят. Молот – это top-down движ. Тут и верхнеуровневый вижн, и стратегия, и OKRs и иногда очень даже конкретные задачи. Инсайты спускаются в разной форме с разной степенью важности и проработанности. Это все желания. Наковальня — это bottom-up движ. Это кодовая база, ресурсы, настроения людей в команде, текущие приоритеты и существующие планы. Это реальность. Там, где желания встречаются с реальностью, приходится менеджить и то, и другое.
Так что ответ на вопрос: "Как это происходит?" — "По-разному"!
Бывает, что разматываешь идею от топ-менеджера и приходишь к пониманию, что в каком-то флоу потенциально есть огромная ценность. Моя задача — выявить эту ценность, понять, как ее встроить в рабочие процесс и проверить, не мешает ли она существующим приоритетным задачам.
Бывает, что совершенно конкретная задача спускается, и ее надо взять и сделать.
Кстати, в глубоком смысле, прямо поставленную задачу от идеи, инсайта или стратегии отличает только степень приближения и проработанности.
— А расскажи, пожалуйста, какова разница между продактом и associate-продактом в контексте Wrike?
— В первую очередь, это уровень решений, которые ты принимаешь. Вот смотри: я пришел и стал Associate Product Manager, и мне мой менеджер говорит: «Давай календари запилим, чтобы маркетинговым агентствам, которые пользуются Wrike, хорошо было» (имеется в виду фича “Календари” в продукте Wrike). И я отвечаю: «Ну, если мы их пилим, то они должны быть вот такие. Там должны быть фильтры, возможность сделать внешнюю ссылку для шаринга и еще много чего». Я описываю детали еще не существующей фичи, но при этом сама фича продана. На что-то я получаю одобрение, а где-то отвечаю на дополнительные вопросы.
При этом, как фича будет функционировать и зачем она нужна — всем понятно. Поэтому на этой стадии ты получаешь задачу в форме: «Давай, делай». На тебя ложится операционный менеджмент команды, наполнение бэклога. Это не главная составляющая работы продакта, но отличная точка отправления.
Наполнять бэклог умеют многие. Нет ничего сложного в том, чтобы в задаче написать, как фича должна работать, когда ты ее сделаешь, и потом проговорить это с разработчиками. Все, что идет далее — вопрос оценки и планирования.
Все, что я описал — это стартовый уровень. На следующем этапе принятия решений перед тобой стоят уже другие вопросы. Не “какая будет фича?”, а “что вообще делать?”. Именно этим вопросом я задавался, начиная работать над Blueprints (прим — одна из новых функциональностей в продукте). Никто мне не говорил: “Сделай Blueprint’ы и реши, какими они будут”. Мне сказали: “Есть проблема с рекуррентной работой. Что будем делать?”
Потом идет третий уровень принятия решений. Здесь тебе уже не обозначают проблему, а говорят: “Мы думаем, что может быть проблема где-то здесь есть”. И твоей задачей уже становится поиск проблемы.
— То есть на третьем уровне ты начинаешь с того, что сам выделяешь проблему, потом сам же предлагаешь решение и затем доводишь это все до конца?
— Да. И для меня это уже выглядит как выпускная работа. Когда ты сам провел исследование, все понял, со всеми поговорил, срастил видение с реальностью, всем все показал, всех во всем убедил. Подытоживая, на каждой стадии тебе всегда дают какие-то вводные. Вопрос в том, насколько они определены. И с каждым новым уровнем принятия решений горизонт необъятного становится все шире.
— Понял. Ты сказал, что на уровне blueprint’ов работал уже на втором уровне принятия решений, а при решении проблемы онбординга — на третьем. А есть ли четвертый, пятый уровни и так далее? Или есть все-таки конец?
— Наверное, четвертый – это когда у тебя есть группа продакт-менеджеров. Работа в скрам-команде перестает быть твоей рутиной, и у тебя появляется новая команда, состоящая из продактов. У каждого из них какое-то видение и проблема, которую они пытаются решить. И твоей задачей становится эффективный менеджмент желаний с реальностями каждого из этих продактов.
То есть, по сути, дальше идет масштабирование: количество горизонтов, которые нужно объять увеличивается. Это возможно благодаря делегированию. И на этом четвертом уровне нужно сделать так, чтобы те, кто сейчас на третьем, пришли к тебе с такими предложениями и презентациями, на базе которых ты можешь принять решение или дать совет, чтобы колесо крутилось.
— Хорошо. Давай вернемся к первоначальному вопросу. Ты уже назвал планы, приоритизацию и умение задавать вопросы. А какое, на твой взгляд, третье качество для успешного менеджера по продукту?
— Как любит говорить мой ментор: «Единственный ресурс продакта – это отношения с другими людьми”, то есть, коммуникация.
— А в рамках навыка коммуникации, с какими проблемами приходится сталкиваться на ежедневном уровне?
— На ежедневном уровне есть две распространенные проблемы: miscommunication и undercommunication. Информация либо поступает в недостаточном количестве, либо трансформируется в злокачественную. В результате, совершаются лишние движения, а какие-то процессы стопорятся. Исправление и того, и другого – это лишние расходы.
Эти проблемы могут быть актуальны на любом уровне. Просто чем уровень выше, тем дороже фикс. Пример внутри скрам-команды: сотрудника не было на планировании, и ему не передали информацию, или продакт криво прописал definition of done. Всякое бывает. В результате, в спринте лежит задача, у которой еще не все шаги выполнены для того, чтобы ее взяли в разработку. Допустим, ее разработка достаточно проста: ее реализуют, а потом выясняется, что ее либо начали делать слишком рано, либо не нужно было делать вообще. Следующий уровень веселья – это менеджмент коммуникаций между командами или департаментами.
— Хотел бы задать еще пару вопросов. Скажи, пожалуйста, у тебя бэкграунд изначально айтишный или нет?
— Нет. Я в жизни не написал строчки кода. Ну, может на BASIC на уроке информатики в 6-ом классе 100 лет назад. В моей работе — это не ключевой фактор.
— У многих людей по этому вопросу расходятся мнения. Считаешь ли ты, что наличие технического образования поможет тебе стать лучшим менеджером по продукту?
— Это поможет тебе больше совать нос в дела твоих разработчиков. Если это поможет им, то это плюс. Если это помешает им или тебе делать свою работу быстрее и эффективнее, тогда это минус. В любом случае, продакт – это не волк-одиночка. Обожаю присказку из Игры Престолов: When winter comes, the lone wolf dies but the pack survives. Это про ценность игры в команде. Мне не нужно знать JavaScript, а им — как заполнять продуктовый бриф.
— Если ты не до конца разбираешься в какой-то теме, то ты задаешь вопросы своей команде и принимаешь решения на базе их ответов?
— Это именно то, что происходит. Я убеждаюсь, что мы делаем самое важное сейчас, и я в курсе сколько это стоит. Я всегда должен держать в голове и соотносить трудоемкость с результатом.
Это задается на каждом из шажочков своеобразной системой противовесов, где ты должен смотреть, не слишком ли затратно сделать этот шаг по отношению к ценности, которая из него получится, и не пропустил ли ты шаг, из которого можно получить очень много ценности и при этом сделать его дешево. Здесь важным моментом является то, что количество получаемой ценности определяю я — это моя чаша весов. А сколько оно стоит, взвешивают разработчики. Мы коммуницируем и определяем, какой шаг все-таки сделать.
— То есть, возможна следующая ситуация: ты проводишь исследование и находишь точку, где ценность огромна. Потом ты приходишь и отдаешь описанную проблему или решение, и тебе разработчики говорят, что вес слишком большой и несоизмеримый ценности. Тогда ты можешь отказаться от дальнейшей работы над данным решением, правильно?
— В такой ситуации вся надежда на разработчиков, потому что удельную ценность не изменить. Но, возможно, есть шанс изменить удельную стоимость.
Все нередко упирается в то, как ты сформулируешь проблему. Ты можешь сказать: “Надо сделать так, чтобы повторяющаяся подзадача могла копироваться в повторяющейся задаче”. А можешь зайти немного с другой стороны: “Мы пытаемся решить проблему, когда есть подзадача и нужно сделать так, чтобы она с какой-то регулярностью создавалась и запоминалась в родительской задаче”.
Кажется, что сформулированные задачи очень похожи. Но в первом случае я говорю разработчикам, что им нужно чинить существующий механизм повторяющихся задач, а во втором случае я такого ограничения не делаю. А еще семантика. Не “надо”, а “мы”. Хорошо работает приходить с проблемой, а как ее решить – зона ответственности команды. Это их креативная свобода и их возможность самореализации.
— А если они предложат несколько решений проблемы, то, кто оценивает лучшее? Тимлид?
— Я и оцениваю. Причем, если у меня нет понимания, какое решение эффективнее, это значит, что я не задал команде нужные вопросы. Это, кстати, подводит меня к очень важной теме – про команду. Важно ставить команду выше цели.
В определенных, конечно, случаях можно делать исключения. Если, например, ставится очень жесткий дедлайн, которые задан извне: срочная разработка под большого клиента, релиз для стратегического партнера, с которым надо синхронизировать выход интеграции и прочее. Тогда нам просто нужно сесть и сделать.
Но чаще всего ты понимаешь, что дедлайн чуть-чуть мягче, чем идущий на встречу поезд. Тогда выбирать надо сторону команды. В Wrike я действительно это чувствую, потому что у нас команду расшатать дороже, чем поменять продакта.
