Предисловие
Чтобы качественно решать проблемы пользователей, продакт-менеджер должен обладать широким набором компетенций: исследования, аналитика, критическое мышление, управление проектами, коммуникации и так далее.
Ошибки в работе неизбежны. Но ошибаться не страшно. Страшно не признавать свои ошибки и не делать выводов. В статье хочу поделиться своими ошибками и выводами, которые сделал. Статья будет полезна junior и middle продакт-менеджерам, которые хотят расти профессионально и карьерно.
Коротко об авторах
Автор: Давид Мкртумян (Linkedin | FB | VK | Telegram | Instagram)
Ведущий менеджер продукта в Авито. Автор канала Product Net, где можно узнать о продуктовых практиках Яндекса и Авито, получить карьерную консультацию и помощь с трудоустройством в ведущие IT-компании России.
Соавтор: Андрей Кардапольцев (Linkedin | FB)
Директор по продуктам ЛитРес. Ранее занимал руководящие должности в продуктовых командах Яндекс Маркета, YouDo и Рамблера.
Структура статьи
Я выделил 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 шага.
Заключение
На примере моих личных ошибок мы с Андреем подробно разобрали «грехи», которые часто совершают продакт-менеджеры.
Давайте коротко подытожим, как избежать их:
Всегда смотрим на продукт глазами пользователя.
Формируем и письменно фиксируем долгосрочное видение продукта.
Проявляем гибкость в работе со стейкхолдерами, но не скатываемся в соглашательство.
Синхронизируемся с заказчиками и смежниками на всех этапах работы.
Все договоренности фиксируем письменно и рассылаем коллегам.
Всегда прорабатываем план Б, а не только позитивный сценарий.
Не перерабатываем и копим силы для непредвиденных ситуаций.
Фокусируемся только на одной наиболее важной задаче в спринт.
Не пытаемся быть человеком-оркестром, делегируем задачи другим членам команды.
Критично смотрим не только на чужие, но и на свои идеи.
Не грузим коллег деталями, а только доносим суть, коротко и по делу.
Своевременно и открыто обсуждаем все проблемы.
Надеюсь, что статья была полезна и поможет вам в профессиональном и карьерном развитии!
Буду благодарен обратной связи в комментариях!
Расскажите какие ошибки совершали вы и какие выводы сделали из них?
