10 качеств плохого продакт-менеджера
Как не быть плохим, а быть хорошим менеджером продукта.
Ситуация:
(заказчик) - У меня ощущение, что проект полностью вышел из-под контроля. Когда мы наконец получим работающий продукт?
(продакт) - Не волнуйтесь, все идет по расписанию! Мы опережаем график и даже сэкономили часть бюджета. Так что я пойду, мне еще нужно закатить пару новых фич от разработчиков...
Если такие реплики вам знакомы, возможно, ваш продакт-менеджер страдает одним или сразу несколькими "профессиональными" недугами. Рассмотрим 10 самых популярных.
Списком
1. Отсутствие ответственности.
Хороший продакт-менеджер берет на себя ответственность за успех или провал проекта. Плохой всегда найдет оправдания и виноватых со стороны. Раскладывал тему почему так происходит в этом посте.
2. Нечеткая коммуникация.
Эффективная коммуникация - ключ к успеху любого проекта. Плохой продакт-менеджер не может четко донести свои мысли и ожидания до команды.
3. Игнорирование обратной связи.
Хороший продакт-менеджер открыт для конструктивной критики и готов учиться. Плохой игнорирует замечания и советы команды и заказчика.
4. Отсутствие гибкости.
В мире IT изменения неизбежны. Плохой продакт-менеджер цепляется за первоначальный план, невзирая на обстоятельства.
5. Нечеткие приоритеты.
Хороший продакт-менеджер умеет расставлять четкие приоритеты. Плохой тонет в хаосе, пытаясь угнаться за всем сразу.
6. Недостаток технических знаний.
Плохой продакт-менеджер имеет поверхностное представление о технологиях, задействованных в проекте, что мешает эффективной работе.
7. Плохое планирование.
Хороший продакт-менеджер тщательно планирует каждый шаг. Плохой импровизирует на ходу, что приводит к срывам сроков.
8. Нежелание принимать трудные решения.
В обязанности продакт-менеджера входит принятие сложных решений. Плохой менеджер постоянно оттягивает этот момент.
9. Конфликтность.
Хороший продакт-менеджер - дипломат, умеющий находить компромиссы. Плохой сеет раздор в команде своим поведением.
10. Самонадеянность.
Сильный продакт-менеджер постоянно учится и совершенствуется. Плохой считает, что уже все знает, и отказывается развиваться.
Коротко итог
В мире IT плохой продакт-менеджер - почти что профессиональный киллер, который может убивать продукту. Если вы узнали себя в описанных признаках - не впадайте в уныние! Каждый может измениться к лучшему. А, если увидели такого в своей команде, покажите ему список выше и дайте обратную связь, может поменяется и хорошим станет.
А какие еще качества плохого продакта вы можете добавить в перечень выше? Поделитесь мнением в комментариях!
—
Больше мыслей про IT и продукт в моем канале alexcouncil, подписывайтесь.
У меня ощущение, что проект полностью вышел из-под контроля. Когда мы наконец получим работающий продукт?На такой вопрос есть только один правильный ответ: в установленные графиком работ сроки. И этот ответ вы почему-то считаете неверным.
Хороший продакт-менеджер берет на себя ответственность за успех или провал проектаЭто не продакт менеджер, а product owner (с немного другой мотивационной схемой, кстати). Тот да, берет на себя еще и всю бизнес составляющую и отвечает за успех или провал. А продакт менеджер отвечает за продукт и его соответствие бизнес-требованиям заказчика
Нечеткая коммуникацияТо, о чем пишите вы - это не про коммуникацию, а про умение ставить ТЗ
Игнорирование обратной связи. Хороший продакт-менеджер открыт для конструктивной критики и готов учиться. Плохой игнорирует замечания и советы команды и заказчика.Смешались в кучу мухи, котлеты, кони, люди... Смотрите, в нормально выстроенной работе у вас есть понятные стадии (упрощу до уровня второклассника, чтобы не душнить):
1. Сбор, валидация, оформление БТ. Все советы от заказчика принимаются и фиксируются на этом этапе.
Когда этап завершен и БТ зафиксированы подписью заказчика, никакие советы от него больше не принимаются. Либо принимаются, но на аналогичный этап версии 2.0 продукта. Иначе вы БТ не соберете никогда, потому что заказчику новые идеи (одна охуительнее другой просто) приходят примерно 2-3 раза в сутки
2. Продуктовая проработка и составление концепта ТЗ (ответ на вопросы "Что и зачем должен делать продукт?") На этом этапе продакт активно обращается к заказчику, но не за советом, а за ответом на вопрос "Я вижу, что продукт должен делать сепульку, чтобы закрыть клиентские потребности 1,2,3 из БТ. Но я предложу добавить к сепульке еще какульку (вот UI прототип), тогда сразу закроем еще потребность 4,5,6. Вы согласны с таким решением?"
3. Техническая проработка (ответ на вопросы "Насколько это вообще реализуемо технически" и "Как должен работать продукт?"). Финал этапа - оформленное ТЗ, под которым подписались архитекторы, лиды разработки, лиды эксплуатации
На этом этапе собирается и обрабатывается вся обратная связь от команды. После подписания ТЗ любая обратная связь от команды (обычно в стиле "Ой, блядь, мы вот здесь херово подумали" или "А тут вот вышел фреймворк Х, давайте на нем сделаем") идет в раздел "Техдолг" продуктового бэклога, более нигде не учитывается
"На такой вопрос есть только один правильный ответ: в установленные графиком работ сроки. И этот ответ вы почему-то считаете неверным."
- Посмотрите немного шире на пример ответа. Неправильность не в форме самого ответа с план-графиком, а в том, что продакт довел до ситуации, где заказчик/стейкхолдер не понимает что происходит. Тут про прозрачность и управление ожиданиями.
"Это не продакт менеджер, а product owner (с немного другой мотивационной схемой, кстати). Тот да, берет на себя еще и всю бизнес составляющую и отвечает за успех или провал. А продакт менеджер отвечает за продукт и его соответствие бизнес-требованиям заказчика"
- Путается немного терминология и определения. Если продакт менеджер отвечает за соответствие бизнес требованиям заказчика, то это больше похоже на проджекта, которому говорят, что делать. Если же под бизнес требованиями подразумеваются бизнес цели, которых хочется достичь, в том числе через продукт, то соглашусь.
По теме product manager/owner как роли в РФ это примерно про одно и то же. У тебя есть бизнесовая цель и ты отвечаешь за нее через продукт и доверенный ресурс (команда разработки). За бугром функционал ролей может разниться.
"То, о чем пишите вы - это не про коммуникацию, а про умение ставить ТЗ"
Согласен.
По пунктам далее прокомментирую.
П.1 Дополню, можно и не собирать на самом деле БТ, а сильно экономить время и в процессе диалога сразу выяснить "Зачем? И как это поможет нашим целям?". Тупо сэкономите время.
Но такое возможно опять же, если роль продакта полноценная, оунерская вашими словами.
П.2.3 Да, обычная операционка.
Вы правы абсолютно. Не указал в статье, но по сути ты всегда должен учиться и изучать новые инструменты и технологии. Иначе в какой-то момент удивишься, что компетенции устарели.
Очень полезно и информативно. Узнала много нового о том, каких ошибок следует избегать в работе.
Рады стараться. Но как выше написали, нельзя забывать про постоянное обучение в том числе. Еще одной ошибкой будет остановка в изучении нового, которая тебя затормозит.