Как стать круче 99% продактов на рынке
Я за свою жизнь видел сотни продакт менеджеров. Многие из них отличные ребята, но плохие продакты, потому что фокусируются не на том: выполняют роль администратора, строят процессы, проводят ретроспективы. Этого обычно достаточно, чтобы получать зарплату, но недостаточно чтобы приносить пользу бизнесу. Есть 4 вещи, которые должен знать и делать…
А я вот очень не согласен с озвученными тезисами. За свою карьеру был и проджектом и продактом, был рядовым спецом, скрам мастером, замом руководителя отдела, CTO, была своя небольшая веб-студия, сейчас лид бэкенда в зарубежной компании. Работал в абсолютно разных компаниях - из самого интересного Drom, ABBYY, Unigine. Абсолютно в разных предметных областях.
И вот у меня напротив сложилось мнение что большинство продактов не эффективны потому что им скучно решать рутинные задачи - настраивать процессы, решать конфликты, разбираться в проблемах, декомпозировать задачи и прочее. Как раз куда интересней прочитать про какую-то новую метрику и добавить ее в аналитику и попытаться тут же сделать какие-то выводы и начать придумывать какие-то новые фичи.
В этом плане у меня есть прям много интересных примеров. Пожалуй, самый показательный - была одна компания где продакт как продакт был действительно неплох. В целом, можно сказать что он отвечал всем критериям из статьи. Он копался в данных, общался с пользователями, строил выводы, придумывал фичи, большинство из которых так или иначе решали поставленные задачи, проект рос и тп.
Но там же ему было абсолютно наплевать на то, как идет разработка. Было, например, много текущих багов прямо с прода. И был один инициативный парень, который их хватал прям в реалтайме и героически закрывал, его все очень люблю за это. У продакта была философия "важно исправить проблему, а не искать виноватых, поэтому причина - не важна". А вот мне было любопытно. Я построил анализ и по каждому багу смотрел после исправления а чей код до этого это вызвал. Собственно, оказалось, что примерно 9 из 10 багов были порождены кодом этого героя. Фактически, человек работал год и процентов 80 его времени уходило на исправление багов, которых бы просто не возникло, если бы его делал кто-то еще. Иными словами, большая часть его зарплаты уходила в трубу. Он исправлял свои косяки и все.
При чем это все было достаточно очевидно и без аналитики, цифры в итоге просто подтверждали проблему. Но если в них углубляться - то надо неприятные разговоры вести, возможно, кого-то увольнять и тд. А зачем, если можно жить в мирке продукта и новых фич?
В общем и целом, разработка шла ощутимо медленнее чем могла бы быть. С того времени прилично лет прошло. И сейчас уже с высоты опыта могу точно оценить что стоило половину команду заменить и остальные бы при более отточенных процессах выдавали бы минимум раза в два больше результата (там в принципе можно было работать одним пальцем, если грубо, зависело только от твоей совести и ответственности)
Потом там решили таки заняться процессами, повысили человека, который к роли вообще не подходил. Это привело к куче конфликтам, переигровке, но по итогу - тому, что немаленькая часть команды ушла (и не та, которой бы стоило уйти).
Мораль истории - хороший продакт как раз либо должен иметь хорошего проджекта в помощь (который не администрированием занимается), или сам в это хотеть лезть. Да, там скучнее и прочее. Но когда человек живет на каком-то верхнем уровне и его идеи реализуются медленнее, чем могли бы - в конечном счете это тоже вопрос к нему. Он главный по продукту. И даже если администрирует кто-то, кроме него - за качеством этого администрирования тоже надо следить.
Поэтому в моем мире - хороший продакт понимает, что вопрос КАК делать ничуть не менее важный чем вопрос ЧТО делать и ПОЧЕМУ делать именно это. При этом делегируя КАК он в состоянии это контролировать.
Условно, если продакт придумал 10 хороших идей, но конкурент за время N реализовали 5 из них, а его команда реализовала, условно 1 за тот же срок - наверное, количество идей не то, над чем стоит работать в этом случае.
У вас отличный пример, но в нем продолбался не продакт, а кто-то из технической команды (техлид или CTO). Я согласен, что чем шире смотрит продакт, тем лучше. Но если он единственный, кто смотрит за всеми частями процесса доставки продукта, это неправильно.