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

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

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

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

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

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

Конечно, вы можете (и должны) расспрашивать сотрудников службы поддержки клиентов о типичных запросах и о том, как они на них обычно отвечают (для чего, кстати, отлично подходит консьерж-тест, позволяющий быстро собрать нужные сведения). Однако довольно скоро вам придется решить непростую задачу автоматизации этого процесса. Чтобы очень быстро протестировать несколько возможных подходов к ее решению, нужно создать прототип «волшебник из страны Оз», который обеспечит вас простым интерфейсом на основе чата. За «ширмой» будете сидеть вы, продакт-менеджер, или другой член команды, который будет получать запросы и составлять на них ответы. Скоро вы начнете экспериментировать с ответами системы и, возможно, даже используете прототип на реальных данных для своего алгоритма.

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

При исследовании продукта мы пытаемся рассортировать хорошие и плохие идеи и одновременно решить поставленные перед нами бизнес-проблемы. Что в действительности это означает?

На этом этапе мы обдумываем четыре вопроса:

1. Будет ли пользователь или клиент использовать продукт, захочет ли он его купить? (Ценность.)

2. Сможет ли пользователь понять, как он работает? (Юзабилити.)

3. Сможем ли мы создать продукт с технической точки зрения? (Выполнимость.)

4. Способствует ли это решение жизнеспособности нашего бизнеса? (Бизнес-жизнеспособность.)

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

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

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

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

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