Предисловие 

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

Ошибки в работе неизбежны. Но ошибаться не страшно. Страшно не признавать свои ошибки и не делать выводов. В статье хочу поделиться своими ошибками и выводами, которые сделал. Статья будет полезна 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. Своевременно и открыто обсуждаем все проблемы.

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

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

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