Вдохновленные. Все, что нужно знать продакт-менеджеру

• Хорошие команды понимают, кто основные заинтересованные стороны в их продукте; им известны ограничения, в условиях которых работают эти люди, и нацелены на поиск решений, не только полезных для пользователей и клиентов, но и эффективно работающих в рамках бизнес-ограничений. Плохие команды просто принимают требования заинтересованных сторон.

• Хорошие команды мастерски владеют различными методиками быстрого тестирования идей и определяют, какие из них стоит воплотить в жизнь. Плохие команды проводят собрания, составляя на них дорожные карты.

• Хорошие команды любят проводить «мозговые штурмы» с участием авторитетных экспертов из разных подразделений компании. Плохие команды обижаются, когда «чужаки» лезут не в свое дело.

• В хороших командах продакт-менеджер, дизайнер и инженер-программист трудятся плечом к плечу, в полной мере осознавая необходимость компромисса между функциональностью, пользовательским опытом и технологией реализации. В плохих командах люди сидят в своих «отсеках» и требуют, чтобы другие делали запросы на их услуги в соответствующей форме с четким соблюдением графика.

• Хорошие команды постоянно тестируют новые идеи, чтобы не перестать быть новаторами, но делают это так, чтобы доход и бренд компании были защищены. Плохие команды ждут сверху разрешения на каждый тест.

• Хорошие команды настаивают на том, что у них должны быть все специалисты, необходимые для создания хитов, например сильный дизайнер продукта. В плохой команде о таких специалистах даже не слышали.

• В хороших командах инженеры-программисты ежедневно тестируют прототипы на этапе исследования и благодаря этому находят новые способы улучшения продукта. Плохие команды дают на оценку прототипы технарям только на этапе планирования спринта.

• Хорошие команды каждую неделю взаимодействуют с конечными пользователями и клиентами, чтобы лучше понимать их запросы и проблемы и видеть их реакцию на самые новые идеи. Плохие команды думают, что они и есть потребители.

• Хорошие команды знают, что многие из их любимых идей не понравятся потребителям, а даже если люди их примут, понадобится нескольких итераций, чтобы достичь желаемого конечного результата. Плохие команды просто создают продукт из дорожной карты, довольствуясь при этом тем, что соблюдают установленные сроки и обеспечивают нужное качество на отдельных этапах разработки.

• Хорошие команды понимают необходимость скорости и знают, что быстрые итерации — это ключ к инновациям; по их мнению, эта скорость произрастает на почве использования правильных методик, а не принудительного труда. Плохие команды объясняют низкую скорость работы недостаточным усердием коллег.

• Хорошие команды берут на себя обязательства с высокими требованиями только после того, как всесторонне оценят запрос и убедятся, что у них есть жизнеспособное решение, выгодное и полезное как для потребителя, так и для бизнеса. Плохие команды жалуются на то, что в их компании всем заправляет отдел продаж.

• Хорошие команды применяют инструменты, позволяющие немедленно оценивать, как используется их продукт, и на основании этих данных оперативно вносить коррективы. Плохие команды считают, что иметь возможность просматривать аналитику и отчеты неплохо, но в этом нет особой необходимости.

• Хорошие команды вводят новые функции в продукт и выпускают релизы постоянно, зная, что непрерывный поток небольших релизов обеспечивает клиентов более надежным решением. Плохие команды тестируют продукт вручную в самом конце болезненного этапа интеграции, а затем одним махом делают релиз.

• Хорошие команды ставят во главу угла референcных клиентов. Плохие команды одержимы борьбой с конкурентами.

• Хорошие команды празднуют то, что им удается значительно улучшить бизнес-результаты своей компании. Плохие команды празднуют то, что им удается выпустить хоть какой-нибудь продукт.

Если многое из характеристик плохих компаний имеет отношение к вам, я очень надеюсь, что вы как можно скорее поднимете планку для своей команды. Подумайте об использовании методик, описанных в книге, чтобы, так сказать, почувствовать разницу.

Глава 65. Причины проблем с инновациями

Я определяю последовательные инновации как способность команды постоянно повышать ценность своего бизнеса. В результате роста многие организации теряют способность к инновациям, что, конечно же, не может не расстраивать руководство и членов продуктовых команд. Чаще всего по этой причине люди уходят из крупных компаний в стартапы.

Тем не менее потерю способности крупных и устоявшихся компаний к инновациям не стоит считать неизбежным злом. Наиболее последовательные новаторы в нашей отрасли очень велики: взять хотя бы Amazon, Google, Facebook и Netflix.

На мой взгляд, компаниям, которые перестали заниматься инновациями вследствие увеличения масштаба, не хватает одной или нескольких из перечисленных ниже черт.