Предисловие
Это достаточно свободный перевод статьи Marty Cagan — The Seven Deadly Sins of Product Planning. Так как я и сам работаю в роли PM, я стараюсь делать более живой перевод таких статей, руководствуясь собственным опытом. Но если у вас есть какие-то замечания и\или предложения — то я всегда открыт для обратной связи в личных сообщениях или комментариях.
The Seven Deadly Sins of Product Planning
Планирование развития продукта — серьезная задача, с которой сталкиваются многие организации. Она охватывает различные активности, включая бизнес стратегию, продуктовую стратегию, дорожную карту (или roadmap) продукта, управление портфелем, оценку возможностей, планирование проектов и отслеживание статуса.
Если коротко, то планирование развития продукта — это решение в какие проекты вы будете вкладываться, а в какие нет.
Я работаю над серией статей, в которых расскажу о различных подходах к продуктовому планированию, но начать я хотел с самых распространенных источников проблем в продуктовых компаниях.
Неважно какой процесс планирования вы используете, любой из них включает в себя этап отделения хороших идей от плохих. В предыдущих статьях я уже рассказывал про Product Discovery и подчеркивал, как именно менеджер по продукту должен находить продукт, который является ценным, пригодным для использования и реализуемым. Нет смысла продолжать работу, пока у вас нет каких-либо доказательств того, что вы этого достигли.
Это означает, что проекты, которые не демонстрируют высокую вероятность успеха, должны быть закрыты, прежде чем они попадут к команде разработки.
В этой статье я хочу обсудить причины по которым проекты, которые должны быть давно закрыты, не закрываются и к чему приводит такое бездействие.
Вот семь самых главных причин, по которым организации не закрывают плохие проекты:
- Инерция — пожалуй основная причина, из-за которой не отменяются слабые проекты и не выбрасываются плохие идеи, просто потому что проще продолжать. Закрытие проекта подразумевает, что у вас есть контрольные точки и данные для принятия того или иного решения. Ни того, ни другого во множестве команд нет.
- Отрицание — многим людям тяжело слышать критику или работать с реальными клиентами, которым не нравится их идея. Поэтому они пытаются убедить себя, что для плохой реакции есть другие причины и как только они закончат разработку и запустят продукт по-настоящему все будет хорошо.
- Гордость — многие люди считают, что если ваш проект был закрыт, то вы потерпели неудачу, и, кроме того, неудача — это плохо. Я же пытаюсь объяснить этим людям, что гораздо бОльшая неудача состоит в том, чтобы продолжить проект, потратив время и деньги на его создание и запуск, только чтобы увидеть, как он потерпит неудачу на рынке. Конечно, возможно, что ваш проект был закрыт, потому что вы не были достаточно умны, чтобы найти хорошее решение. Но скорее всего, что идея не была такой уж хорошей, и клиенты просто не отреагировали на нее так, как вы надеялись. Закрытие проекта по этим причинам не является провалом в любом смысле этого слова.
- Отречение — многие лидеры, управляющие продуктом, думают, что их задача состоит в том, чтобы беспокоиться о шкафе у окна, а не брать на себя ответственность за продукт, который выпускает компания. Они просто отказываются от своей ответственности как менеджеры продукта, не принимая трудных решений.
- Культура — в некоторых корпоративных культурах считаются подлым закрытие слабых проектов. Особенно после тяжелой работы, которая была проделана. Но корпоративные культуры, которые действительно ценят своих людей, презирают мысль о том, чтобы тратить свой самый ценный ресурс, своих людей, на обреченные проекты. Вот наказывать или унижать людей, которые работали над закрытым проектом, действительно жестоко.
- Сроки (дедлайны) — я называю это проблемой «накорми зверя», инженеры освободятся на следующей неделе, и мы должны дать им срочно что-то для работы, давайте быстро напишем новые требования! Как бы нелепо это ни звучало, это очень распространенная проблема. Поэтому важно создать резерв полезных задач. Если у вас действительно есть свободная команда, а требования к проекту, на который вы надеялись, не готовы, то у вас будет другая не менее важная задача, которая готова к работе (примечание переводчика — или поработайте над техническим долгом).
- Гордость — давайте посмотрим правде в глаза, многие проекты — любимые идеи некоего руководителя, который лично убежден, что что-то необходимо. Это не столько отрицание, сколько высокомерие; они боссы, поэтому по определению они должны быть правы. Не поймите меня неправильно, многие отличные идеи о продукте приходят от очень умных руководителей, но у руководителей есть и плохие идеи, как и у всех остальных.
На мой взгляд поиск идей для продукта и инновации похожи на сельское хозяйство. Вы хотите посеять семена множества идей и вырастить их, но если при этом не удалять слабые,то они будут отбирать ресурсы у сильных идей.
Правда в том, что зачастую компании работают над множеством проектов одновременно, многие из которых не стоят того, и в результате они слишком распыляются, чтобы хорошо реализовать все идеи.
В конечном счете, именно руководители, начиная с руководителя продукта, несут ответственность за то, чтобы слабые идеи были убиты, а сильные могли быть реализованы.
Большинство людей видят потерянные время и деньги, которые тратятся на создание и реализацию плохих идей. Но они не понимают, что высокие затраты часто являются стоимостью альтернативной идеи, которую можно было бы реализовать вместо этой. У продуктовых команд есть много хороших идей, но у них есть немало и плохих, и они не знают разницы между ними до тех пор, пока не реализуют идею и не выпустят ее для пользователей.
Устранить эту проблему помогут продуктовые исследования, а работой команды руководителей станет обеспечение только сильных идей ценными ресурсами для создания, тестирования и выпуска.