Страница 10 из 21
Часть 3
Навыки работы с продуктом
Навыки работы с продуктом лежат в основе разработки высококачественного решения, которое будет радовать клиентов и отвечать их запросам. Этот раздел посвящен развитию навыков, благодаря которым вы сможете принимать более эффективные решения о продукте.
• Глава «Понимание потребностей пользователя» (с. 43) научит вас понимать, что действительно нужно людям и какие проблемы они хотят решить с помощью продукта. Вы узнаете, как собирать информацию от пользователей и вычленять из нее ключевые идеи. Наконец, мы рассмотрим различные варианты проведения пользовательских исследований.
• Из главы «Анализ данных» (с. 60) вы узнаете, как проводить обзор данных, анализировать их и использовать для принятия более эффективных решений. Мы расскажем о том, как работать с метриками компании, а также рассмотрим A/B-тестирование и способы работы со статистикой.
• Глава «Аналитический подход к решению задач» (с. 75) описывает главные принципы принятия эффективных решений. Мы разберем такую тему, как системное мышление, и изучим методы устранения сложных проблем.
• Информация, изложенная в главе «Продукт и навыки дизайна» (с. 90), будет полезна для развития продуктового мышления и способности влиять на решения о продукте. Вы узнаете о создании прототипов и мозговых штурмах, а также о том, как правильно расставлять приоритеты.
• Прочтя главу «Технические навыки» (с. 109), вы научитесь взаимодействовать с инженерами и лучше оценивать затраты на разработку. Здесь же дается экспресс-курс по технологиям – API, развертывание, SQL, алгоритмы и многое другое.
• Содержание главы «Документация по продукту» (с. 123) полностью соответствует ее названию. Из нее вы узнаете, какие методы составления и использования продуктовых спецификаций являются самыми эффективными.
Чаще всего навыки по работе с продуктом используются на ранних стадиях жизненного цикла продукта (с. 23), но могут понадобиться и на любом другом этапе проекта.
Глава 4
Понимание потребностей пользователя
Впервые попав в продуктовую команду, я прочла несколько обращений в службу поддержки и поговорила с несколькими клиентами по телефону. Однако большинство решений я принимала, не встречаясь с реальными пользователями. Вместо этого я изучала архетипы клиентов – небольшой набор вымышленных персонажей, представляющих собой разные виды пользователей нашего продукта. В 2004 году этот подход считался самым эффективным, хотя на деле я просто пыталась догадаться, чего хочет клиент.
Позднее я увидела, что мелкие ошибки в моих суждениях превратились в большие проблемы для клиентов.
Однажды я сократила время разработки, убрав функцию выбора пользовательских цветов. Я думала, что это не столь важно. Но когда я представила продукт заказчику, выяснилось, что он готов его использовать, только если палитра будет соответствовать цветам бренда. И чтобы решить эту проблему, мне пришлось перенастраивать серверы компании клиента под нужные цвета.
В другом, еще более неприятном случае выяснилось, что одну из функций, над которыми я усердно работала (настройка уведомлений для других пользователей), просто невозможно найти в программе. Люди жаловались, что эта опция отсутствует! Мы сделали свою работу, но она оказалась бессмысленной, потому что никто не увидел результат.
Эти неудачи определили мое дальнейшее становление как профессионала. Я поняла, что интуиция может подвести и что любое предположение нужно проверять. Мне казалось, что я хорошо понимала наших пользователей, но на самом деле это было не так.
Чувствовать, чего хотят клиенты, – основной навык, необходимый каждому PM. Вы должны развивать глубокое понимание и эмпатию, чтобы безошибочно определять возможности продукта и находить решения, отвечающие потребностям пользователей[18].
Обязанности
РАЗГОВАРИВАТЬ С ДЕЙСТВУЮЩИМИ И ПОТЕНЦИАЛЬНЫМИ ПОЛЬЗОВАТЕЛЯМИ
Пользователи – это люди. Что мы делаем, чтобы узнать человека получше? Мы с ним разговариваем!
Начиная работу над новым продуктом, опросите хотя бы с пять-десять человек и увеличивайте это количество еще на пять-десять человек с каждым новым проектом. Если продукт предназначен для разных типов пользователей (например, авторы + читатели или пассажиры + водители), поговорите с пятью-десятью представителями каждого типа.
Живое общение, особенно при личной встрече, работает лучше, чем электронная почта и опросы, где нужно ждать ответа. Беседа с глазу на глаз, в отличие от обмена письмами и заполнения готовых форм, дает более глубокое понимание предмета. Вы получаете совершенно новую информацию, видите эмоции человека и можете задавать дополнительные вопросы. Изучение пользовательских исследований, проведенных вашей компанией, безусловно, важно, но не может заменить разговоров с людьми.
Ваша цель – досконально изучить пользователей и стать экспертом в этой области. Продакт-менеджмент – или, по крайней мере, эффективный продакт-менеджмент – это не школа, где вы решаете задачи с заранее известным ответом. Он требует от вас получения новых и уникальных знаний.
Разговаривая с людьми, сосредоточьтесь на своих выводах – как предсказуемых, так и неожиданных, – чтобы на их основе сформировать мысленное представление о пользователе. Пытайтесь угадать, что скажут люди, и фиксируйте, удалось вам это или нет. Со временем вы не только разовьете интуицию, но и научитесь понимать, когда на нее можно положиться, а когда она может сбить вас с верного пути.
Копайте глубже
Представьте, что ваша компания производит лазерные скальпели, и ваши клиенты – врачи – часто на них жалуются. Манипуляторы слишком тяжелые! С помощью лазера хирурги проводят сложные операции, и вес инструментов имеет большое значение.
Именно в такой ситуации оказалась компания Xanar и ее конкуренты. Последние в ответ на запрос пользователей решили применить более легкие металлы и другие материалы, что потребовало больших финансовых вложений. Но компания Xanar решила копнуть глубже. Врачи просили сделать манипулятор более легким, но настоящей проблемой была его маневренность.
В Xanar учли это и просто уравновесили манипулятор. Он не стал легче (на самом деле технически он был даже тяжелее), но зато его управляемость сильно возросла.
Как оказалось, люди не всегда знают, чего они хотят. Они чувствуют «боль» и превращают ее в конкретное решение. И отчасти ваша задача состоит в том, чтобы это решение трансформировать обратно, то есть выслушать запрос, а затем выявить лежащую в его основе проблему. Она-то и становится в итоге «jobs to be done» – «работой, которую нужно выполнить» (с. 49)[19].
Чем глубже PM вникает в проблему, тем ему проще понять клиента и направить команду в нужном направлении в поисках эффективного решения.
Чтобы тщательнее проработать тему, попробуйте задать пользователю такие вопросы:
• Расскажите, как вы собираетесь использовать запрашиваемую функцию. Что происходит перед ее применением? Что происходит после?
• Является ли это действие частью более масштабной задачи?
• С какими трудностями вы сталкиваетесь при выполнении этого действия?
• Пробовали ли вы раньше решить эту проблему? Что не сработало? Как вы решаете эту проблему сегодня?
• Если мы создадим продукт по вашему запросу, вы сразу же начнете его использовать или понадобится что-то еще?
• Вот как я понимаю вашу проблему: […]. Я ничего не упустил?
Запомните: мы должны прислушиваться к нашим клиентам, но это не значит, что они всегда предлагают правильные решения.
18
Некоторым не нравится термин «пользователь» из-за его обезличенности, но мы используем его в нашей книге, поскольку такие замены, как «клиенты», «читатели» или «участники», применимы не ко всем продуктам.
19
Речь идет о методе JTBD (jobs to be done), который позволяет выяснить, какие задачи ваш продукт будет решать для клиента. – Примеч. пер.