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

Еще пара интересных фактов о юной Netflix: на раннем этапе компания столкнулась с серьезной проблемой наличных средств, и тогда она предложила купить себя Blockbuster за 50 миллионов долларов, но та отказалась. Сегодня на Blockbuster никто не поставит и копейки, а Netflix стоит больше 40 миллиардов долларов.

Кейт сегодня работает лидером продукта в Нью-Йорке.

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

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

К счастью, в нашем распоряжении есть методики, весьма эффективно помогающие преодолеть все преграды.

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

Спринт на этапе исследования продукта — это недельный интервал в ходе исследования, в течение которого вам предстоит решить важную проблему или снизить риск, с которым в настоящий момент столкнулась команда. Безусловно, такой метод полезен не только для введения преобразований в командах и компаниях, его можно считать отличным инструментом планирования или прототипирования на этапе исследования. Но, по моему убеждению, полезнее всего объединить все эти способы применения, поэтому я и решил поговорить об этом здесь.

Некоторые специалисты используют термин дизайн-спринт, а не спринт-исследование, но, поскольку цель этой деятельности — при условии, что все сделано как надо, — выходит за рамки дизайна, я предпочитаю использовать обобщающий термин.

Если у вашей компании возникают трудности с использованием минимально жизнеспособного продукта (MVP), то спринт позволит вам начать извлекать ценность из этой важнейшей методики.

С командой Google Ventures (GV) я познакомился много лет назад, в самом начале ее деятельности. Команда входит в инвестиционное подразделение Google и снабжает деньгами стартапы, но гораздо больше она помогает им тем, что обучает правильно подходить к разработке продуктов. В рамках используемой в GV модели ее сотрудники обычно проводят в стартапе неделю: засучив рукава, они показывают своим подопечным, как нужно исследовать продукт, бок о бок с ними выполняя все необходимые действия. (Я знаком с несколькими надежными людьми из этой сферы, работающими индивидуально; они коучи по исследованию продукта и делают для команд то же самое.) За неделю такой интенсивной работы вы со своей командой изучите и проанализируете десятки различных идей и подходов, чтобы решить ту или иную бизнес-задачу. Заканчивается неделя проверкой потенциального решения на реальных пользователях и клиентах. И, как показывает мой опыт, результатом неизменно становится последовательное и очень важное обучение и более глубокое понимание дела; эти знания могут в корне изменить дальнейший курс развития продукта и даже всей компании.

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

Поработав с более чем сотней продуктовых команд и на практике отточив свои методы и определив эффективнейшие из них, команда GV решила поделиться этими знаниями в книге Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days [15]. Ее авторы Джейк Кнапп, Джон Зерацки и Браден Ковиц.

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

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

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

По мере перехода команд к использованию agile-методов (обычно они начинают с управления проектами Scrum) многие компании решили подписать контракт или нанять agile-коуча. Эти специалисты помогают командам — особенно инженерам-программистам, контролерам качества, продакт-менеджерам и дизайнерам продукта — обучаться методам и образу мышления, без которых применение agile-методологии невозможно.

К сожалению, такое обучение порождает множество проблем, поскольку большинство этих agile-коучей не имеют опыта работы с компаниями по выпуску технологичных продуктов — их опыт ограничивается поставкой продукта на рынок. Следовательно, было бы правильнее называть их agile-коучами по поставке. Они отлично разбираются в инженерно-техническом аспекте разработки новых продуктов и релизах, но не в исследовании продукта.