Продолжаем говорить о ключевых качествах успешного продакт-менеджера по мнению продуктовой команды Wrike. В шестой (!) части этой серии мы поговорим с Антоном Стожко.
Антон 1,5 года работает младшим менеджером по продукту, куда перешёл из команды поддержки клиентов.
- Здравствуйте, Антон! Предлагаю сразу начать с ключевого вопроса: каковы, по вашему мнению, три ключевых качества менеджера по продукту, который хочет добиться успеха на своей должности? — Самое лучшее — это умение планировать и расставлять приоритеты.
План и приоритет — это не столько управление продуктом, сколько личная культура или даже гигиена.
План важен, потому что он помогает бороться с неизвестным, и мало кто его любит, а большинство стараются его избегать.
Но если вы хотите развивать свой бизнес, вам придется иметь с ней дело.
И приоритет важен, потому что никогда не будет ресурсов, чтобы сделать все полностью (хорошая новость в том, что это не обязательно).
Главное – успеть сделать самые важные дела в свое время.
— Как можно развить эти навыки? Можно сказать, что они исходят из чувства ответственности за то, что происходит в вашем коллективе и вашем бизнесе? - Ну точно не за все происходящее, а только за то, что находится в вашей зоне ответственности.
Их можно развивать, как и все остальное – посредством повторения.
Небольшая оговорка: трудно научиться хорошо планировать, пока вы сами не станете продуктом.
Необходимость в той или иной деятельности особо не видна; реальная стоимость не ясна.
Здесь Wrike меня очень встряхнул: я понял, что личного времени у меня не так много, как я думал, а список приоритетных задач стремится к бесконечности.
Передо мной все еще стоит очередь запросов в службу поддержки, откуда я начинал.
Чтобы развить эти навыки, нужно постараться применять эти принципы абсолютно ко всему происходящему.
Дела на день, планы на отпуск, ответы на сообщения трёх-четырёх каналов, планы команды на квартал.
Далее вам нужно научиться переносить навыки на деятельность других людей: на команды и их планирование, на продакт-менеджеров и их видение.
Я заметил, что большой толчок к планированию и расстановке приоритетов дает способность сначала представить «идеальное состояние».
Когда все сделано, решения приняты, функции реализованы, показатели достигнуты.
Как только в вашей голове сформировалось идеальное состояние на определенный момент времени, можно начинать раскручивать клубок.
- Как его размотать? — Конечно, задавая вопросы.
Это как раз второй ключевой навык – умение задавать вопросы себе и другим: «Что нужно, чтобы это произошлоЭ», «Чего не хватаетЭ», «Что непонятно человеку без контекстаЭ» Большие и расплывчатые вопросы распадаются на маленькие и конкретные вопросы.
Опять же, не обязательно отвечать на все сразу.
Давайте вспомним первый принцип.
О важности умения задавать вопросы написано, наверное, во всех книгах о продукте, только там большой акцент делается на вопросе «ПочемуЭ».
Спорить не буду — исследование клиентов — полезная тема, но не менее важны и другие вопросы.
Заинтересованные стороны часто задаются вопросом: «что и когдаЭ», команда задается вопросом: «почему и в каком порядкеЭ», все задаются вопросом: «что и почемуЭ».
Особенность работы продукта в том, что ответов в кармане не всегда больше, чем вопросов.
Но желание получить ответы – это секрет боевой рутины.
— Насколько широко сформулированы задачи, над которыми вам как владельцу продукта необходимо работать в рамках стратегии? Вы передаете только общее видение или какие-то более конкретные вещи? Например, типична ли ситуация, когда к вам обращаются: «Мы хотим, чтобы эта часть продукта была такой».
А потом собираешь команду и говоришь: «Ребята, давайте сделаем это».
— У меня есть любимая метафора про молот и наковальню.
Продукт живет там, где они встречаются, и летят искры.
Молоток – это движение сверху вниз.
Есть видение высшего уровня, стратегия, OKR и иногда очень конкретные задачи.
Понимание приходит в разных формах с разной степенью важности и проработанности.
Это все пожелания.
Наковальня – движение снизу вверх.
Сюда входит кодовая база, ресурсы, настроения членов команды, текущие приоритеты и существующие планы.
Это реальность.
Там, где желания совпадают с реальностью, необходимо управлять обоими.
Итак, ответ на вопрос: «Как это происходитЭ» - "Иначе"! Бывает, откручиваешь идею от топ-менеджера и приходишь к пониманию, что в каком-то потоке потенциально есть огромная ценность.
Моя работа — определить эту ценность, выяснить, как включить ее в рабочий процесс, и посмотреть, не мешает ли она существующим приоритетам.
Бывает, что попадается очень конкретная задача, и нужно ее взять и сделать.
Кстати, в глубоком смысле непосредственно поставленная задача отличается от идеи, идеи или стратегии лишь степенью приближения и проработки.
— Скажите, пожалуйста, чем отличается продукт от сопутствующего продукта в контексте Wrike? — Прежде всего, это уровень принимаемых вами решений.
Смотрите: я пришел и стал заместителем менеджера по продукту, и мой менеджер сказал мне: «Давайте исправим календари, чтобы маркетинговые агентства, использующие Wrike, хорошо проводили время» (имеется в виду функция «Календари» в продукте Wrike).
А я отвечаю: «Ну, если мы их порежем, то они должны быть такими.
Должны быть фильтры, возможность сделать внешнюю ссылку для расшаривания и многое другое».
Я описываю детали функции, которой еще нет, но сама функция продана.
Я получаю одобрение на некоторые вещи, а иногда отвечаю на дополнительные вопросы.
При этом то, как функция будет функционировать и зачем она нужна, понятно всем.
Поэтому на этом этапе вы получаете задание в виде: «Давай, сделай».
На вас лежит ответственность за оперативное управление командой и заполнение бэклога.
Это не основная составляющая работы продукта, но это отличная отправная точка.
Многие люди знают, как заполнить отставание.
Нет ничего сложного в том, чтобы написать, как фича должна работать, когда вы ее сделаете, а потом поговорить об этом с разработчиками.
Все, что будет дальше, является вопросом оценки и планирования.
Все что я описал это начальный уровень.
На следующем этапе принятия решения перед вами встают другие вопросы.
Не «какая будет особенностьЭ», а «что нам делатьЭ» Именно этот вопрос я задал себе, когда начал работать над Blueprints (заметьте — один из новых функционалов продукта).
Никто мне не говорил: «Сделай чертежи и реши, какими они будут».
Мне сказали: «Есть проблема с повторяющейся работой.
Что мы делаем?" Затем наступает третий уровень принятия решений.
Здесь вам уже не указывают на проблему, а говорят: «Мы думаем, что, может быть, где-то здесь проблема».
И вашей задачей становится найти проблему.
— То есть на третьем уровне вы начинаете с того, что сами определяете проблему, потом сами предлагаете решение, а потом доводите все до конца? - Да.
А для меня это уже похоже на дипломную работу.
Когда ты сам провел исследование, все понял, со всеми поговорил, слил видение с реальностью, всем все показал, всех во всем убедил.
Подводя итог, на каждом этапе вам всегда дается какая-то вводная информация.
Вопрос в том, насколько они определены.
И с каждым новым уровнем принятия решений горизонт необъятного становится шире.
- Понял.
Вы сказали, что на уровне blueprint вы уже работали на втором уровне принятия решений, а при решении проблемы онбординга — на третьем.
Есть ли четвертый, пятый уровни и так далее? Или все-таки конец? — Наверное, четвёртый — это когда у тебя есть группа продакт-менеджеров.
Работа в Scrum-команде перестает быть для вас рутиной, и у вас появляется новая команда, состоящая из продуктовых людей.
У каждого из них есть видение и проблема, которую они пытаются решить.
И вашей задачей становится эффективное управление желаниями с реалиями каждого из этих продуктов.
То есть, по сути, масштабирование продолжается: увеличивается количество горизонтов, которые необходимо охватить.
Это возможно посредством делегирования.
И на этом четвертом уровне вам нужно сделать так, чтобы к вам приходили те, кто сейчас на третьем, с такими предложениями и презентациями, на основании которых вы сможете принять решение или дать совет, чтобы колесо крутилось.
- Отлично.
Вернемся к исходному вопросу.
Вы уже упомянули о планах, расстановке приоритетов и умении задавать вопросы.
Как вы думаете, какое третье качество для успешного менеджера по продукту? — Как любит говорить мой наставник: «Единственный ресурс продукта — это отношения с другими людьми», то есть общение.
— А в рамках коммуникативных навыков с какими проблемами вы сталкиваетесь ежедневно? — На повседневном уровне есть две общие проблемы: недопонимание и недопонимание.
Информация либо поступает в недостаточном количестве, либо трансформируется в злокачественную информацию.
В результате совершаются лишние движения и останавливаются некоторые процессы.
Исправление обоих требует дополнительных затрат. Эти проблемы могут быть актуальными на любом уровне.
Просто чем выше уровень, тем дороже починка.
Пример изнутри Scrum-команды: сотрудник не присутствовал на планировании и информация ему не передавалась, или продакт-менеджер неправильно записал определение сделано.
Все может случиться.
В результате в спринте появляется задача, для которой еще не все шаги выполнены, чтобы ее можно было взять в разработку.
Скажем, его разработка довольно проста: его реализуют, а потом выясняется, что его либо начали слишком рано, либо вообще не надо было делать.
Следующий уровень удовольствия — управление коммуникациями между командами или отделами.
— Я хотел бы задать еще пару вопросов.
Скажите пожалуйста, у вас изначально IT-образование или нет? - Нет. Я никогда в жизни не писал ни строчки кода.
Ну, может быть, на БЕЙСИКЕ на уроке информатики в 6 классе 100 лет назад. Это не ключевой фактор в моей работе.
— У многих людей разные мнения по этому вопросу.
Как вы думаете, техническое образование поможет вам стать лучшим менеджером по продукту? — Это поможет вам больше совать нос в дела ваших разработчиков.
Если им это поможет, то это плюс.
Если это мешает им или вам выполнять свою работу быстрее и эффективнее, то это минус.
В любом случае, продукт — не волк-одиночка.
Мне нравится поговорка из «Игры престолов»: когда приходит зима, одинокий волк умирает, но стая выживает. Речь идет о ценности игры в команде.
Мне не нужно знать JavaScript, а им не нужно знать, как заполнить описание продукта.
— Если вы не до конца понимаете тему, задаете ли вы своей команде вопросы и принимаете решения на основе их ответов? - Именно это и происходит. Я слежу за тем, чтобы мы сейчас делали самое важное, и знаю, сколько это стоит. Мне всегда приходится держать это в уме и соотносить усилия с результатом.
Это задается на каждом из шагов своеобразной системой противовесов, где надо смотреть, не слишком ли дорого сделать этот шаг по отношению к той ценности, которая от него выйдет, и не пропустили ли вы шаг из который вы можете получить большую ценность и в то же время сделать его дешевым.
Важным моментом здесь является то, что я определяю сумму полученной ценности – это моя шкала.
Разработчики взвешивают, сколько это стоит. Мы общаемся и определяем, какой шаг предпринять.
— То есть возможна следующая ситуация: вы проводите исследование и находите точку, значение которой огромно.
Потом вы приходите и сообщаете описанную проблему или решение, а разработчики вам говорят, что вес слишком велик и несоизмерим со стоимостью.
Тогда вы можете отказаться от дальнейшей работы над этим решением, верно? — В такой ситуации вся надежда лежит на разработчиках, потому что конкретное значение изменить нельзя.
Но может быть шанс изменить стоимость единицы продукции.
Все зачастую зависит от того, как сформулировать проблему.
Вы можете сказать: «Нам нужно убедиться, что повторяющуюся подзадачу можно скопировать в повторяющуюся задачу».
А можно пойти немного по-другому: «Мы пытаемся решить задачу, когда есть подзадача и нам нужно сделать так, чтобы она создавалась и запоминалась в родительской задаче с некоторой регулярностью».
Кажется, заявленные задачи очень схожи.
Но в первом случае я говорю разработчикам, что им нужно исправить существующий механизм повторяющихся задач, а во втором — такого ограничения не делаю.
А еще семантика.
Не «должны», а «мы».
Хорошо, если у вас возникнет проблема, и ответственность за ее решение лежит на команде.
Это их творческая свобода и возможность самореализации.
— А если предлагают несколько вариантов решения проблемы, то кто оценит лучшее? Руководитель группы? - Я ценю это.
Более того, если у меня нет понимания, какое решение эффективнее, значит, я не задал команде правильные вопросы.
Это, кстати, подводит меня к очень важной теме – о команде.
Важно ставить команду выше цели.
В определенных случаях, конечно, могут быть сделаны исключения.
Если, например, установлен очень жесткий срок, заданный извне: срочная разработка для крупного клиента, релиз для стратегического партнера, с которым нужно синхронизировать интеграционный релиз и т. д. Тогда нам просто нужно сесть и сделай это.
Но чаще всего понимаешь, что дедлайн немного мягче, чем приближающийся поезд. Затем вам нужно выбрать сторону команды.
В Wrike я это очень чувствую, потому что встряхивать команду дороже, чем менять продукт. Теги: #Управление проектами #Управление продуктами #saas #SaaS / S+S #wrike
-
Amazon Представила Kindle Hdx
19 Oct, 24 -
Результаты Опроса О Entity Framework
19 Oct, 24
