Сколько можно работать над одним продуктом

Михаил Калашников, директор по продуктам Sports.ru и мобильного издательства Tribuna Digital, в свое блоге Media Skunk объясняет необходимость менять менеджеров и команды, работающие над проектом.

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

Поэтому предельный срок эффективной работы менеджера над одним продуктом — полтора-два года. Понять, как все устроено, можно за один-три месяца, после этого около года успешной работы и еще месяц постепенной передачи дел. Для более простых продуктов цикл может быть еще меньше. Например, мобильными приложениями Sports.ru о клубах и турнирах (мы их называем “эталонами”) с февраля будет заниматься уже пятый человек за пять лет.

Простое следствие: запускать и развивать продукт должны разные люди.

Как это можно устроить

1. Самый естественный способ: рост команд.  Так работает в успешных стартапах: гендиректор в какой-то момент нанимает продакт-менеджера, тот затем превращается в директора по продуктам, нанимая новых людей. Появляются сайд-проекты, проект делится на части (например, на внутреннюю и внешнюю), кто-то увольняется, все постоянно в движении. У бурно растущих проектов команда может трижды полностью смениться за пять лет, здесь никакие особенные приемы не нужны.
2. Есть отдельная команда запуска проектов, которая с какого-то момента передает то, что они запустили, в эксплуатацию другими командами. Нормально для больших компаний, где есть отдельное подразделение R&D.
3. Ротация команд. Заранее известен момент, когда одна команда отстраняется от продукта и вместо нее работает другая. Возможно, меняется только менеджер, а не команда целиком. Это распространенная практика в самых разных отраслях: от региональных продажников до школьных учителей и военных. Тоже встречается в некоторых больших компаниях, хотя имеет смысл уже тогда, когда у вас становится хотя бы 4-5 продуктов. Дальше я говорю в основном об этом варианте.

Почему это сложно

1. Люди привыкают к хорошему и своему. Особенно команда, запускавшая новую штуку, которая оказалась успешной. Ощущения могут варьироваться от дискомфорта (что в данном случае полезно, нельзя слишком любить свой продукт и свой процесс) до острой несправедливости.
2. Кажется, что тратится неоправданно много ресурсов на изменения и передачу информации. Это отчасти правда, но без изменений у вас накапливается “информационный долг”: знания о том, как все работает, которые есть только у кого-то в голове. Это тоже риск.
3. Кажется, что новые команды будут работать хуже и медленнее, чем опытные. Так, безусловно, бывает, но обычно новые команды работают хуже и быстрее.  Скоростью проверки гипотез часто можно компенсировать их качество.

Почему это важно

1. Внутренняя культура команд со временем усложняет процессы. Продукт обрастает временными решениями, появляются вещи, которые делаются так, потому что всегда делались, возникает болото задач, которые вроде бы нужны, но вроде бы и нет. Передача дел фиксирует ценное, устраняет лишнее и заставляет наконец записать всю нужную информацию. Если известно, что когда-то придется сдать проект вместе с документацией, это стимулирует составлять ее вовремя.
2. Человек отделяется от задачи: успех, провал и привлекательность продукта меньше ассоциируются с теми, кто над ними работал. Учитывая, что успех продукта зависит от продакт-менеджера не так уж и сильно (посмотрите пункт 24 в известном тексте Олега Якубенкова), не говоря уже о других членах команды, это выглядит справедливым.
3. Понятнее перспективы. Больше возможностей управлять счастьем людей и команд. Чтобы эффективно начать работать над продуктами конкретной компании, нужно много времени даже людям с большим потенциалом.
4. Если конец цикла известен заранее, у продукта возникает дедлайн и ощущение срочности. Когда знаешь, что на все новое и хорошее осталось всего полгода, начинаешь выбирать то, что имеет значение и что реально сделать за оставшееся время.
5. Вместо передачи проекта новой команде его можно просто закрыть. Закрывать продукты тяжело даже тогда, когда знаешь, что это нужно. Принимать такие решения проще в том случае, когда альтернатива — тратить на проект еще год чьей-то жизни.