[Управление продуктом] Product Manager & Product Designer: поиск сходств и отличий
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Меня зовут Ростислав Салата, я работаю в киберспортивной организации без малого три года. Пришел в компанию на должность проектировщика интерфейсов, дорос до UX-лида, и в настоящее время являюсь продуктовым менеджером.
Задачи продуктового менеджера и подход к работе у нас сильно отличаются от обязанностей продуктовых менеджеров в других компаниях. Это значит, что в вашей компании представления о функционалах и наборе скилов для продуктового менеджера и дизайнера могут отличаться. Например, в некоторых компаниях продуктовый менеджер проектирует интерфейсы, а у нас – нет.
Почему я поднял эту тему? Мы провели очень много собеседований с продуктовыми дизайнерами. Опираясь на свой опыт и опыт коллег, могу смело сказать, что вопрос о круге обязанностей задает каждый претендент. Разное понимание зон ответственности может впоследствии привести к конфликтам, которые пагубно повлияют на продукт.
Ниже не будет чек-листов и стопроцентной инструкции о том, как перейти в менеджмент. В первой части статьи я развею мифы о «кажется, я уже продакт». Во второй части расскажу о реальных задачах менеджера по продукту. Точнее о тех, с которыми я сталкиваюсь ежедневно и которые должны развеять идеалистическое представление о том, что такое продуктовый менеджмент.
Часть 1. Я и мой продакт-менеджер выполняем похожие задачи. Получается… я продакт-менеджер?
Есть качества, отличающие опытного продуктового дизайнера от начинающего. Поэтому предлагаю обсудить черты тех специалистов, которые на глубинном уровне понимают дизайн, замеряют его эффективность и влияние на решение бизнес-задач. Почему-то обязанности сильных дизайнеров часто путают или пытаются добавить к задачам продуктового менеджера. Следующие шесть пунктов – это частые «ошибки» в понимании задач этих специалистов. По сути это функционал сильного продуктового дизайнера, но почему-то многие считают, что, если он так думает и поступает, то автоматически становится менеджером.
1. Из твоего лексикона пропадают фразы «это не моя работа» или «это не моя зона ответственности»
Ты не закрываешь глаза на ситуацию, если знаешь, что можешь помочь решить или исправить её. Ты готов подхватить какой-то сторонний процесс без вреда для текущей нагрузки. Ты понимаешь значение слова «ответственность» и готов брать ее на себя.
Ловишь себя на мысли, что перестаешь говорить всем подряд, что они недостаточно компетентны. Вместо этого находишь способы тактично донести конструктивную критику до каждого. Многие дизайнеры, да и другие специалисты индустрии могут подумать, что это первые шаги на пути к менеджменту. И да, и нет.
Кто говорит, что продуктовый дизайнер несет меньшую ответственность за продукт, чем продуктовый менеджер? Продуктовым дизайнерам никто не запрещает (даже наоборот!) замечать глюки, давать советы, помогать строить или дополнять командные процессы. Хорошего продуктового дизайнера и отличают те модели поведения, которые я описал ниже.
2. Начинаешь самостоятельно искать инсайты и их источники
В большинстве случаев принятие решения о реализации того или иного функционала остается за продуктовым менеджером. Очень часто дизайнеру, в том числе и продуктовому, приносят список проблем и болей пользователей, которые нужно решить с помощью дизайна. Если же ты сам находишь эти проблемы, задачи, потребности или боли, возникает мысль: а не должен ли этим заниматься продуктовый менеджер? Если кратко, то да. И не только этим.
Определение проблем пользователей – часть дизайн-процесса. «Интерфейсная экспертиза», безусловно, очень важна, но она должна сопровождаться постоянной работой с пользователями. Правда, чаще выходит, что именно дизайнер, а не продакт, находит большинство инсайтов и внедряет их в продукт.
3. Понимаешь, что внедряемая фича влияет не только на пользователя
Дизайнеры часто аргументируют свои предложения пользовательским фидбэком из анкетирования, интервью, комментариев в социальных сетях и запросов в support, говоря о том, что пользователи – наше всё. Без сомнения, так и есть. От пользователей можно и нужно черпать инсайты. Но не пользователем единым.
Когда ты начинаешь думать, что разрабатываемая фича Х может использоваться в разных каналах коммуникации, влиять на финансовую модель продукта, юридические правила и политику его использования, стратегические цели продукта и компании в целом, то становишься намного ценнее и полезнее для продукта и команды в целом. Это очень хороший маркер твоего дизайнерского хард-скила.
Многие дизайнеры знакомы с понятием омниканальности. В работе над продуктом стоит отталкиваться от этого понятия и тщательно продумывать предложенные пользовательские фичи. Почему же дизайнер не должен думать о влиянии внедряемых решений на продукт во всех точках его контакта с пользователями? Если ты продуктовый дизайнер, то это просто must have. Консистентность, детализация и продуманность дизайн-решений на всех уровнях – это топ-скилы дизайнера.
4. Смещение фокуса с дизайна в привычном для всех понимании
Дизайнер в первую очередь работает с интерфейсом продукта. Результатом его работы должен быть визуально приятный и удобный интерфейс. Об этом не стоит забывать, ведь перевод фокуса на глубинный анализ может принести больше вреда, нежели пользы. Иногда дизайнеры настолько погружаются в ресерч, аналитику и другие продуктовые вопросы, что забывают о важности первого впечатления пользователя о продукте.
Если понимаешь, что интерфейс и визуальная коммуникация продукта начинают волновать тебя меньше всего, может, стоит думать не о дизайне или менеджменте, а о позиции исследователя?
5. Появляется ощущение, что предлагаемые фичи не несут пользу продукту
С этим ощущением надо быть аккуратным, так как оно может быть связанным с чувством собственной важности (ЧСВ). Бывает, что внедрение фич обосновывают лишь «я так считаю», «мне виднее» или «пользователям так точно будет удобнее».
Хорошо уметь анализировать фичи с точки зрения пользы для продукта или компании. Как это сделать? Провалидировать и аргументировать идею. Занимаются ли этим только продуктовые менеджеры? Хороший вопрос.
Кем бы ты ни был, дизайнером или менеджером, любые ощущения лучше сопоставлять с фактами и цифрами, а решения – аргументировать.
6. У тебя меняется отношение к продуктовым метрикам
Зачастую метрики уже сформированы. Вся команда работает над их достижением, и дизайнер – не исключение. Круто, когда у тебя появляются мысли о том, что текущие показатели можно пересмотреть, доработать для более правильной интерпретации, в крайнем случае создать или добавить новые.
Смотреть на продуктовые показатели под другим углом – хороший навык. Но говорит ли наличие этого навыка о том, что ты на пути к продуктовому менеджменту? Скорее нет, чем да. Будучи продуктовым дизайнером, ты можешь (должен?) проверять свои решения на соответствие метрикам, и, вероятнее всего, научишься смотреть на показатели эффективности шире.
Добавление новых фич или итерации существующего функционала должны соответствовать целям продукта или компании. Продуктовый дизайнер должен опираться на метрики и смотреть на них в более широком контексте. Это не указывает на то, что специалисту пора переходить в менеджмент.
И правда, получается, что обязанности продуктового дизайнера и продуктового менеджера во многом пересекаются. Чем тогда на самом деле занимается продуктовый менеджер?
Часть 2. Какие задачи решает продуктовый менеджер в реальной жизни?
Будем откровенны: чаще всего продуктовый менеджер занимается чем угодно, кроме своих прямых задач. Если ты продуктовый менеджер и дочитал до этого раздела, то точно улыбнешься, вспомнив себя в роли маркетолога, дизайнера (особенно графического), продажника, разработчика, проектного менеджера, пиарщика и т. д. Да, я тоже был во всех этих ролях, но чего уж там, дизайнер из меня не получается и не получится никогда.
Ниже я собрал основные векторы, в рамках которых продуктовые менеджеры выполняют свои «незаметные» задачи с «невидимыми» результатами работы.
1. Фокус, консолидация, коммуникация.
Фокус. Продуктовый менеджер должен быть сфокусирован на получении прибыли от своего продукта. Другими словами, на заработке денег для компании. Стремление сделать проект прибыльным должно быть здравым, а не фанатичным.
Фанатизм рассмотрим на примере вывода нового продукта на рынок. Менеджер должен понимать: если его продукт нестабилен и не покрывает базовых потребностей своего рынка, то ни о какой монетизации не может быть и речи. Почему? Если требовать с пользователей плату лишь за отличительные ценности, не покрывая их базовые потребности, высока вероятность напортачить в самый важный момент.
Консолидация. Продуктовый менеджер должен быть source of truth для команды. Продакт как сито – он собирает тонну информации, просеивает ее и передает команде в виде понятного технического задания.
В качестве примера рассмотрим работу с sales-менеджерами или маркетологами на этапе внедрения или валидации какой-либо гипотезы. Перед тем, как передать гипотезу в работу другим отделам, ты должен проработать информацию. С одной стороны, не придется отвечать на наводящие вопросы. С другой стороны, ты задашь стратегический вектор, в рамках которого нужно будет копать.
Коммуникация. В моем идеальном мире работа продуктового менеджера должна распределяться так:
- 30%: свои задачи;
- 40%: коммуникация с командой;
- 30%: one-to-one встречи с сотрудниками.
Как видим, 70% времени составляет коммуникация, хотя первые 30% задач тоже так или иначе с ней связаны.
Коммуникация – это налаживание процессов, решение внутренних проблем в команде, встречи с представителями других департаментов, включая маркетинг и т. д. Очень часто в развитии продукта помогают хорошие soft skills, даже если ты начинающий продакт.
Один из важных результатов работы продуктового менеджера – выстроенная коммуникация. Это одна из сложнейших частей работы, поскольку нет результата, который можно «пощупать».
2. Сотрудничество с отделом продаж (Business Development)
Большинство продуктов рано или поздно выходят на стадию монетизации. Так как главная задача продуктового менеджера – создание прибыли, общение с отделом продаж поможет лучше понять продукт и рынок в целом. Некоторые компании не всегда дают возможность общаться с отделом Business Development, но мне повезло.
Совместная работа с менеджерами по развитию бизнеса создает условия для более качественной продажи вашего продукта. Sales менеджеры должны понимать продукт, знать сильные и слабые стороны, а также болевые точки пользователей. Тогда они сделают upsell в нужный момент.
3. Организация кросс-командных процессов
Если у вашей компании достаточно ресурсов для того, чтобы задействовать несколько команд для решения задачи, нужно наладить обмен информацией, чтобы согласовывать действия. Процесс рутинный, но без него не обойтись. Возьмите на себя ответственность и создайте регулярные мероприятия для коммуникации разных команд.
Да, это не быстро. Да, это сложная коммуникация. Да, вероятность игнора высока. Но отношение коллег и доступ к своевременной информации стоят. Этот кейс хорошо описывает задачу взаимодействия в кросс-командах.
4. Правильная постановка целей и задач для команды
Цели. Каждый член продуктовой команды должен понимать, для чего мы «это» делаем и куда идем. Неважно, что это: апдейт текущей фичи, разработка нового сценария или выход еще на один рынок. Интересоваться видением команды по поводу целей продукта в неформальной обстановке – это хорошая практика.
Задачи. Как продуктовый менеджер ты должен быть уверен, что тебя понимают так же, как ты понимаешь себя сам. Достаточно часто я сталкивался с тем, что мои ожидания не всегда очевидны для команды. Поэтому перед постановкой задачи стоит удостовериться, все ли понимают, что должно получиться в итоге, и зачем вообще делать эту работу. Такой себе definition of done, отвечающий на вопрос «что?» со стороны продукта. Команда же ответит на вопрос «как?».
5. Аргументация и навязывание
В нашей команде любые доработки проходят через стадию аргументации. Даже если решение пришло «сверху», команда должна понимать и разделять его. Понимание задач в целом и погружение в детали – это инвестиция в развитие продуктового мышления у всех участников. Если инвестировать в это время, мы получим очень здравую внутреннюю группу валидаторов, которые не пропустят «какую-то дичь» к пользователям. Иначе команда будет просто исполнителем.
Кому-то это подходит, кому-то – нет. В моей компании любой из членов команды является полноправным участником продуктовой разработки и может критиковать предложенные подходы или предлагать свои.
6. Управление продуктовой командой
Важно не теоретическое понимание процесса разработки, наличие сертификата по Agile от Coursera, а то, готов ли ты организовать команду и взять ответственность за эффективность и результат её работы.
Важно чувствовать, в какие моменты нужно поддержать участников команды, попросить о помощи, а когда – спросить их мнение. Может показаться, что это полная чепуха. Но понимая настроение коллег, зная их ритуалы, ты получишь тонну инсайтов для построения крутой команды.
Продуктовые менеджеры до последнего «шатают» предлагаемую гипотезу перед тем, как добавить новую фичу или улучшить что-то работающее: проверяют корнер-кейсы, ищут сильные аргументы в пользу внедрения гипотезы в работу. Еще продакт выясняет, с помощью каких KPI будет измеряться результат предполагаемых изменений, если гипотезу примут, а также в рамках какой цели ее будут проверять.
6.1 Стоимость команды и внедряемых решений
Теперь не о романтике. Помимо стандартной эстимации, как продакт-менеджер ты должен просчитывать финансовую эффективность ресурса, который планируешь потратить. Понимая стоимость часа твоей команды, начинаешь смотреть через призму финансовой эффективности на любое предложение и гипотезу.
Стоимость разработки и ожидаемая прибыль от изменений в функционале играют не последнюю роль в принятии решений. Думаю, что знание финансовой стороны работы команды усиливает главный скил продуктового менеджера: умение говорить «нет».
6.2. Кадровая эффективность
В некоторых компаниях продуктовый менеджер участвует в регулярных ревью членов команды. По объективным причинам обсуждение технических скилов на уровне ревью находится вне зоны влияния менеджера (если ты, конечно, не Technical Product). А вот оценка персональной эффективности и ее влияния на работу в команде – самое то.
Продуктовый менеджер может и должен влиять на оценку эффективности сотрудника в команде. Звучит немного эгоистично, но команда – это ресурс, который должен самоотверженно и эффективно работать на благо продукта.
Для оценки и обсуждения факторов, влияющих на эффективность работы сотрудника, можно использовать следующие подходы:
- регулярные one-to-one встречи;
- наблюдение при решении спорных моментов;
- предрелизная реакция;
- коммуникация с коллегами из других команд.
«Не создавай вибрации. Создавай ценность» ©
6.3. Подбор сотрудников, расширение команды
Продуктовый менеджер также влияет на подбор сотрудников в свою команду. Помимо технических скилов и опыта работы, важны совместимость с командой и соответствие ценностям компании. Проводить собеседования – отдельное мастерство.
Лучше познакомиться с рекрутерами и узнать об их tips and tricks. Если перенять опыт не от кого, остается только учиться на своих ошибках. Наём человека – это процесс: онбординг, адаптация, испытательный срок. За 2–3 месяца нужно убедиться, что это именно тот человек, поскольку ответственность на… ну, сами знаете, на ком.
6.4. Увольнение
В каких-то компаниях менеджер может отстранить участника команды, а в некоторых – только повлиять на увольнение. Суть не меняется. Увольнение человека – наверное, одна из сложнейших задач менеджера в коммуникации (по крайней мере, для меня). Главное быть уверенным в причине, вооружиться аргументами, несколько раз проанализировать ситуацию, которая привела к необходимости расстаться – и сообщить коллеге, что он уволен.
7. Общение с топ-менеджментом (уровень С, executives, founders, investors)
Для себя я определил, что данный пункт был и порой до сих пор является сложнейшей из задач продуктового менеджера. Сложность заключается в мышлении и принятии решений на совсем другом уровне абстракции. Говоря на языке agile, это общение на уровне тем (themes) или инициатив (initiatives).
Здесь больше о стратегии, чем о тактических действиях. Взаимодействие с топ-менеджментом – решение задач с множеством неизвестных переменных, что сильно выводит из зоны комфорта и расширяет взгляд на многое в продукте и компании.
Если кратко, то вся работа сводится к исследованиям рынка или ниши, поиску инсайтов, вычитки бизнес-отчетов, и т. п. Все эти действия нужны для того, чтобы подкрепить заданный уровень абстракции цифрами и фактами. чтобы в будущем преобразовать его в тактические задачи.
Выводы
Задачи продуктового дизайнера и продуктового менеджера и пересекаются между собой, и сильно разнятся.
Дизайнер, выполняя задачи, входящие в компетенцию продуктового менеджера, делает две вещи:
прокачивается в скилах, которых ему может не хватать;
снимает с продуктового менеджера часть нагрузки и дает ему возможность эффективнее выполнять свои задачи.
Если вы задумались о романтике продуктового менеджмента, представьте себя решающим задачи в рамках одного из векторов, описанных выше. Представили? А теперь забудьте, потому что в течение дня продуктовый менеджер переключается между этими векторами очень часто.
Случай, когда ты делаешь одну задачу в конкретный период времени, не переключаясь, – роскошь. Хорошо это или плохо? Сложно ответить. Скорее всего это задачи разного типа. Если ты сразу проскролил статью вниз, то сделаю здесь затравку, чтобы тебе захотелось вернуться как минимум ко второй части.
Готов ли ты как дизайнер или любой другой специалист менять контекст в течение дня по несколько раз? Готов ли ты к тому, что 70–80% твоего времени составляет коммуникация? Готов ли ты к тому, что результаты твоей работы не всегда сразу можно увидеть и «пощупать»?
Тогда, если есть цель, к ней стоит стремиться. Главное – учитывать все нюансы.
===========
Источник:
habr.com
===========
Похожие новости:
- [Анализ и проектирование систем, Проектирование и рефакторинг, Управление продуктом] Смешение уровней абстракции закладывает бомбу в основание вашего проекта
- [Управление продуктом, Карьера в IT-индустрии, Финансы в IT, IT-компании] Mozilla сократит 250 человек из-за пандемии
- [Управление проектами, Управление продуктом, Искусственный интеллект] Разработка AI-продукта на основе машинного зрения. Промежуточная ретроспектива: мысли, боль, страдания
- [Программирование, Управление разработкой, Управление проектами, Управление продуктом, DevOps] Типовые ситуации при непрерывной интеграции (перевод)
- [Учебный процесс в IT, Управление продуктом, Карьера в IT-индустрии] Как нанимать IT-специалистов. Опыт продакта
- [Развитие стартапа, Управление продуктом] Как мы организовали процесс разработки гаджетов от идеи до производства в стартап-инкубаторе
- [Управление продуктом, Управление продажами] Три фактора, которые недооценивают руководители отдела продаж
- [Управление разработкой, Развитие стартапа, Управление продуктом, Карьера в IT-индустрии] Создание программного продукта и управление его развитием
- [Управление разработкой, Управление сообществом, Управление продуктом, Конференции] Открытый Demo Day в Райффайзенбанке: проекты, фичи и немного магии
- [Развитие стартапа, Управление продуктом, Управление продажами, Бизнес-модели] Free Trial, motherf***er, do you need it? — или почему бесплатные траялы и фримиум модели подходят далеко не для всех
Теги для поиска: #_upravlenie_produktom (Управление продуктом), #_produktovyj_dizajn (продуктовый дизайн), #_produktovyj_dizajner (продуктовый дизайнер), #_produktovyj_menedzhment (продуктовый менеджмент), #_produktovyj_menedzher (продуктовый менеджер), #_product_management, #_product_design, #_upravlenie_produktom (
Управление продуктом
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 15:53
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Меня зовут Ростислав Салата, я работаю в киберспортивной организации без малого три года. Пришел в компанию на должность проектировщика интерфейсов, дорос до UX-лида, и в настоящее время являюсь продуктовым менеджером. Задачи продуктового менеджера и подход к работе у нас сильно отличаются от обязанностей продуктовых менеджеров в других компаниях. Это значит, что в вашей компании представления о функционалах и наборе скилов для продуктового менеджера и дизайнера могут отличаться. Например, в некоторых компаниях продуктовый менеджер проектирует интерфейсы, а у нас – нет. Почему я поднял эту тему? Мы провели очень много собеседований с продуктовыми дизайнерами. Опираясь на свой опыт и опыт коллег, могу смело сказать, что вопрос о круге обязанностей задает каждый претендент. Разное понимание зон ответственности может впоследствии привести к конфликтам, которые пагубно повлияют на продукт. Ниже не будет чек-листов и стопроцентной инструкции о том, как перейти в менеджмент. В первой части статьи я развею мифы о «кажется, я уже продакт». Во второй части расскажу о реальных задачах менеджера по продукту. Точнее о тех, с которыми я сталкиваюсь ежедневно и которые должны развеять идеалистическое представление о том, что такое продуктовый менеджмент. Часть 1. Я и мой продакт-менеджер выполняем похожие задачи. Получается… я продакт-менеджер? Есть качества, отличающие опытного продуктового дизайнера от начинающего. Поэтому предлагаю обсудить черты тех специалистов, которые на глубинном уровне понимают дизайн, замеряют его эффективность и влияние на решение бизнес-задач. Почему-то обязанности сильных дизайнеров часто путают или пытаются добавить к задачам продуктового менеджера. Следующие шесть пунктов – это частые «ошибки» в понимании задач этих специалистов. По сути это функционал сильного продуктового дизайнера, но почему-то многие считают, что, если он так думает и поступает, то автоматически становится менеджером. 1. Из твоего лексикона пропадают фразы «это не моя работа» или «это не моя зона ответственности» Ты не закрываешь глаза на ситуацию, если знаешь, что можешь помочь решить или исправить её. Ты готов подхватить какой-то сторонний процесс без вреда для текущей нагрузки. Ты понимаешь значение слова «ответственность» и готов брать ее на себя. Ловишь себя на мысли, что перестаешь говорить всем подряд, что они недостаточно компетентны. Вместо этого находишь способы тактично донести конструктивную критику до каждого. Многие дизайнеры, да и другие специалисты индустрии могут подумать, что это первые шаги на пути к менеджменту. И да, и нет. Кто говорит, что продуктовый дизайнер несет меньшую ответственность за продукт, чем продуктовый менеджер? Продуктовым дизайнерам никто не запрещает (даже наоборот!) замечать глюки, давать советы, помогать строить или дополнять командные процессы. Хорошего продуктового дизайнера и отличают те модели поведения, которые я описал ниже. 2. Начинаешь самостоятельно искать инсайты и их источники В большинстве случаев принятие решения о реализации того или иного функционала остается за продуктовым менеджером. Очень часто дизайнеру, в том числе и продуктовому, приносят список проблем и болей пользователей, которые нужно решить с помощью дизайна. Если же ты сам находишь эти проблемы, задачи, потребности или боли, возникает мысль: а не должен ли этим заниматься продуктовый менеджер? Если кратко, то да. И не только этим. Определение проблем пользователей – часть дизайн-процесса. «Интерфейсная экспертиза», безусловно, очень важна, но она должна сопровождаться постоянной работой с пользователями. Правда, чаще выходит, что именно дизайнер, а не продакт, находит большинство инсайтов и внедряет их в продукт. 3. Понимаешь, что внедряемая фича влияет не только на пользователя Дизайнеры часто аргументируют свои предложения пользовательским фидбэком из анкетирования, интервью, комментариев в социальных сетях и запросов в support, говоря о том, что пользователи – наше всё. Без сомнения, так и есть. От пользователей можно и нужно черпать инсайты. Но не пользователем единым. Когда ты начинаешь думать, что разрабатываемая фича Х может использоваться в разных каналах коммуникации, влиять на финансовую модель продукта, юридические правила и политику его использования, стратегические цели продукта и компании в целом, то становишься намного ценнее и полезнее для продукта и команды в целом. Это очень хороший маркер твоего дизайнерского хард-скила. Многие дизайнеры знакомы с понятием омниканальности. В работе над продуктом стоит отталкиваться от этого понятия и тщательно продумывать предложенные пользовательские фичи. Почему же дизайнер не должен думать о влиянии внедряемых решений на продукт во всех точках его контакта с пользователями? Если ты продуктовый дизайнер, то это просто must have. Консистентность, детализация и продуманность дизайн-решений на всех уровнях – это топ-скилы дизайнера. 4. Смещение фокуса с дизайна в привычном для всех понимании Дизайнер в первую очередь работает с интерфейсом продукта. Результатом его работы должен быть визуально приятный и удобный интерфейс. Об этом не стоит забывать, ведь перевод фокуса на глубинный анализ может принести больше вреда, нежели пользы. Иногда дизайнеры настолько погружаются в ресерч, аналитику и другие продуктовые вопросы, что забывают о важности первого впечатления пользователя о продукте. Если понимаешь, что интерфейс и визуальная коммуникация продукта начинают волновать тебя меньше всего, может, стоит думать не о дизайне или менеджменте, а о позиции исследователя? 5. Появляется ощущение, что предлагаемые фичи не несут пользу продукту С этим ощущением надо быть аккуратным, так как оно может быть связанным с чувством собственной важности (ЧСВ). Бывает, что внедрение фич обосновывают лишь «я так считаю», «мне виднее» или «пользователям так точно будет удобнее». Хорошо уметь анализировать фичи с точки зрения пользы для продукта или компании. Как это сделать? Провалидировать и аргументировать идею. Занимаются ли этим только продуктовые менеджеры? Хороший вопрос. Кем бы ты ни был, дизайнером или менеджером, любые ощущения лучше сопоставлять с фактами и цифрами, а решения – аргументировать. 6. У тебя меняется отношение к продуктовым метрикам Зачастую метрики уже сформированы. Вся команда работает над их достижением, и дизайнер – не исключение. Круто, когда у тебя появляются мысли о том, что текущие показатели можно пересмотреть, доработать для более правильной интерпретации, в крайнем случае создать или добавить новые. Смотреть на продуктовые показатели под другим углом – хороший навык. Но говорит ли наличие этого навыка о том, что ты на пути к продуктовому менеджменту? Скорее нет, чем да. Будучи продуктовым дизайнером, ты можешь (должен?) проверять свои решения на соответствие метрикам, и, вероятнее всего, научишься смотреть на показатели эффективности шире. Добавление новых фич или итерации существующего функционала должны соответствовать целям продукта или компании. Продуктовый дизайнер должен опираться на метрики и смотреть на них в более широком контексте. Это не указывает на то, что специалисту пора переходить в менеджмент. И правда, получается, что обязанности продуктового дизайнера и продуктового менеджера во многом пересекаются. Чем тогда на самом деле занимается продуктовый менеджер? Часть 2. Какие задачи решает продуктовый менеджер в реальной жизни? Будем откровенны: чаще всего продуктовый менеджер занимается чем угодно, кроме своих прямых задач. Если ты продуктовый менеджер и дочитал до этого раздела, то точно улыбнешься, вспомнив себя в роли маркетолога, дизайнера (особенно графического), продажника, разработчика, проектного менеджера, пиарщика и т. д. Да, я тоже был во всех этих ролях, но чего уж там, дизайнер из меня не получается и не получится никогда. Ниже я собрал основные векторы, в рамках которых продуктовые менеджеры выполняют свои «незаметные» задачи с «невидимыми» результатами работы. 1. Фокус, консолидация, коммуникация. Фокус. Продуктовый менеджер должен быть сфокусирован на получении прибыли от своего продукта. Другими словами, на заработке денег для компании. Стремление сделать проект прибыльным должно быть здравым, а не фанатичным. Фанатизм рассмотрим на примере вывода нового продукта на рынок. Менеджер должен понимать: если его продукт нестабилен и не покрывает базовых потребностей своего рынка, то ни о какой монетизации не может быть и речи. Почему? Если требовать с пользователей плату лишь за отличительные ценности, не покрывая их базовые потребности, высока вероятность напортачить в самый важный момент. Консолидация. Продуктовый менеджер должен быть source of truth для команды. Продакт как сито – он собирает тонну информации, просеивает ее и передает команде в виде понятного технического задания. В качестве примера рассмотрим работу с sales-менеджерами или маркетологами на этапе внедрения или валидации какой-либо гипотезы. Перед тем, как передать гипотезу в работу другим отделам, ты должен проработать информацию. С одной стороны, не придется отвечать на наводящие вопросы. С другой стороны, ты задашь стратегический вектор, в рамках которого нужно будет копать. Коммуникация. В моем идеальном мире работа продуктового менеджера должна распределяться так:
Как видим, 70% времени составляет коммуникация, хотя первые 30% задач тоже так или иначе с ней связаны. Коммуникация – это налаживание процессов, решение внутренних проблем в команде, встречи с представителями других департаментов, включая маркетинг и т. д. Очень часто в развитии продукта помогают хорошие soft skills, даже если ты начинающий продакт. Один из важных результатов работы продуктового менеджера – выстроенная коммуникация. Это одна из сложнейших частей работы, поскольку нет результата, который можно «пощупать». 2. Сотрудничество с отделом продаж (Business Development) Большинство продуктов рано или поздно выходят на стадию монетизации. Так как главная задача продуктового менеджера – создание прибыли, общение с отделом продаж поможет лучше понять продукт и рынок в целом. Некоторые компании не всегда дают возможность общаться с отделом Business Development, но мне повезло. Совместная работа с менеджерами по развитию бизнеса создает условия для более качественной продажи вашего продукта. Sales менеджеры должны понимать продукт, знать сильные и слабые стороны, а также болевые точки пользователей. Тогда они сделают upsell в нужный момент. 3. Организация кросс-командных процессов Если у вашей компании достаточно ресурсов для того, чтобы задействовать несколько команд для решения задачи, нужно наладить обмен информацией, чтобы согласовывать действия. Процесс рутинный, но без него не обойтись. Возьмите на себя ответственность и создайте регулярные мероприятия для коммуникации разных команд. Да, это не быстро. Да, это сложная коммуникация. Да, вероятность игнора высока. Но отношение коллег и доступ к своевременной информации стоят. Этот кейс хорошо описывает задачу взаимодействия в кросс-командах. 4. Правильная постановка целей и задач для команды Цели. Каждый член продуктовой команды должен понимать, для чего мы «это» делаем и куда идем. Неважно, что это: апдейт текущей фичи, разработка нового сценария или выход еще на один рынок. Интересоваться видением команды по поводу целей продукта в неформальной обстановке – это хорошая практика. Задачи. Как продуктовый менеджер ты должен быть уверен, что тебя понимают так же, как ты понимаешь себя сам. Достаточно часто я сталкивался с тем, что мои ожидания не всегда очевидны для команды. Поэтому перед постановкой задачи стоит удостовериться, все ли понимают, что должно получиться в итоге, и зачем вообще делать эту работу. Такой себе definition of done, отвечающий на вопрос «что?» со стороны продукта. Команда же ответит на вопрос «как?». 5. Аргументация и навязывание В нашей команде любые доработки проходят через стадию аргументации. Даже если решение пришло «сверху», команда должна понимать и разделять его. Понимание задач в целом и погружение в детали – это инвестиция в развитие продуктового мышления у всех участников. Если инвестировать в это время, мы получим очень здравую внутреннюю группу валидаторов, которые не пропустят «какую-то дичь» к пользователям. Иначе команда будет просто исполнителем. Кому-то это подходит, кому-то – нет. В моей компании любой из членов команды является полноправным участником продуктовой разработки и может критиковать предложенные подходы или предлагать свои. 6. Управление продуктовой командой Важно не теоретическое понимание процесса разработки, наличие сертификата по Agile от Coursera, а то, готов ли ты организовать команду и взять ответственность за эффективность и результат её работы. Важно чувствовать, в какие моменты нужно поддержать участников команды, попросить о помощи, а когда – спросить их мнение. Может показаться, что это полная чепуха. Но понимая настроение коллег, зная их ритуалы, ты получишь тонну инсайтов для построения крутой команды. Продуктовые менеджеры до последнего «шатают» предлагаемую гипотезу перед тем, как добавить новую фичу или улучшить что-то работающее: проверяют корнер-кейсы, ищут сильные аргументы в пользу внедрения гипотезы в работу. Еще продакт выясняет, с помощью каких KPI будет измеряться результат предполагаемых изменений, если гипотезу примут, а также в рамках какой цели ее будут проверять. 6.1 Стоимость команды и внедряемых решений Теперь не о романтике. Помимо стандартной эстимации, как продакт-менеджер ты должен просчитывать финансовую эффективность ресурса, который планируешь потратить. Понимая стоимость часа твоей команды, начинаешь смотреть через призму финансовой эффективности на любое предложение и гипотезу. Стоимость разработки и ожидаемая прибыль от изменений в функционале играют не последнюю роль в принятии решений. Думаю, что знание финансовой стороны работы команды усиливает главный скил продуктового менеджера: умение говорить «нет». 6.2. Кадровая эффективность В некоторых компаниях продуктовый менеджер участвует в регулярных ревью членов команды. По объективным причинам обсуждение технических скилов на уровне ревью находится вне зоны влияния менеджера (если ты, конечно, не Technical Product). А вот оценка персональной эффективности и ее влияния на работу в команде – самое то. Продуктовый менеджер может и должен влиять на оценку эффективности сотрудника в команде. Звучит немного эгоистично, но команда – это ресурс, который должен самоотверженно и эффективно работать на благо продукта. Для оценки и обсуждения факторов, влияющих на эффективность работы сотрудника, можно использовать следующие подходы:
«Не создавай вибрации. Создавай ценность» © 6.3. Подбор сотрудников, расширение команды Продуктовый менеджер также влияет на подбор сотрудников в свою команду. Помимо технических скилов и опыта работы, важны совместимость с командой и соответствие ценностям компании. Проводить собеседования – отдельное мастерство. Лучше познакомиться с рекрутерами и узнать об их tips and tricks. Если перенять опыт не от кого, остается только учиться на своих ошибках. Наём человека – это процесс: онбординг, адаптация, испытательный срок. За 2–3 месяца нужно убедиться, что это именно тот человек, поскольку ответственность на… ну, сами знаете, на ком. 6.4. Увольнение В каких-то компаниях менеджер может отстранить участника команды, а в некоторых – только повлиять на увольнение. Суть не меняется. Увольнение человека – наверное, одна из сложнейших задач менеджера в коммуникации (по крайней мере, для меня). Главное быть уверенным в причине, вооружиться аргументами, несколько раз проанализировать ситуацию, которая привела к необходимости расстаться – и сообщить коллеге, что он уволен. 7. Общение с топ-менеджментом (уровень С, executives, founders, investors) Для себя я определил, что данный пункт был и порой до сих пор является сложнейшей из задач продуктового менеджера. Сложность заключается в мышлении и принятии решений на совсем другом уровне абстракции. Говоря на языке agile, это общение на уровне тем (themes) или инициатив (initiatives). Здесь больше о стратегии, чем о тактических действиях. Взаимодействие с топ-менеджментом – решение задач с множеством неизвестных переменных, что сильно выводит из зоны комфорта и расширяет взгляд на многое в продукте и компании. Если кратко, то вся работа сводится к исследованиям рынка или ниши, поиску инсайтов, вычитки бизнес-отчетов, и т. п. Все эти действия нужны для того, чтобы подкрепить заданный уровень абстракции цифрами и фактами. чтобы в будущем преобразовать его в тактические задачи. Выводы Задачи продуктового дизайнера и продуктового менеджера и пересекаются между собой, и сильно разнятся. Дизайнер, выполняя задачи, входящие в компетенцию продуктового менеджера, делает две вещи: прокачивается в скилах, которых ему может не хватать; снимает с продуктового менеджера часть нагрузки и дает ему возможность эффективнее выполнять свои задачи. Если вы задумались о романтике продуктового менеджмента, представьте себя решающим задачи в рамках одного из векторов, описанных выше. Представили? А теперь забудьте, потому что в течение дня продуктовый менеджер переключается между этими векторами очень часто. Случай, когда ты делаешь одну задачу в конкретный период времени, не переключаясь, – роскошь. Хорошо это или плохо? Сложно ответить. Скорее всего это задачи разного типа. Если ты сразу проскролил статью вниз, то сделаю здесь затравку, чтобы тебе захотелось вернуться как минимум ко второй части. Готов ли ты как дизайнер или любой другой специалист менять контекст в течение дня по несколько раз? Готов ли ты к тому, что 70–80% твоего времени составляет коммуникация? Готов ли ты к тому, что результаты твоей работы не всегда сразу можно увидеть и «пощупать»? Тогда, если есть цель, к ней стоит стремиться. Главное – учитывать все нюансы. =========== Источник: habr.com =========== Похожие новости:
Управление продуктом ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 15:53
Часовой пояс: UTC + 5