Провалы в управлении: 5 распространённых ошибок продакт-менеджера
2026-02-21 19:30 Diff
https://skillbox.ru/media/management/provaly-v-upravlenii-5-rasprostranyennykh-oshibok-prodaktmenedzhera/

#Мнения

  • 5 июн 2024
  • 0

Почему нельзя завязывать все процессы на одного человека и как уменьшить количество созвонов — рассказала product owner.

Изображение: AFP Photo / Juan Mabromata / Getty Images

Рассказывает просто о сложных вещах из мира бизнеса и управления. До редактуры — пять лет в банке и три — в оценке имущества. Разбирается в Excel, финансах и корпоративной жизни.

О типичных ошибках в управлении продуктом рассказала

Ex-product owner клиентского приложения Flowwow. Более 16 лет работает в области управления и выстраивания процессов, шесть из которых — в IT-сфере.

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

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

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

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

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

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

Вот пять ключевых признаков «узкого горлышка» — наличие даже одного из них может привести к остановке работы команды:

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

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

Как это исправить? Первый шаг — зафиксировать всю информацию о процессах и продукте. Для этого можно нанять технического писателя, который за несколько недель соберёт данные с носителей знаний и перенесёт их на «бумагу».

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

Кадр:  фильм «Легенда» / Cross Creek Pictures

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

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

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

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

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

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

Как это исправить? Определите целевые задачи для каждого члена команды и исходя из этого спланируйте загрузку — в том числе и участие в созвонах.

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

При таком подходе основное время разработчиков занято целевой работой, а звонки занимают порядка 3–4 часов в неделю, включая дейли, ретро и другие регулярные созвоны команды. Например, мы во Flowwow таким образом сократили затраты времени разработчиков в 1,5–2 раза.

Эта ошибка касается продактов, чьи команды выпускают мобильные приложения одновременно для iOS и Android.

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

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

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

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

Пренебрежение техническим заданием

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

Часто продакт-менеджеры либо пренебрегают техзаданием вовсе и обсуждают задачи устно, либо формируют его в удобном для себя формате.

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

Как это исправить? Формировать технические задания нужно так, чтобы они были понятны команде, которая будет с ними работать. Желательно уточнить у участников команды даже мелкие детали оформления, с которыми документ станет удобнее для них, — например, отступы, разбивку на абзацы, разделение на пункты и так далее.

Наиболее оптимальный формат ТЗ такой:

  • Название фичи.
  • Содержание документа.
  • Общее описание функциональности, цель, ценность.
  • Пошаговое описание требуемых действий, разделённое на пункты.
  • Дизайн или прототип, полностью согласованный с пунктами ТЗ.

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

Также ТЗ важно вовремя обновлять — вносить информацию обо всех изменениях, которые происходят в процессе работы над продуктом. Например, обновлять скорректированные юристами формулировки.

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

Задача → согласование → дизайн → разработка

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

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

Кадр: фильм «Стрингер» / Bold Films

Часто начинающий продакт боится ошибиться и принять неправильное решение. Поэтому он каждый раз проводит весь «идеальный процесс» с нуля даже после незначительных правок — всё это занимает недели.

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

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

Как узнать больше о продакт-менеджменте

Курс с трудоустройством: «Профессия Продакт-менеджер» Узнать о курсе