13 грехов продакта

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

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

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

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

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

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

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

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

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

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

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

Как надо?

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

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

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

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

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

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

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

Как надо?

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

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

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

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

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

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

Как надо?

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

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

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

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

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

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

Как надо?

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

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

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

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

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

Как надо?

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

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

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

Как надо?

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

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

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

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

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

Как надо?

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

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

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

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

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

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

Как надо?

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

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

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

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

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

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

Как надо?

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

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

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

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

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

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

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

Как надо?

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

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

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

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

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

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

Как надо?

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

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

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

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

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

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

Как надо?

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

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

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

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

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

Как надо?

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

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

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

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

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