13 грехов продакт-менеджера

28ddb3316d5980dc911abab5cb7ce52d.jpeg

Предисловие 

Чтобы качественно решать проблемы пользователей, продакт-менеджер должен обладать широким набором компетенций: исследования, аналитика, критическое мышление, управление проектами, коммуникации и так далее.

Ошибки в работе неизбежны. Но ошибаться не страшно. Страшно не признавать свои ошибки и не делать выводов. В статье хочу поделиться своими ошибками и выводами, которые сделал. Статья будет полезна junior и middle продакт-менеджерам, которые хотят расти профессионально и карьерно.

Коротко об авторах 

Давид Мкртумян

Давид Мкртумян

Автор: Давид Мкртумян (Linkedin | FB | VK | Telegram | Instagram

Ведущий менеджер продукта в Авито. Автор канала Product Net, где можно узнать о продуктовых практиках Яндекса и Авито, получить карьерную консультацию и помощь с трудоустройством в ведущие IT-компании России.

Андрей Кардапольцев

Андрей Кардапольцев

Соавтор: Андрей Кардапольцев (Linkedin | FB)

Директор по продуктам ЛитРес. Ранее занимал руководящие должности в продуктовых командах Яндекс Маркета, YouDo и Рамблера.

Структура статьи 

Я выделил 13 ошибок, проранжированных от менее критичных к поистине греховным:

  1. Замалчивание проблем в команде

  2. Погружение в излишние детали

  3. Влюбленность в свои идеи

  4. Неумение делегировать

  5. Отсутствие фокуса

  6. Переработки

  7. Отсутствие плана Б

  8. Отсутствие письменных договоренностей

  9. Соглашательство

  10. Отсутствие синхронизации со смежниками

  11. Отсутствие гибкости в работе со стейкхолдерами

  12. Отсутствие долгосрочного видения продукта

  13. Не смотреть на продукт глазами пользователя

Далее подробно остановимся на каждой из них.

1. Замалчивание проблем в команде 

На прошлом месте работы у меня было немало проблем со стейкхолдерами. Я решил, что мне, как командному игроку, не стоит выносить сор из избы и не стал ничего писать на ревью про своих коллег. В результате, в ответ я получил кучу негатива, так как претензии были взаимными, но заказчики молчать не стали. В итоге, несмотря на то, что все OKR были выполнены, я был вынужден искать варианты перехода в другое направление внутри компании.

Почему это ошибка?  

  • Если ты промолчишь, а оппоненты по конфликту — нет, то окажешься в роли оправдывающегося. Это далеко не самая выгодная позиция.

  • Если коллеги не получают негативных сигналов, то они уверены в правильности своих действий. В результате проблема будет повторяться. Таким образом, замалчивая, ты не способствуешь профессиональному развитию коллег и культуры внутри компании.

Какие могут быть последствия?

  • Препятствует развитию коллег, команды и культуры внутри компании.

  • Может помешать карьерному росту и даже стать причиной увольнения.

Как надо?  

  • Во-первых, все проблемы нужно обсуждать и стараться решить их сразу после возникновения. Корректирующую обратную связь стоит давать один на один по модели SBI (Situation, Behavior, Impact), например:

S — на командном синке в пятницу

B — ты прервал меня во время аргументации решения 

I — в итоге команда, не получила важный контекст и не поняла, почему было принято такое решение. Кроме того, это было неуважительно и демотивировало меня и команду. 

  • Во-вторых, если откровенный разговор один на один не дал эффекта, стоит подсветить ситуацию HRBP. Лучше, чтобы коллеги из HR знали о потенциальной проблеме заранее и могли мягко скорректировать действия коллеги. Кроме того, потом ты не окажешься в роли оправдывающегося, так как первым подашь сигнал.

  • В-третьих, корректирующий фидбек должен быть дан на ревью. Не стоит ожидать, что если вы обсудили ситуацию с глаза на глаз, то конфликт исчерпан. Это может обернуться неприятным сюрпризом на ревью, как было в моем случае.

2. Погружение в излишние детали 

Честно, я сам до сих пор работаю над этим недостатком. Как говорят мои руководители — почти все продакты грешат этим. Когда прорабатываешь решение, то настолько погружаешься в аргументацию, что каждая деталь кажется важной. В итоге, при защите решения или в обсуждениях ты вываливаешь на коллег кучу информации, которая тяжело воспринимается теми, кто не в контексте, и не позволяет принять быстрое решение.

Почему это ошибка?  

Большинство смежников или стейкхолдеров не имеют глубокого погружении в контекст, да и не нуждаются в этом. Им нужно быстро уловить суть и принять наиболее правильное решение. Обилие лишней информации мешает этому.

Какие могут быть последствия?

  • Идею можно просто не «продать» коллегам, если перегрузить их деталями.

  • Неумение кратко и емко презентовать мысли мешает карьерному развитию.

Как надо?  

Нужно очень кратко доносить:  

  • Кто ЦА продукта?

  • Какую боль мы решаем?

  • Какой масштаб проблемы?

  • В чем идея продукта?

  • Какое решение предлагаем?

  • Какие результаты ожидаем?

Всю детальную аргументацию и расчеты прячем в гиперссылки. Коллегам показываем только тезисы. Если они с ними не согласны, то предоставляем дополнительную аргументацию по ссылке. 

3. Влюбленность в свои идеи 

Один из бывших руководителей говорил мне: «Давид, ты влюбляешься в свои фичи, и лелеешь их как собственных детей».

Почему это ошибка?  

С трепетным отношением к своим идеям ты рискуешь потерять критичный взгляд, не увидеть существенные риски или переоценить предполагаемые возможности.

Какие могут быть последствия?

  • На этапе реализации могут выстрелить риски, которые повлияют на качество запуска, либо просто сделают запуск невозможным.

  • Продукт не будет востребован среди пользователей.

  • Падение продуктовых метрик или выручки.

  • Напрасная трата ресурсов команды, демотивация или выгорание.

  • Личные репутационные риски из-за неудачного запуска.

Как надо?  

Отношение к продукту должно строиться не на личном восприятии, а на:  

  • результатах UX-тестов,

  • аналитике,

  • трекшн-модели,

  • результатах АB-тестов.

Если все они покажут позитивные сигналы, тогда ты по праву можешь гордиться своим продуктом. До этого момента, это лишь гипотеза, не более. 

4. Неумение делегировать 

Фидбек с одного из моих ревью звучал так: «Давид склонен большую часть аналитической работы (когда есть готовые данные) делать самостоятельно, обращаясь за помощью к аналитику только в случае, когда нужна какая-то выгрузка. На мой взгляд, это не очень здорово, так как оставляет аналитику только эдхоки, не погружает его в контекст продукта, не позволяет стать частью команды.»

Почему это ошибка?  

Собственно, выше хорошо описано, почему это ошибка :)

Какие могут быть последствия?

  • Нельзя разбираться в каждом вопросе так же хорошо, как профильный специалист. Есть риск допустить ошибку, которая отразится на качестве продукта.

  • Если не будешь делегировать, то тебя просто задавит количеством задач и ты выгоришь. Я проходил через выгорание дважды. Никому не советую.

Как надо?  

Менеджер продукта потому и называется менеджером, потому что должен выстраивать процессы, управлять приоритетами и добиваться командного результата, а не делать все сам.

Ты должен четко определить цели, делегировать задачи экспертам в своей области и выстроить работу в команде так, чтобы деливерить результат в срок.

5. Отсутствие фокуса 

В период работы в Яндекс Маркете, Андрей дал мне ценный фидбек, который звучал примерно так: «Давид, ты берешься за очень много задач сразу, долго отсутствуешь на радарах, а затем в один момент выдаешь пачку результатов и снова пропадаешь. Будет лучше, если ты будешь фокусироваться на одной задаче, быстро достигать по ней результат и затем уже браться за следующую. Так ты будешь более заметен, быстрее достигать результат и обеспечивать прозрачность.»

Почему это ошибка?  

  • Расфокус негативно влияет на качество решений.

  • Деливери результатов происходит реже, бизнес упускает выгоду.

  • Работа продакт-менеджера становится непрозрачной для коллег, создается ощущение, что ты работаешь неэффективно.

  • Отсутствие visibility негативно сказывается на карьерном росте.

Какие могут быть последствия?

  • Неудачные запуски.

  • Дополнительная трата ресурсов на устранение ошибок.

  • Упущенная выгода из-за отложенных запусков.

  • Снижение доверия к продуктовой команде.

  • Блокирование карьерного роста и даже увольнение.

Как надо?

  • Приоритезируем задачи.

  • Согласовываем со стейкхолдерами последовательность выполнения задач.

  • Составляем роадмап выполнения задач.

  • Согласовываем сроки выполнения задач.

  • Фиксируем договоренности письменно.

  • В спринте фокусируемся на решении только одной задачи.

  • При появлении ad-hoc задач от заказчиков, подсвечиваем какие задачи сдвинуться, на какой срок, каковы будут последствия.

  • Письменно фиксируем изменения приоритетов, последствия, новые сроки и договоренности.

6. Переработки 

Это типичная ошибка многих работников IT. Мой личный антирекорд — двое суток работы без сна.

Почему это ошибка?  

  • Это просто вредно для здоровья и быстро приводит к выгоранию. А выгоревший работник — не работник.

  • Скорее всего, никто не оценит твои подвиги. Особенно будет обидно, если ты будешь выкладываться, а на ревью получать просто хороший результат.

  • Если ты будешь регулярно перерабатывать, то все начнут воспринимать это как норму и будут постоянно нарушать твои личные границы — писать в выходные или вечером и отрывать тебя от отдыха и восстановления.

  • Когда ты работаешь сверх нормированного времени, то даешь работодателю скидку на свои услуги, поскольку твои переработки не оплачиваются. Т.е. по факту ты занижаешь свою ЗП.

Какие могут быть последствия?

  • Депрессия и выгорание.

  • Проблемы со здоровьем.

  • Карьерные риски — когда выгоришь, твоя эффективность снизится, ты начнешь допускать больше ошибок и тебя могут просто уволить за плохой перформанс.

Как надо?  

  • Честно отрабатывай свои рабочие часы. Не трать время на перекуры, кофе и болтовню с коллегами.

  • Не работай регулярно больше 8 часов.

  • Не работай в выходные.

  • Ходи в отпуск 2 раза в год.

Переработки все равно будут. Но это должны быть разовые акции, которые возникают не чаще раза в квартал, когда нужно сделать рывок, чтобы затащить квартальные планы. Для таких случаев ты должен быть в ресурсе, а поэтому обязан регулярно и качественно отдыхать. 

7. Отсутствие плана Б 

Реализация любого продукта всегда связана с рисками — техническими, юридическими и другими. Раньше я прорабатывал только один целевой сценарий и какие-то очевидные риски. Я редко прорабатывал каждый этап воронки и отвечал на вопрос: «Что будем делать, если что-то пойдёт не так (например, на данном этапе продукт не будет перформить так, как мы планируем?)». Обычно, это приводит к тому, что какой-то риск обязательно выстреливает и команде приходится тратить дополнительные ресурсы на его устранение. 

Почему это ошибка?  

Если ты заранее не проработал риски, то в случае их реализации, придется тратить дополнительные ресурсы на их устранение. В лучшем случае это сдвигает сроки, а в худшем может поставить под угрозу весь проект.

Какие могут быть последствия?

Как надо?  

  • Строим воронку продукта.

  • На каждом этапе воронки отвечаем на вопросы:

  • Что может пойти не так? Какова вероятность реализации риска? Как будем митигировать риск? Сколько времени заложим на его устранение?

  • Закладываем время на устранение рисков в роадмап.

  • Подсвечиваем риски и их последствия стейкхолдерам.

  • Фиксируем все договоренности письменно.

8. Отсутствие письменных договоренностей 

У меня был кейс, когда прямо перед релизом один из стейкхолдеров утверждал, что команда продукта без согласования изменила параметры запуска, о которых договаривались ранее, и запускает совершенно не то.

В ответ я показал скриншот переписки, где этот стейкхолдер подтвердил тот список, который мы релизили. Если бы договоренности не были зафиксированы письменно, то это могло бы негативно повлиять как на перспективы запуска, так и на результаты performance review команды.

В итоге мы всё равно реализовали дополнительные запросы, о которых попросил стейкхолдер, но и на ревью получили благодарность за дополнительные усилия с нашей стороны. 

Почему это ошибка?  

Слова к делу не пришьешь. Если письменные договоренности отсутствуют, то то тебе будет не на что сослаться и тебя всегда могут сделать крайним и обвинить в чужих ошибках. 

Какие могут быть последствия?

  • Конфликты на стадии релиза из-за разного восприятия договоренностей.

  • Срывы релизов.

  • Переработки.

  • Репутационные и карьерные риски.

Как надо?  

Нужно оставлять цифровые следы. Все договоренности должны быть зафиксированы в рабочем чате или почте сразу после встречи. Обычно я фиксирую договоренности во время встречи и перед ее окончанием выравниваюсь с коллегами по написанному. После встречи, все договоренности должны быть сразу отправлены участникам встречи и другим заинтересованным стейкхолдерам.

9. Соглашательство 

Ещё одна распространенная ошибка среди молодых продактов — соглашательство, когда ты не челленджишь задачи и идеи заказчиков, а просто берешь их в работу.

Один раз я допустил такую ошибку, потому что не хотел обострять и без того непростые отношения с заказчиком. В итоге, как и прогнозировалось, реализованный нами продукт оказался просто не нужен пользователям. Разработчик, который работал над этим продуктом 1,5 месяца, был сильно демотивирован, и мне пришлось приложить массу усилий, чтобы вернуть его в строй. 

Почему это ошибка?  

Заказчик может не знать всех подводных камней продукта. Просто соглашаясь, ты рискуешь потратить ресурсы на бесперспективные задачи или, что еще хуже, — ухудшить опыт пользователей и метрики продукта.

Какие могут быть последствия?

  • Ухудшение пользовательского опыта.

  • Падение метрик продукта.

  • Потеря выручки.

  • Неэффективная трата ресурсов.

  • Выгорание команды.

Как надо?  

Нужно подсвечивать заказчику потенциальные риски и предлагать альтернативные, менее рискованные решения, либо конкретный план действий. 

10. Отсутствие синхронизации со смежниками 

Однажды, работая над оптимизацией каталога, я обнаружил, что основной бизнес, который продается в категории «Общественное питание» — это точки с шаурмой. Также на этот бизнес был самый большой спрос среди покупателей по данным в wordstat.

Исходя из этого, я решил назвать категорию «Шаурма и другой общепит», что действительно дало прирост в показах и контактах. Казалось бы — успех. Но бизнес-заказчик и маркетинг вернулись с негативным фидбеком.

Во-первых, на конференции рестораторы, которых в категории меньшинство, сказали, что им не комильфо продвигать свои рестораны в категории, где в названии фигурирует слово «шаурма». Во-вторых, маркетинг сказал, что в бизнесовой категории должен соблюдаться деловой tone of voice. В итоге название пришлось откатить. 

Почему это ошибка?  

Учесть весь контекст очень сложно. Даже при положительных показателях, я упустил контекст, связанный с продвижением и продажами. Поэтому важно выравниваться по предлагаемым решениям со всеми стейкхолдерами до старта разработки. 

Какие могут быть последствия?

  • Дополнительная трата ресурсов.

  • Конфликты внутри команды.

  • Репутационные риски.

Как надо?  

Вырванимаваться с заказчиками на всех этапах дискавери, а не только в начале:  

  • На этапе проработки проблемы.

  • На этапе разработки решения.

  • На этапе создания дизайна решения.

  • Финально выравниваемся перед передачей задачи в разработку.

11. Отсутствие гибкости в работе со стейкхолдерами 

Раньше я часто допускал эту ошибку. Я считал, что следование продуктовым процессам и подкрепление своего мнения данными дает мне право отказать в реализации идеи.

Почему это ошибка?  

Нужно понимать, что стейкхолдер приходит с задачей не просто так. Возможно, задача «спущена сверху», или решение этой задачи поможет выполнить личные KPI этого стейкхолдера.

Если ты отказываешь стейкхолдеру, то ты оставляешь его наедине с проблемой. В итоге, может быть, ты и сэкономил ресурсы и не реализовал что-то ненужное, но ты оставил заказчика с проблемой и подпортил отношения в команде, а также дал ему основание блокировать твой карьерный рост в будущем. 

Какие могут быть последствия?  

  • Конфликты в команде.

  • Препятствия для карьерного роста, риски увольнения.

Как надо?  

  • Нужно докопаться до сути и понять, какую проблему заказчик хочет решить.

  • Понять масштаб проблемы, насколько она серьезная.

  • Понять, является ли предложенное заказчиком решение самым эффективным. Если нет, то предложить альтернативное решение.

  • Если ты не можешь с ходу предложить решение, то нужно предложить план действий по ее решению. Договориться о приоритетах, сроках исследования и ожидаемых результатах.

  • Определить, как эта проблема / решение соотносится с другими планами команды. Является ли новая задача более приоритетной?

Это не значит, что нужно брать задачу «под козырек». Можно отказать в решении проблемы предложенным способом, но обязательно предложить альтернативу или план действий с понятными сроками. 

12. Отсутствие долгосрочного видения продукта 

Мои самые свежие грабли. Мы много раз проговаривали видение продукта и я примерно понимал в какую сторону развивать продукт, и фокусировался на выполнении текущих OKR. При таком подходе часто возникала рассинхронизация, так как видение продукта не было зафиксировано письменно и, со временем, стало отличаться у разных участников. 

Почему это ошибка?

Отсутствие письменно зафиксированного видения порождает дополнительные споры при обсуждении продуктовых решений. В итоге тратится больше времени на согласование.

Кроме того, команде важно понимать: «Куда мы движемся в долгосрочной перспективе?» и «Как наша работа влияет на конечную цель / цели компании?»

Какие могут быть последствия?

  • Споры с заказчиками.

  • Трата ресурсов.

  • Демотивация команды.

  • Карьерные риски.

Как надо?  

Нужно формулировать финальное видение продукта на самом старте вместе со всеми стейкхолдерами и фиксировать его письменно. О том, как формулировать видение писал здесь. Этот шаг сразу сформирует дискавери бэклог, так как видение нужно будет подтвердить качественными и количественными исследованиями. 

13. Не смотреть на продукт глазами пользователя 

Когда долго работаешь над продуктом, то часто зашориваешься. Имея контекст, многие решения в CJM кажутся интуитивно понятными, но не погруженному пользователю может быть сложно понять логику твоего решения. 

Почему это ошибка?  

Пользователь не обладает вашим контекстом и иначе смотрит на продукт. В итоге то, что кажется очевидным тебе, может быть абсолютно непонятно пользователю, что будет ломать CJM и метрики продукта.

Какие могут быть последствия?

  • Дополнительные доработки и срыв сроков.

  • Плохой перформанс на этапе запуска продукта.

  • Негативный фидбек со стороны пользователей продукта.

Как надо?  

  • На этапе разработки дизайна нужно все время ставить себя на место пользователя и смотреть на продукт так, будто ты видишь его в первый раз.

  • Обязательно нужно согласовывать дизайн со стейкхолдерами. Они могут дать дополнительные полезные замечания.

  • Ну и конечно, надо прогонять продукт через UX-тесты. Но, чтобы UX прошел максимально гладко, нужно как следует выполнить предыдущие 2 шага.

Заключение 

На примере моих личных ошибок мы с Андреем подробно разобрали «грехи», которые часто совершают продакт-менеджеры.

Давайте коротко подытожим, как избежать их:  

  1. Всегда смотрим на продукт глазами пользователя.

  2. Формируем и письменно фиксируем долгосрочное видение продукта.

  3. Проявляем гибкость в работе со стейкхолдерами, но не скатываемся в соглашательство.

  4. Синхронизируемся с заказчиками и смежниками на всех этапах работы.

  5. Все договоренности фиксируем письменно и рассылаем коллегам.

  6. Всегда прорабатываем план Б, а не только позитивный сценарий.

  7. Не перерабатываем и копим силы для непредвиденных ситуаций.

  8. Фокусируемся только на одной наиболее важной задаче в спринт.

  9. Не пытаемся быть человеком-оркестром, делегируем задачи другим членам команды.

  10. Критично смотрим не только на чужие, но и на свои идеи.

  11. Не грузим коллег деталями, а только доносим суть, коротко и по делу.

  12. Своевременно и открыто обсуждаем все проблемы.

Надеюсь, что статья была полезна и поможет вам в профессиональном и карьерном развитии!  

Буду благодарен обратной связи в комментариях!

Расскажите какие ошибки совершали вы и какие выводы сделали из них?

© Habrahabr.ru