Михаил Калашников, директор по продуктам Sports.ru и мобильного издательства Tribuna Digital, в свое блоге Media Skunk объясняет необходимость менять менеджеров и команды, работающие над проектом.
В некоторых профессиях невозможно долго и эффективно работать над одной и той же задачей. Если задача полностью помещается у вас в голове — пожалуйста, пишите роман, компьютерную игру или язык программирования столько лет, сколько вам это интересно. Диджитал-продукты для массовой аудитории существуют в меняющейся среде, которая не поддается полному моделированию (почти всегда вы на самом деле не понимаете и не представляете своих пользователей, сколько бы не старались). Как только вы построили себе ментальную модель, вы начинаете что-то упускать или делать что-то, что нужно только вам.
Поэтому предельный срок эффективной работы менеджера над одним продуктом — полтора-два года. Понять, как все устроено, можно за один-три месяца, после этого около года успешной работы и еще месяц постепенной передачи дел. Для более простых продуктов цикл может быть еще меньше. Например, мобильными приложениями Sports.ru о клубах и турнирах (мы их называем “эталонами”) с февраля будет заниматься уже пятый человек за пять лет.
Простое следствие: запускать и развивать продукт должны разные люди.
Как это можно устроить
- Самый естественный способ: рост команд. Так работает в успешных стартапах: гендиректор в какой-то момент нанимает продакт-менеджера, тот затем превращается в директора по продуктам, нанимая новых людей. Появляются сайд-проекты, проект делится на части (например, на внутреннюю и внешнюю), кто-то увольняется, все постоянно в движении. У бурно растущих проектов команда может трижды полностью смениться за пять лет, здесь никакие особенные приемы не нужны.
- Есть отдельная команда запуска проектов, которая с какого-то момента передает то, что они запустили, в эксплуатацию другими командами. Нормально для больших компаний, где есть отдельное подразделение R&D.
- Ротация команд. Заранее известен момент, когда одна команда отстраняется от продукта и вместо нее работает другая. Возможно, меняется только менеджер, а не команда целиком. Это распространенная практика в самых разных отраслях: от региональных продажников до школьных учителей и военных. Тоже встречается в некоторых больших компаниях, хотя имеет смысл уже тогда, когда у вас становится хотя бы 4-5 продуктов. Дальше я говорю в основном об этом варианте.
Почему это сложно
- Люди привыкают к хорошему и своему. Особенно команда, запускавшая новую штуку, которая оказалась успешной. Ощущения могут варьироваться от дискомфорта (что в данном случае полезно, нельзя слишком любить свой продукт и свой процесс) до острой несправедливости.
- Кажется, что тратится неоправданно много ресурсов на изменения и передачу информации. Это отчасти правда, но без изменений у вас накапливается “информационный долг”: знания о том, как все работает, которые есть только у кого-то в голове. Это тоже риск.
- Кажется, что новые команды будут работать хуже и медленнее, чем опытные. Так, безусловно, бывает, но обычно новые команды работают хуже и быстрее. Скоростью проверки гипотез часто можно компенсировать их качество.
Почему это важно
- Внутренняя культура команд со временем усложняет процессы. Продукт обрастает временными решениями, появляются вещи, которые делаются так, потому что всегда делались, возникает болото задач, которые вроде бы нужны, но вроде бы и нет. Передача дел фиксирует ценное, устраняет лишнее и заставляет наконец записать всю нужную информацию. Если известно, что когда-то придется сдать проект вместе с документацией, это стимулирует составлять ее вовремя.
- Человек отделяется от задачи: успех, провал и привлекательность продукта меньше ассоциируются с теми, кто над ними работал. Учитывая, что успех продукта зависит от продакт-менеджера не так уж и сильно (посмотрите пункт 24 в известном тексте Олега Якубенкова), не говоря уже о других членах команды, это выглядит справедливым.
- Понятнее перспективы. Больше возможностей управлять счастьем людей и команд. Чтобы эффективно начать работать над продуктами конкретной компании, нужно много времени даже людям с большим потенциалом.
- Если конец цикла известен заранее, у продукта возникает дедлайн и ощущение срочности. Когда знаешь, что на все новое и хорошее осталось всего полгода, начинаешь выбирать то, что имеет значение и что реально сделать за оставшееся время.
- Вместо передачи проекта новой команде его можно просто закрыть. Закрывать продукты тяжело даже тогда, когда знаешь, что это нужно. Принимать такие решения проще в том случае, когда альтернатива — тратить на проект еще год чьей-то жизни.