При исследовании продукта мы пытаемся рассортировать хорошие и плохие идеи и одновременно решить поставленные перед нами бизнес-проблемы. Что в действительности это означает?
На этом этапе мы обдумываем четыре вопроса:
1. Будет ли пользователь или клиент использовать продукт, захочет ли он его купить? (Ценность.)
2. Сможет ли пользователь понять, как он работает? (Юзабилити.)
3. Сможем ли мы создать продукт с технической точки зрения? (Выполнимость.)
4. Способствует ли это решение жизнеспособности нашего бизнеса? (Бизнес-жизнеспособность.)
Во многих случаях на большинство или даже на все эти вопросы ответить очень просто, и они не сопряжены со сколь-нибудь значимым риском. Ваша команда уверена в своих силах; она много раз делала это раньше, и мы смело переходим на этап поставки продукта на рынок. Большая работа на этапе исследования нужна в случае, когда ответы на эти вопросы неоднозначны.
Должен заметить, что порядок, в котором нужно отвечать на эти вопросы, не предписан, но многие команды следуют определенной логике. Первым делом мы обычно изучаем ценность идеи. Часто это самый сложный и главный вопрос, так как при отсутствии ценности все остальное не имеет значения. Нередко нам приходится решать проблему риска юзабилити до того, как потребитель сумеет распознать ценность нашего предложения. В любом случае мы анализируем юзабилити и ценность одновременно, с привлечением одних и тех же пользователей и клиентов.
Как только становится ясно, что у нас есть разработка, которую потребители считают ценной, и она спроектирована так, что, по нашему мнению, пользователи смогут разобраться в принципах ее работы, приходит время проанализировать этот подход с инженерами, чтобы убедиться в осуществимости замысла с технической точки зрения. Если и тут результаты обнадеживают, мы показываем свою идею в компании всем, у кого могут возникнуть в связи с новым продуктом вопросы или сомнения: юристам, маркетологам, продавцам, СЕО и прочим специалистам. Обычно эти бизнес-риски оцениваются в последнюю очередь, ведь никому не хочется «расшевелить улей», пока он не уверен в том, что дело того стоит. Случается, идеи, дожившие до этого момента, совсем не похожи на те, с которых вы начинали, а нередко были предложены одной из упомянутых выше заинтересованных сторон. Так что гораздо лучше представить им какие-либо подтверждения того, что в их идее потребителям не все понравилось, и объяснить все внесенные изменения.
Глава 50. Тестирование юзабилити
Тестирование юзабилити, как правило, наиболее продуманная и понятная форма тестирования на этапе исследования продукта, используемая уже много лет. Конечно, сегодня инструменты стали намного эффективнее, и команды проводят такие тесты гораздо чаще, чем раньше, но и в целом это не самый сложный вид деятельности. Главное отличие от тестирования юзабилити в прошлом — его проведение на этапе исследования — с использованием прототипов, а не готовых продуктов — а не в конце процесса, когда исправления и коррекции сопряжены со значительными непродуктивными тратами, а то и с чем-то похуже.
Если ваша компания достаточно велика и в ней есть собственная группа исследователей пользователей, во что бы то ни стало добейтесь, чтобы эти люди как можно больше времени работали на вашу команду. Даже если этого времени будет не очень много, такие специалисты обычно представляют собой потрясающий ресурс для менеджера продукта; и если вы сможете подружиться с кем-то из них, то получите отличное подспорье.
Если компания располагает средствами для привлечения сторонних сервисов, можно воспользоваться для тестирования своих идей и продуктов услугами одной из множества фирм, специализирующихся на исследовании пользователей. Однако из-за цены, взимаемой большинством из них, скорее всего, вы не сможете себе позволить такой подход к тестированию юзабилити в нужном объеме. Дело в том, что если вы похожи на большинство компаний, то у вас не слишком много ресурсов и еще меньше денег. Но это ни в коем случае не должно помешать вам работать в этом важнейшем направлении.
А теперь я расскажу, как проводить тестирование юзабилити идеи или нового продукта самостоятельно. Нет, это не позволит вам достичь эффективности специально обученного и подготовленного исследователя, по крайней мере поначалу, и, скорее всего, понадобится провести не одну серию тестов, чтобы в нем поднатореть, но в большинстве случаев вы сможете практически с самого начала самостоятельно выявлять самые серьезные проблемные области продукта, а это, безусловно, очень и очень важно.
В отличных книгах подробно описывается, как проводить неофициальное тестирование юзабилити, но я не стану пересказывать их содержание, а обращу ваше внимание на ряд наиболее существенных моментов.
Прежде всего нужно собрать группу объектов исследования. Если у вас есть особая команда исследователей пользователей, то подбирать людей и планировать тесты будут они; и это огромное подспорье. Но если вам приходится делать все самим, в вашем распоряжении есть несколько вариантов:
• Если в компании реализуется программа определения потребителей, которую я подробно описывал ранее, вы всегда готовы к этой задаче — по крайней мере когда работаете над продуктом для корпоративных клиентов. Если же вы создаете потребительский продукт, придется дополнить имеющуюся группу.
• Для привлечения участников к тестированию можно разместить приглашение на сайте электронных объявлений или осуществить поиск в сети с использованием сервиса Google Ads — что особенно правильно в случае, если вы ищете пользователей, которые в настоящий момент пробуют продукт, похожий на ваш.
• Если у вас есть список адресов электронной почты ваших пользователей, можете отобрать участников из него. А продуктовый маркетолог поможет вам сократить выборку.
• Можно привлекать волонтеров на сайте своей компании — сегодня многие крупные организации с удовольствием участвуют в тестированиях. Однако волонтеров всегда нужно проверять, чтобы все отобранные люди относились к вашему целевому рынку.
• Вы всегда можете пойти в места, где собираются ваши пользователи: торговые выставки софта для бизнес-клиентов, маркетплейсы, спорт-бары для любителей фэнтези-спорта и другие. Если продукт предназначен для удовлетворения какой-нибудь реальной потребности, у вас не будет недостатка в тех, кто согласится потратить на вас час или два. И кстати, захватите с собой символические подарки, чтобы раздать их в знак благодарности за внимание.
• Если вы просите пользователей прийти для участия в тестировании к вам, скорее всего, нужно будет им чем-то компенсировать это одолжение. Мы обыкновенно организуем встречи с участниками тестов там, где удобно всем, например в кафе Starbucks. Такая практика стала настолько широко распространенной, что у нее даже появилось название — starbucks-тестирование.
Юзабилити-тестирование обычно проводится с применением пользовательского прототипа высокой детализации. Собрать полезные сведения о юзабилити можно и с помощью пользовательского прототипа средней детализации, но для изучения ценности, которое обычно проводится сразу после этого теста, все равно понадобится более реалистичный продукт (о причинах этого я расскажу чуть позже).
В большинстве случаев в тестировании юзабилити и (или) ценности участвуют продакт, дизайнер продукта и один из инженеров-программистов команды (из тех, кому нравится посещать такие мероприятия). Я стараюсь привлекать наших разработчиков по очереди. Как я уже упоминал, в присутствии инженера-программиста нередко возникает некое волшебство, поэтому я стараюсь по возможности всегда привлекать таких специалистов. Если в тестировании вам помогает сторонняя компания по исследованию пользователей, управляет тестом обычно она, но ваши продакт-менеджер и дизайнер обязательно должны присутствовать на каждом тесте.
Следует заранее определить набор задач для тестирования. Обычно тут все просто. Если вы разрабатываете, скажем, приложение для будильника на мобильном устройстве, то пользователям придется устанавливать будильник, находить и нажимать кнопку повтора и так далее. Встречаются и менее очевидные задачи, но при тестировании юзабилити нужно сосредоточиться на основных, то есть на тех, которые будут выполняться чаще всего.
Некоторые до сих пор считают, что продакт-менеджер и дизайнер продукта слишком к нему привязаны, поэтому не способны объективно провести тестирование юзабилити; что полученный результат может глубоко ранить их чувства; что они будут слышать только то, что хотят услышать. Такое препятствие устраняется двумя способами: во-первых, путем обучения продакт-менеджеров и дизайнеров поведению в ходе тестирования; во-вторых, как можно более ранним и быстрым проведением тестов, прежде чем создатели продукта влюбятся в свои детища. Хороший продакт знает, что поначалу любой продукт «неправильный», ведь никто не способен сделать все правильно с первого раза. И ему известно, что знания, полученные благодаря этим тестам, — самый скорый и верный путь к успеху в разработке.
Следите за тем, чтобы юзабилити-тест проводил один человек, а записи вел другой. Очень полезно потом все обсудить и убедиться, что оба видели одно и то же и пришли к одинаковым выводам, для этого и нужен второй участник с вашей стороны.
В формальных средах для проведения тестирования обычно организуются помещения с двусторонними зеркалами или специальные видеомониторы с камерами, которые показывают и экран, и лицо пользователя. Прекрасно — иметь такое оборудование, но я даже не могу сосчитать, сколько прототипов мы протестировали за крошечным столиком в Starbucks — таким крошечным, что больше трех-четырех стульев за ним не помещалось. Во многих отношениях кафе даже предпочтительнее отлично оборудованной лаборатории: в неформальной обстановке пользователь не чувствует себя подопытным кроликом.
Еще одна превосходная среда для тестирования — офис потребителя. На реализацию такого подхода может уйти много времени, но даже полчаса, проведенные «в среде обитания» пользователя, расскажут вам о нем очень много полезного. Здесь ваши потребители хозяева, поэтому они намного разговорчивее. В офисе всегда найдется множество подсказок, как еще можно использовать тестируемый продукт. Многое можно узнать при виде офисной обстановки. Насколько большие мониторы? Как быстро работает компьютер и подключение к сети? Как люди общаются с коллегами при решении рабочих задач?
Сегодня в нашем распоряжении имеются инструменты для проведения данного типа тестирования удаленно, и я приветствую это двумя руками. Однако не забывайте, что они предназначены для тестирования юзабилити, а не ценности; вторые тесты обычно проводятся сразу после первых. Иными словами, я рассматриваю удаленное тестирование юзабилити как дополнение, а не замену обычному.
Итак, прототип готов, участники тестирования отобраны, задачи и вопросы сформулированы, теперь воспользуйтесь приведенными ниже советами и методиками для проведения теста.
Первым делом узнайте, что потребители думают о проблеме в настоящий момент. Вы же, конечно, помните, какие ключевые вопросы задаются в рамках методики «Интервью с клиентом»; нам нужно узнать, действительно ли пользователь или клиент столкнулся с той проблемой, которую мы выделили, как он решает ее сегодня и что нужно для того, чтобы убедить его использовать наш продукт.
В начале теста юзабилити обязательно сообщите участникам, что это всего лишь прототип, сырая идея, а не настоящий продукт, и объясните, что они не обидят вас откровенным как позитивным, так и негативным отзывом. Вы тестируете на прототипе идеи, а не пользователей, и они не могут пройти или провалить тест — это грозит только вашему прототипу.
Прежде чем приступить к выполнению своих задач, посмотрите, могут ли пользователи по начальной (посадочной) странице прототипа определить, что вы, собственно, пытаетесь сделать, и особенно то, что, с их точки зрения, может быть ценным или привлекательным. Как только люди приступят к выполнению задания, контекст посетителя-новичка исчезнет, так что не упускайте такую отличную возможность. Увидите: для преодоления разрыва между ожиданиями пользователя и тем, что продукт предлагает ему на самом деле, невероятно важны начальные (посадочные) страницы.
В ходе тестирования нужно делать все от вас зависящее, чтобы удерживать участников в режиме использования и не давать им перейти к критике. Важно определить, могут ли пользователи, применяя ваш прототип, легко выполнять необходимые им задачи, а не то, считают ли они тот или иной элемент страницы недостаточно привлекательным или что, по их мнению, на ней нужно что-то переместить или изменить. Иногда люди, не слишком поднаторевшие в тестировании, задают пользователям неправильные вопросы: «Какие три элемента на странице вы изменили бы?» Меня подобные вещи не очень интересуют — разве что если этот человек по стечению обстоятельств еще и дизайнер продукта. Если бы пользователи знали, чего они на самом деле хотят, создавать программное обеспечение было бы намного проще. Так что обращайте внимание на то, что они делают, а не на то, что говорят.
Для успешного тестирования очень важно сохранять олимпийское спокойствие. Видя, что у человека что-то не получается, у большинства из нас возникает естественное желание прийти на помощь. Вы должны всеми силами подавлять его в себе. Ваша задача — превратиться в нелюдима, не готового поддерживать приятную беседу. Станьте максимально молчаливым; тишина — лучший помощник тестировщика.
В ходе тестирования стоит ожидать развития событий по трем основным сценариям: 1) пользователь справился с задачей без малейших проблем и посторонней помощи; 2) пользователь немного помучился и поворчал, но выполнил нужную задачу; 3) он так измучился и расстроился, что в конце концов сдался, но так и не сделал того, что хотел. Конечно, иногда люди сдаются очень быстро, и вам, возможно, придется уговаривать их продолжить попытки. Но если дело доходит до момента, когда, судя по поведению пользователя, он точно откажется от вашего продукта и перейдет к конкуренту, можно сделать пометку, что пользователь сдался.
Тестировщику нужно стараться не помогать и не задавать участнику тестирования наводящие вопросы. Но если вы видите, что пользователь в сотый раз прокручивает страницу вверх-вниз, явно что-то разыскивая, спросите его, что он ищет, так как эта информация может оказаться очень полезной. Некоторые тестировщики даже просят пользователей в ходе теста постоянно рассказывать, о чем они думают, но, по-моему, это настраивает людей на критику, а такое поведение для нас нежелательно.
Повторяйте за собеседником как попугай, так как это полезно во многих ситуациях и помогает не давать пользователю наводок. Если участник тестирования ничего не говорит, а у вас уже нет сил молчать, опишите ему, что он делает: «Я вижу, вы ищете этот список справа». Человек обязательно расскажет вам, что он пытается сделать, что хочет найти и все остальное. Если же он задаст прямой вопрос, вместо ответа-подсказки можно просто повторить его слова. Например, пользователь спрашивает: «А если кликнуть тут, будет новая запись?» — а вы отвечаете: «Вам интересно, нужно ли кликнуть здесь, чтобы получить новую запись?» Как правило, пользователи «покупаются» на такой прием, потому что люди обычно хотят ответить на заданный им вопрос: «Ну да, думаю, так и будет». А еще попугайничанье помогает избегать наводящих оценочных суждений. Если у вас возникло непреодолимое желание похвалить участника тестирования, лучше скажите: «Ну вот, вы создали новую запись». И наконец, по-попугайски повторяя ключевые моменты, вы помогаете коллеге, который ведет записи, оставляя ему на это больше времени.
Вы пытаетесь разобраться, как целевые пользователи подходят к осмыслению тестируемой проблемы, и выявить в своем прототипе слабые места, в которых модель, представленная данным софтом, не согласуется с ходом рассуждений и действий пользователя. В этом случае она нелогична. К счастью, заметив это на этапе тестирования, мы можем без особого труда все исправить, что нередко становится решающим фактором в успехе будущего продукта.
Вы также скоро обнаружите, что очень многое можно узнать по жестам и тону участников тестирования. Обычно бывает очевидно, нравятся или не нравятся людям ваши идеи. Если пользователям по душе то, с чем они столкнулись, они почти всегда просят вас им сообщить, как только продукт выйдет на рынок. А если ваше детище им очень понравилось, то постараются заполучить его и раньше.
Цель тестирования прототипа — как можно лучше понять своих пользователей и клиентов и, конечно же, выявить в прототипе слабые места, чтобы как можно раньше их устранить. Например, это могут быть проблемы со спецификациями, потоком, графическим дизайном или ментальной моделью работы продукта. Выявив их, сразу же исправьте.
Тест не должен быть одинаковым для всех участников тестирования прототипа. Такая установка базировалась бы на непонимании роли этого вида качественного тестирования. Проводя тест, мы не пытаемся что-либо доказать, а хотим быстро получить ценную информацию.
После каждого тестирования или каждой серии тестов кто-нибудь, обычно продакт-менеджер или дизайнер, составляет резюме полученных результатов и рассылает их по электронной почте членам продуктовой команды. Не нужно составлять эти отчеты долго, они не должны быть длинными. Их редко дочитывают до конца, и они устаревают раньше, чем люди их получат. Ведь к этому моменту прототип, как правило, уже ушел далеко вперед по сравнению с тем, каким был на момент проведения теста. Такие отчеты не стоят потраченных сил и времени.
Глава 51. Тестирование ценности
Потребители не обязаны покупать наши продукты, а пользователи — выбирать новую фичу, предложенную вами. Люди будут делать это лишь в случае, если увидят в них ценность. То же самое можно сказать и по-другому: то, что кто-то может использовать наш продукт, еще не означает, что он решит это сделать. Повторяйте себе этот тезис, когда пытаетесь убедить клиентов или пользователей переключиться на ваш новый продукт с того, которым они пользуются.
Очень многие компании и продуктовые команды думают, что им достаточно всего лишь предложить потребителю приблизительно тот же набор функций (обеспечить паритет функциональных возможностей), а потом недоумевают, почему их продукт не продается даже по цене ниже той, что люди платили до появления их детища на рынке.
Чтобы мотивировать потребителя раскошелиться на ваш продукт и пережить все сложности перехода со старого, привычного решения, он должен воспринимать ваше предложение как нечто значительно лучшее. Иными словами, я хотел донести до вас мысль, что хорошие продуктовые команды огромную часть времени уделяют созданию ценности. При наличии ценности можно улучшить и все остальное. В противном случае не имеет значения, насколько удобен, надежен и производителен наш продукт.
Ценность программного продукта состоит из нескольких составляющих, для каждой из которых применяются особые методики тестирования.
Иногда довольно трудно определить, есть ли спрос на то, что мы хотим создать. Возможно, нам под силу найти потрясающее решение проблемы, но волнует ли она потребителей? И если да, то в достаточной ли степени, чтобы они купили новый продукт и стали им пользоваться? Стоит отметить, что такой подход к тестированию спроса относится к продукту в целом, в том числе к отдельным функциям уже существующего продукта.
Нельзя просто предположить, что спрос на наше предложение есть, хотя нередко это действительно так. Ведь наши продукты выходят на уже существующий рынок, где спрос уже продемонстрирован, а часто даже и оценен. Настоящая трудность — это предложить решение, ценность которого будет очевидно выше всех его альтернатив.
Самый распространенный тип качественного тестирования ценности сосредоточен на отзывах. Нравится ли идея клиентам? Готовы ли они за нее платить? Решат ли ее использовать? И главное, почему нет?
Нам нужно протестировать эффективность многих продуктов. Насколько успешно они решают проблему, ради избавления от которой создавались? Для одних типов продуктов такая оценка в высшей мере объективная, количественная. Например, мы можем измерить полученный благодаря рекламным технологиям доход и без особого труда сравнить его с тем же показателем других рекламных технологий. Но для других типов продуктов, например игр, такая оценка будет намного менее объективной.
Глава 52. Методики тестирования спроса
К непродуктивным тратам сил и времени относятся случаи, когда команда разрабатывает и создает продукт (тестирует юзабилити, надежность, производительность; делает все, что, по ее мнению, нужно сделать), а после его выхода на рынок обнаруживает, что люди его не покупают. По этой причине стартапы часто терпят крах. Хуже всего не те случаи, когда пользователи, массово подписавшись на пробную версию, потом вдруг решают не покупать продукт. Тут-то еще все можно исправить. Но ведь иногда они не хотят даже подписываться на пробную версию. И вот это действительно огромная, часто роковая проблема.
Вы можете сколько угодно экспериментировать с ценообразованием, позиционированием и маркетингом, но в финале придете к выводу, что предложили решение такой проблемы, которая не так уж и беспокоит людей. Наихудшее в подобном развитии событий то, что, судя по моему опыту, его легко избежать.
Описанная проблема может возникнуть и на уровне продукта, скажем совершенно нового продукта стартапа, и на уровне отдельных опций. Удручающе часто встречается второй вариант. Каждый день пользователям предлагают новые функциональные возможности, которыми они не хотят пользоваться. А между тем предотвратить такую ситуацию просто.
Предположим, вы обдумываете новую функцию, например, потому, что один из крупных клиентов пожелал ее иметь, или вы видели такую у конкурента, или, скажем, она очень нравится вашему СЕО. Вы рассказываете о ней команде, и инженеры-программисты сразу же заявляют, что реализация этой идеи влетит вам в копеечку. Не так уж невозможно осуществить ваш замысел, но и не слишком легко. Достаточно трудно, чтобы вы не пожелали, потратив на это время, в итоге обнаружить, что ее никто не использует. И вы тестируете новую опцию.
Такой метод тестирования спроса называют тестом с поддельными дверями (Fake-door demand test). Мы помещаем кнопку или пункт меню в том месте пользовательского интерфейса, где, по нашему мнению, они должны быть. Но когда пользователь на нем кликает, то он, вместо того чтобы привести к новой опции, переводит его на специальную страницу, где человеку объясняют, что вы исследуете возможность добавления новой опции и очень хотели бы с ним это обсудить. На этой странице пользователю также предлагают стать волонтером в тестировании спроса — например, указав свой адрес электронной почты или номер телефона.
Нужно отметить, что этот подход будет эффективным только в том случае, если пользователь не увидит ни одного признака, который подскажет ему, что это тест, до тех пор пока не кликнет на кнопке или пункте меню. Преимущество этой методики состоит в том, что с ее помощью можно быстро собрать очень полезные данные, которые позволят сравнить рейтинг кликов по кнопке с нашими ожиданиями или другими функциями. И тогда мы можем еще раз связаться с потребителями и глубже разобраться в их запросах и ожиданиях.
То же самое применимо и ко всему продукту. Но в этом случае речь идет не о кнопке на странице — мы настраиваем посадочную страницу на «воронку» нового предложения. Этот метод называют тестом на спрос с использованием посадочной страницы. Новое предложение описывается точно так же, как если бы мы действительно запускали сервис. Однако когда пользователь кликает на кнопке призыва к действию, вместо того чтобы подписаться на пробную версию (или другое действие), он видит страницу, где ему объясняют, что вы изучаете возможность добавления нового предложения и в случае его согласия хотели бы поговорить с ним об этом.
При использовании обоих описанных методов тестирования спроса мы можем показать свой тест либо каждому пользователю (если мы стартап), либо очень маленькому их проценту, либо только тем, кто относится к определенному географическому сегменту (если речь идет о крупной компании).
Надеюсь, вы очень скоро сами убедитесь в несложности этого метода. Благодаря ему можно быстро приобрести сразу два серьезных преимущества: заполучить надежное подтверждение спроса на ваше предложение и составить список пользователей, которые готовы и желают говорить с вами о новой функциональной возможности.
На практике получить спрос обычно несложно. Люди охотно подписываются на пробные версии продуктов. Трудности начинаются тогда, когда они пробуют продукт и он не производит на них впечатления — достаточно сильного, чтобы отказаться от продукта, которым они пользуются сейчас. Справиться с этим помогают качественные и количественные методики, описанные в следующих главах.
О том, как проводить исследование продукта в стартапах, написано много — и мной, и другими авторами. Перед стартапами стоит множество трудных задач, но главная и первоочередная — это выживание.
У стартапов есть преимущество: не приходится тащить за собой груз предыдущих, устаревших версий; у них еще нет дохода, который нужно сохранить, и хорошей репутации, которую необходимо поддерживать. Благодаря этому они идут вперед очень быстро и соглашаются на значительные риски без особых негативных последствий.
Как только ваш продукт развивается до такой степени, что на его продаже можно построить жизнеспособный бизнес (примите мои поздравления!), вам есть что терять. И совсем неудивительно, что теперь придется кое-что изменить в динамике исследования продукта. Я хочу обратить ваше внимание на эти различия и описать, как меняются методики стартапа, когда он вырастает до масштабов крупной корпорации. О применении этих методик в корпорациях писали и другие авторы, но, признаться, их советы не произвели на меня особого впечатления. Чаще всего предлагается сколотить защищенную от рисков команду; обеспечить ее, образно говоря, прикрытием с воздуха, чтобы ее члены могли заниматься инновациями, не опасаясь последствий. Но что при этом подумают сотрудники, которые не входят в состав этих особенных команд? А что будут думать о нынешних продуктах компании? Даже если какая-то идея новаторов кажется весьма перспективной, насколько позитивно, по-вашему, существующие продуктовые команды воспримут эти новые знания? Тут я перечислил лишь несколько из целого ряда причин, по которым я не могу быть сторонником так называемых корпоративных инновационных лабораторий.
Уже не первый год я настаиваю на том, что многие методики исследования продукта и быстрого тестирования и обучения в полной мере применимы в крупных, устоявшихся компаниях, а не только в стартапах. Все лучшие продуктовые компании, такие как Apple, Amazon, Google, Facebook, Netflix, давно и надежно используют этот подход к инновациям. В этих компаниях инновациями разрешено заниматься не только горстке избранных. Это долг и ответственность всех продуктовых команд, которые там работают.
Прежде чем двигаться дальше, хочу еще раз обратить ваше внимание на важнейшее предостережение для технологических компаний: перестанешь внедрять инновации — умрешь! Может быть, это случится не сразу, но если вы только оптимизируете старые решения, полностью отказываясь от инноваций, смерть лишь вопрос времени. Рано или поздно вы непременно станете чьим-нибудь обедом.
На мой взгляд, это не подлежит обсуждению; мы просто обязаны постоянно развивать и улучшать свои продукты, повышая их ценность для потребителей. Но подходить к этому нужно ответственно, а значит, делать две важные вещи: защищать от рисков свой доход и бренд и защищать своих сотрудников и клиентов.
Защищай свой доход и бренд
После того как компания создает себе репутацию и начинает получать доход, работа ее продуктовых команд состоит в проведении исследования продукта таким образом, чтобы защищать репутацию и прибыль от всех возможных рисков. Сегодня в нашем распоряжении есть больше способов, чем раньше, в том числе отличные методики для создания недорогих прототипов с очень низким уровнем риска, которые позволяют проверять, что работает, а что нет, с минимальными инвестициями и ограниченным приобщением к этому участников тестирования. Вот почему мы все просто обожаем прототипы на реальных данных и тестирование А/В.
Конечно, не все подходы рискованны для бренда или дохода, но в таком случае мы должны использовать методики, позволяющие снизить риск. Для этого отлично подходит A/B-тест с участием одного (или меньше) процента клиентов.
Однако иногда приходится быть более консервативными. Тогда проводится тестирование на реальных данных только по приглашению или используется программа определения новых потребителей, в рамках которой к тестированию привлекают лишь пользователей, подписавших соглашение о неразглашении. Есть множество других методик для тестирования в том же духе, которые позволяют компаниям приобретать нужные знания продуманно и ответственно.
Защищай своих сотрудников и потребителей
Помимо защиты доходов и бренда нам также необходимо защищать своих сотрудников и потребителей. Если служба поддержки клиентов, службы профессиональных услуг или торговый персонал вечно пребывают в шоке от калейдоскопа изменений, людям очень трудно выполнять свою работу и заботиться о потребителях качественно и достойно.
Потребители тоже не слишком долго будут оставаться счастливыми, если ваш продукт, по их восприятию, сильно напоминает постоянно движущуюся цель, и у людей создается впечатление, что для того чтобы им пользоваться, нужно постоянно переучиваться.
Вот почему мы используем «мягкие» методы развертывания, в том числе постоянно оцениваем воздействие изменений на потребителя. Может, это выглядит нелогично, но непрерывное развертывание весьма действенная и щадящая методика, и при правильном ее применении в комбинации с оценкой влияния изменений на потребителя это очень мощный инструмент защиты.
Большинство экспериментов и изменений не доставляют никаких проблем, но наша обязанность — относиться к защите потребителей и сотрудников проактивно и оценивать, как скажутся на них те или иные изменения.
Не поймите меня неправильно. Я не утверждаю, что внедрять инновации в корпоративных компаниях легко и просто. Конечно же, это не так. Но не из-за того, что методики исследования продукта этому мешают. Если вы хотите планомерно предлагать потребителям все большую и большую ценность, они необходимы. У крупных корпоративных компаний, как правило, есть проблемы более общего характера, которые обычно и становятся препятствием для инноваций. Если вы работаете в такой компании, знайте: ради непрерывного улучшения продукта следует действовать агрессивно, не ограничиваясь несущественными оптимизациями. Но делать это необходимо так, чтобы защищать от возможных рисков бренд и доход и одновременно своих сотрудников и потребителей.
Глава 53. Качественные методики тестирования ценности
Количественное тестирование показывает, что происходит или, наоборот, не происходит, но оно не способно рассказать, почему и что нужно сделать, чтобы исправить не устраивающее нас положение вещей. Поэтому мы проводим качественное тестирование. Если пользователи и клиенты реагируют на новый продукт не так, как мы ожидали, необходимо как можно детальнее выяснить, в чем дело.
Напомним, что качественное тестирование не относится к способам что-либо подтвердить или в чем-либо убедиться. Для этого используется количественное тестирование. А качественное предназначено для быстрого обучения, приобретения нужных знаний и глубокого изучения ситуации.
Проводя такое тестирование с участием пользователей, вы не получите полного ответа от каждого участника, но каждый пользователь, на котором вы тестируете продукт, даст вам что-то вроде очередного кусочка пазла. И со временем вы соберете и увидите такую часть общей картины, что поймете свою ошибку.
Знаю, это весьма громкое заявление, тем не менее берусь утверждать, что качественное тестирование идей продукта на реальных пользователях и клиентах, по всей вероятности, важнейшая активность в рамках исследования продукта для вас и вашей продуктовой команды. Чрезвычайно важно проводить по крайней мере два-три качественных теста на ценность продукта каждую неделю. Делается это так.
Обычно пользовательский тест начинается с короткого интервью с пользователем, во время которого нам нужно постараться выяснить, действительно ли у него есть проблемы, которые мы предполагаем; узнать, как он решает их сейчас и что необходимо ему предложить, чтобы он согласился пользоваться нашим продуктом (см. главу 41).
Как уже говорилось, сегодня в нашем распоряжении имеется целый ряд хороших методов для качественного тестирования ценности, но все они требуют, чтобы пользователь понимал, что представляет собой ваш продукт и как он работает. По этой причине тестированию ценности продукта всегда должен предшествовать юзабилити-тест.
Во время тестирования юзабилити мы проверяем, может ли человек без особого труда разобраться, как пользоваться тем, что мы ему предлагаем. И что еще важнее, после юзабилити-теста человек должен знать, в чем смысл вашего продукта и как его предполагается использовать. Только тогда мы можем завести с ним разговор о ценности продукта либо ее отсутствии.
Таким образом, подготовка теста на ценность обязательно должна включать в себя подготовку юзабилити-теста. В предыдущей главе я описал, как это делается, а сейчас позволю себе еще раз отметить, что юзабилити-тест важно проводить перед тестированием ценности и проводить их нужно сразу же один за другим.
Если вы попытаетесь провести тестирование ценности, не предоставив пользователю или клиенту возможности узнать, как используется ваш продукт, тест будет больше напоминать фокус-группу, в которой люди обсуждают ваш продукт гипотетически, пытаясь представить себе, как он может работать. Для полной ясности добавлю: методика фокус-групп весьма полезна для понимания рынка, но не поможет нам провести исследование и определить, какой продукт нужно поставить на рынок (см. главу 33).
В этом тестировании должны участвовать как минимум менеджер и дизайнер продукта, но, как уже не раз говорилось, меня не перестает удивлять волшебство, возникающее тогда, когда вместе с вами за ходом тестирования наблюдает еще и инженер-программист. Поверьте, стоит приложить все усилия, чтобы привлечь к этим тестам технарей.
При тестировании юзабилити и ценности пользователь должен иметь возможность использовать один из прототипов, описанных в предыдущих главах. Для тестов на ценность обычно применяются пользовательские прототипы высокой детализации, следовательно, прототип выглядит очень реалистично и воспринимается таким. Как показывает опыт, это чрезвычайно важно для эффективного тестирования ценности. Можно также использовать прототипы на реальных данных или смешанные прототипы.
При тестировании ценности, когда вы сидите лицом к лицу с реальными пользователями и клиентами, возникает такая сложность: поскольку люди в целом любезны и вежливы, им не хочется говорить вам в глаза, что они действительно думают о вашем предложении. Поэтому все тесты на ценность разработаны так, чтобы мы были уверены в том, что пользователь не просто пытался быть с нами милым и добрым.
ДЕНЬГИ КАК СПОСОБ ДЕМОНСТРАЦИИ ЦЕННОСТИ
Один из моих любимых подходов к измерению ценности — это проверка того, готов ли пользователь заплатить за ваш продукт, даже если вы не собираетесь взимать с него плату. Мы ищем человека, готового немедленно вытащить кредитку и попросить нас продать ему наш замечательный новый продукт (на самом деле данные его карты нам не нужны).
Если речь идет о дорогостоящем продукте для корпоративных клиентов, стоимость которого не вписывается в сумму, имеющуюся обычно на потребительской кредитной карте, можно спросить людей, готовы ли они подписать «неформальное намерение» сделать покупку; согласие говорит о том, что собеседники настроены серьезно.
РЕПУТАЦИЯ КАК СПОСОБ ДЕМОНСТРАЦИИ ЦЕННОСТИ
Пользователи могут «заплатить» за продукт и другими способами, скажем собственной репутацией. Для этого вам нужно спросить, насколько велика вероятность, что они порекомендуют его своим друзьям, коллегам или начальству (обычно по шкале от 0 до 10). Можно также попросить их поделиться информацией о нем в социальных сетях или дать вам адрес электронной почты их руководителя или друзей, чтобы вы могли предложить им продукт (даже если вы не станете это делать, чрезвычайно важна готовность человека поделиться контактными данными).
ВРЕМЯ КАК СПОСОБ ДЕМОНСТРАЦИИ ЦЕННОСТИ
Можно также спросить пользователя, готов ли он уделить значительное время совместной работе над новым продуктом (даже если вам это не нужно); такой подход хорош для тестов с корпоративными клиентами. Люди платят за ценность и таким способом.
ПРЕДОСТАВЛЕНИЕ ДОСТУПА КАК СПОСОБ ДЕМОНСТРАЦИИ ЦЕННОСТИ
Вы можете попросить реквизиты доступа к какому-либо продукту, с которого пользователи готовы переключиться на ваш, объяснив это утилитой миграции или другой причиной. На самом деле вам не нужны ни их логин, ни пароль — просто вы хотите знать, ценят ли они ваш продукт настолько высоко, чтобы начать использовать его немедля.
В этом случае ваша цель не что-либо доказать или подтвердить, а быстро и эффективно получить нужные и полезные знания. Вы считаете, что обнаружили новую проблему, либо хотите попробовать иной подход и вам нужно его проверить. Например, вы показали свой прототип двум разным людям, и их отзывы сильно отличаются, попытайтесь выяснить почему. Возможно, это два разных типа клиентов, и у них совершенно разные проблемы. Или это разные типы пользователей со своими навыками или квалификацией в разных предметных областях. А может, они используют различные решения, и один из них доволен продуктом, а второй нет.
Может также оказаться, что вам не удается заинтересовать людей той проблемой, над решением которой вы работаете, или у вас не получится сделать свое предложение удобным и понятным настолько, чтобы целевые потребители осознали его ценность. В этом случае вы, возможно, решите вообще прекратить работу над идеей или отложите ее. Некоторые продакт-менеджеры считают это серьезным провалом. Я же отношусь к такой ситуации как к благоприятной возможности для компании сократить ненужные траты на создание бесперспективного продукта.
Этот вид качественного тестирования замечателен своей простотой и эффективностью. Вы убедитесь в этом, дав свой ноутбук или планшет с установленным на нем продуктом или прототипом человеку, который его еще не видел, и предложив его опробовать.
И одно важное замечание: менеджер продукта должен присутствовать на каждом качественном тестировании ценности. Никогда никому не делегируйте эту обязанность и уж, конечно, не нанимайте для этого стороннюю фирму. Ваш вклад в эффективность своей команды в огромной мере зависит от прямого общения с как можно большим числом пользователей, тесного взаимодействия с ними при тестировании разных идей и внимательного изучения их отзывов. Если бы вы работали в моей компании, это условие было бы главнейшим критерием сохранения вашей фамилии в зарплатной ведомости.
Глава 54. Количественные методики тестирования ценности
Если предназначение качественного тестирования заключается в быстром обучении и составлении новой аналитической картины, то количественные методики — это инструменты для сбора подтверждений ценности ваших идей.
Иногда необходимо собрать достаточно данных для получения статистически достоверных результатов — особенно для потребительских сервисов с большим ежедневным трафиком, — а иногда планка устанавливается ниже. Мы просто собираем фактические данные об использовании продукта, которые считаем полезными подтверждениями его ценности, способными, помимо всего прочего, помочь нам принять обоснованное решение насчет наших дальнейших действий. Это и есть основное предназначение прототипа на реальных данных, который мы обсуждали раньше. Напомним, что такой прототип входит в число создаваемых на этапе исследования продукта для того, чтобы предложить ограниченной группе пользователей определенные сценарии его применения и в итоге собрать некоторые фактические данные об этом.
Существует несколько основных способов сбора таких сведений. Выбор методики зависит от объема вашего трафика, времени и отношения к риску.
У стартапов трафик обычно невелик, да и времени маловато, зато они смело идут на риск — ведь им еще нечего терять. В устоявшейся компании трафика более чем достаточно, и она располагает временем. Причиной для беспокойства обычно бывает то, что у менеджмента может лопнуть терпение. И, как правило, такие компании не склонны рисковать.
Золотым стандартом этого типа тестирования считается A/B-тест. Мы очень любим эти тесты, потому что пользователь не знает, какую версию продукта он видит, и мы получаем данные, весьма надежные с точки зрения точности прогнозирования, к чему мы, собственно, и стремимся.
Имейте в виду: речь идет о немного ином типе A/B-тестов, чем A/B-тесты с целью оптимизации. Во втором случае мы экспериментируем с разными призывами к действию, цветовыми решениями кнопок и тому подобными вещами. Концептуально эти типы тестирования одинаковы, но на практике между ними есть важные различия. В частности, A/B-тесты с целью оптимизации обычно предполагают поверхностные изменения с низким уровнем риска; часто это тесты в рамках сплит-теста (50:50).
В ходе A/B-тестирования на этапе исследования мы демонстрируем продукт 99 процентам пользователей, а прототип на реальных данных — только одному проценту, а то и меньше. И гораздо внимательнее отслеживаем результаты.
Если ваша компания не готова идти на риск или вам не хватает трафика, чтобы продемонстрировать версию продукта одному или даже 10 процентам пользователей и быстро получить значимые результаты, примените такой эффективный метод сбора доказательств, как тест только по приглашению. В этом случае вы определяете группу пользователей или клиентов, с которыми связываетесь и приглашаете испытать новую версию продукта. Вы говорите им, что это экспериментальная версия и, решив запустить ее на своем оборудовании, они дают согласие на участие в тестировании. Получаемые от этой группы данные не так информативны и полезны для прогнозирования, как полученные в результате реального «слепого» А/Б-тестирования. Очевидно, что чаще всего использовать «сырой» продукт соглашаются так называемые ранние последователи — люди, склонные ко всему новому и непривычному. Тем не менее мы получаем группу реальных людей, которые выполняют свою работу с использованием нашего прототипа на реальных данных, и данные, собранные таким образом, действительно очень важны и интересны.
Я даже не могу сосчитать, как часто мы полагаем, будто у нас есть то, что пользователи непременно полюбят, а после того как делаем это доступным для узкой группы людей, обнаруживаем, что их это ничуть не интересует. К сожалению, после проведения количественного теста данного типа мы точно узнаем только одно: что люди упорно этим не пользуются; и ни малейших подсказок и намеков на то, чем объясняется такая ситуация. Поэтому после такого теста проводится тот или иной качественный тест, позволяющий еще раз протестировать идею и максимально быстро узнать, почему пользователи увлечены ею не так сильно, как мы надеялись.
В одном из вариантов теста только по приглашению к тестированию привлекают участников программы по выявлению новых потребителей, которую мы обсуждали выше, в разделе, посвященном методикам для выработки идей. Эти компании уже принимают участие в тестировании ваших новых версий, и у вас налажены с ними тесные взаимоотношения, благодаря чему можно без труда продолжить с ними сотрудничество.
Обычно я применяю такой подход как основную методику для сбора фактических данных об использовании продуктов для корпоративных клиентов. Участники нашей программы по выявлению новых потребителей часто получают обновления прототипа на реальных данных, и мы сравниваем их данные об использовании с данными более широкого пула клиентов.
Одно из самых значительных изменений в нашем сегодняшнем подходе к созданию нового продукта связано с использованием аналитических данных. В наши дни от каждого хорошего продакта ожидают умения работать с такими данными и использовать аналитику для быстрого обучения, приобретения нужных знаний и повышения профессионального уровня.
Я объясняю это изменение несколькими факторами. Во-первых, тем, что благодаря глобальному доступу — и появлению сетевых устройств — рынок наших продуктов в последние годы резко расширился, а объем данных многократно увеличился и несравненно быстрее обеспечивает нас интересными и статистически значимыми результатами.
Во-вторых, тем, что инструменты для получения доступа к этим данным и приобретения благодаря им ценных знаний за последние годы значительно усовершенствовались. Но главную причину я вижу в осознании той роли, которую обычно играют эти данные, помогая вам быстро учиться и адаптироваться к изменениям.
В сильных продуктовых командах мы видим пять основных областей применения аналитических данных. Предлагаю детально рассмотреть каждую из них.
Понимание поведения пользователей и потребителей
Большинство людей, думая об аналитике, имеют в виду именно данные о пользователях продуктов, притом что это только один тип аналитики. Эти данные изучаются для того, чтобы понять, каким образом пользователи и клиенты используют наши продукты (помните: на одного потребителя приходится много пользователей, по крайней мере в контексте «бизнес для бизнеса»). Мы делаем это для выявления функций, которые ими не используются; для подтверждения того, что функции применяются так, как мы того ожидали; или просто для того, чтобы лучше понять, насколько велика пропасть между тем, что люди говорят и что делают.
Успешные продуктовые команды собирают и используют такие аналитические данные с этой целью уже не менее тридцати лет. За доброе десятилетие до появления интернета персональные компьютеры и серверы с помощью превентивного контроля состояния устройств собирали поведенческую аналитику, которая затем изучалась продуктовыми командами для доработки и усовершенствования продукта. По-моему, это одно из очень немногих требований к продукту, которое не стоит даже обсуждать. Я убежден: если вы собираетесь добавить новую фичу, вам необходимо включить как минимум базовый механизм сбора аналитики по ее использованию. А иначе как вы узнаете, работает ли она так, как вам требуется?
Оценка прогресса продукта
Уже много лет я пылкий сторонник использования данных для управления продуктовыми командами. Вместо того чтобы выдавать команде устаревшие дорожные карты с составленными кем-то списками догадок относительно того, какие фичи могут (или не могут) сработать, я предпочитаю предложить ей набор бизнес-целей с измеримыми конечными результатами, после чего команда сама принимает решение, какими способами лучше всего этих целей достигать. Это один из аспектов всеобъемлющей тенденции, наблюдающейся сегодня в сфере разработки новых продуктов — сосредоточиваться на результате, а не на процессе.
Подтверждение перспективности идей относительно продукта
Сегодня мы — особенно в компаниях по выпуску потребительских товаров, — проводя A/B-тесты, а затем сравнивая полученные результаты, имеем отличную возможность вычленить вклад новых фич, новых версий рабочих процессов и новых проектных решений. Это позволяет получать наглядные подтверждения того, какие из наших идей работают, а какие нет. Нам не нужно делать это со всеми своими предложениями, но для исследования продуктов, сопряженных с серьезным риском или высокими затратами на развертывание, или тех, что требуют изменений поведения пользователей, этот инструмент может быть чрезвычайно действенным и полезным. Даже если сбор статистически значимых результатов существенно затруднен из-за объема трафика или занимает очень много времени, мы имеем возможность собирать фактическую аналитику с помощью прототипов на реальных данных и принимать в итоге более информированные решения.
Сбор информации для принятия решений о продукте
По моему многолетнему опыту, самым скверным в решениях о продуктах в прошлом было то, что они обычно опирались на чьи-то мнения. И как правило, чем более высокую должность занимал в организации этот человек, тем больше с ним считались.
Сегодня, когда мы руководствуемся правилом «данные важнее мнений», у нас есть возможность провести тест и использовать собранные данные для принятия более обоснованных решений. Конечно, аналитика — это еще не все, и мы не должны становиться ее рабами, но в лучших продуктовых командах я вижу бесчисленные примеры удачных решений, в основу которых легли именно результаты тестов. И я постоянно слышу от людей, как часто аналитические данные становятся для них сюрпризом и как сильно меняют их точку зрения.
Вдохновение от работы над продуктом
Я давно укрепился в намерении использовать аналитические данные во всех перечисленных случаях, но, должен признать, мой фаворит — этот последний пункт. Совокупные данные, собранные из всех доступных источников, могут стать для нас настоящей «золотой жилой». Тут часто все сводится к умению задавать правильные вопросы, но впоследствии, изучая эти данные, мы можем выявить некоторые очень большие возможности в плане создания новых продуктов. Лучшие проекты, которые разрабатываются прямо сейчас, были вдохновлены именно аналитикой. Конечно, мы часто получаем отличные идеи, наблюдая за потребителями и применяя новые технологии, но анализ и изучение данных нередко становятся озарением и мощным толчком, дающим старт поистине революционным идеям. Во многом так происходит потому, что аналитика частенько застает нас врасплох, становится сюрпризом. У нас имеется ряд предположений о том, как используется наш продукт, причем о большинстве вариантов мы даже не подозреваем, и, увидев данные, очень удивляемся тому, насколько сильно действительность не соответствует нашим ожиданиям. И такие сюрпризы нередко становятся толчком к реальному прогрессу.
Менеджер по высокотехнологичным продуктам обязан разбираться в разных видах данных для тех продуктов, с которыми он работает. Многие коллеги, надо признать, подходят к этой задаче слишком узко. Вот базовый набор аналитики для работы с большинством высокотехнологичных продуктов.
• Аналитика тенденций пользовательского поведения (отслеживание кликов, активность пользователей).
• Бизнес-аналитика (активные пользователи, коэффициент конверсии, пожизненная ценность клиента, коэффициент удержания клиентов).
• Финансовая аналитика (средняя продажная цена, обороты по счетам, время закрытия счетов).
• Производительность (время загрузки, аптайм).
• Операционные расходы (хранение, хостинг).
• Затраты, связанные с выходом на рынок (логистические затраты, себестоимость продаж, маркетинговые программы).
• Структура поведения (индекс потребительской лояльности [Net Promoter Score, NPS], уровень удовлетворенности потребителей, опросы).
Надеюсь, теперь вы видите, какую огромную роль играет аналитика в успехе продуктовых команд. Однако, как бы ни были важны и полезны эти данные, важно помнить, что они проливают свет на происходящее, но не объясняют причин. Для интерпретации количественных результатов нам необходимы качественные методики.
(Обратите внимание: аналитические данные часто используются для отслеживания ключевых показателей эффективности [key performance indicators, KPI]).
Как ни удивительно, я и сегодня сталкиваюсь с продуктовыми командами, которые либо не используют свой продукт для сбора аналитических данных, либо так мало занимаются этим, что все равно не знают, использовался ли их продукт, и если да, то как.
Мои команды — и каждая команда, которую я могу вспомнить из тех, с какими когда-либо работал, — делают это так давно, что нам даже трудно представить, как можно работать без этой ценной информации. Я даже не могу вспомнить, каково это — не иметь ни малейшего представления о том, как использовался тот или иной продукт, какие фичи помогают пользователю решить его проблемы и те ли это фичи, которые, на наш взгляд, необходимо предложить, чтобы продукт охотно покупали.
Проще всего это делать с помощью «облачных» продуктов и сервисов, и большинство из нас используют веб-аналитику, но иногда мы выбираем для этого собственные инструменты.
Как я уже говорил, хорошие продуктовые команды занимаются сбором аналитики о своих продуктах не один год. И не только с помощью «облачных» сайтов, но и с использованием установленных мобильных приложений или приложений для ПК — локального софта, оборудования и устройств, которые периодически проводят проверку и отправляют командам данные о фактическом использовании их продуктов. Нужно сказать, очень немногие компании сегодня настолько консервативны, чтобы запрашивать разрешение перед отправкой этих данных; в основном все проходит, так сказать, без лишних слов.
Безусловно, надо анонимизировать данные и агрегировать их так, чтобы в них не было никаких сведений, по которым можно установить личность их автора. И все же время от времени в новостях рассказывают о компаниях, которые нажили большие проблемы из-за того, что в своем стремлении выйти на рынок рассылали «сырые» данные. Создается впечатление, что, по мнению журналистов, мы отслеживаем их ради корыстных, гнусных целей, но все компании, с которыми я знаком, просто стараются выпускать лучшие продукты — более ценные, удобные и полезные для людей. А сбор аналитических данных уже давно стал в этом одним из важнейших инструментов.
В общем все происходит так: сначала мы задаем себе вопрос, что нам нужно знать об использовании наших продуктов, затем дополняем продукт возможностями для сбора этой информации (выбор методик зависит от используемого инструмента и от того, какие данные нам нужны). И в конце генерируем онлайн-отчеты в различных формах для анализа собранных данных и их интерпретации.
Мы стремимся располагать инструментами для оценки всего нового, что добавляется в продукт, чтобы незамедлительно узнавать, работает ли он так, как мы ожидаем, и не возникло ли не предусмотренных нами последствий. Честно говоря, без этого инструментария я не стал бы выводить на рынок ни одну новую фичу. Откуда нам знать, как она в действительности работает?
Большинство успешных менеджеров продукта первым делом утром проверяют аналитику, чтобы узнать, что произошло за предыдущую ночь. Они постоянно проводят тестирование в той или иной форме, и им, разумеется, очень интересно, что эти тесты показывают.
Конечно, существуют экстремальные среды, где все происходящее защищено надежнейшими брандмауэрами, но даже в этом случае продакты могут генерировать периодические отчеты об их использовании; эти отчеты анализируются и после получения разрешения направляются продуктовым командам (при необходимости в виде электронных или печатных документов).
Я большой энтузиаст радикального упрощения продуктов путем удаления из них всех функций и опций, которые не способны нести даже свой вес. Но если не знаешь, что и как используется, это становится весьма мучительным, ведь неизвестно, что происходит на самом деле. В этом случае у нас нет данных, которые подтверждали бы наши теории или решения, и наш менеджмент (с полным на то правом) артачится, не желая их принимать.
На мой взгляд, вам стоит начать с признания того, что наличие аналитических данных о продукте обязательно, и стартовать отсюда в обратном направлении, чтобы найти лучший способ их получения.
Глава 55. Тестирование реализуемости
Для того чтобы подтвердить наличие технических возможностей идеи, инженеры-программисты стараются ответить на ряд вопросов по существу дела:
• Знаем ли мы, как это создать?
• Обладает ли наша команда необходимыми для этого навыками?
• Достаточно ли у нас времени для создания продукта?
• Потребуются ли какие-либо изменения архитектуры?
• В наличии ли все необходимые компоненты?
• Понимаем ли мы, какие взаимосвязи и зависимости предполагает реализация идеи?
• Будет ли приемлемой производительность полученного результата?
• Будет ли полученный результат масштабироваться до необходимого уровня?
• Имеется ли у нас инфраструктура для его тестирования и запуска?
• Можем ли мы позволить себе все связанные с этим расходы?
Я не намерен вас пугать. В большинстве случаев ваши разработчики, оценивая идеи новых продуктов на этапе исследования, быстро рассмотрят все эти пункты и ответят, что проблем нет. По большому счету задачи не такие уж и новые, и разработчики уже много раза делали что-то подобное.
Тем не менее к некоторым идеям это не относится, и тогда ответить на эти или даже на многие из перечисленных вопросов бывает очень трудно.
Приведу весьма распространенный пример: сегодня многие команды оценивают технологию машинного обучения, обдумывают решения типа «создавать или покупать» и прикидывают, подходит ли она для выполняемой ими задачи — и, если говорить шире, пытаются оценить ее потенциал.
С удовольствием дам вам несколько важных практических советов на этот счет. Проведение еженедельных планерок, на которых менеджер продукта, предлагая инженерам-программистам готовый список идей, требует дать их оценку с точки зрения затрат времени, насчитать баллы за пользовательскую историю или оценить в других единицах усилий, которые понадобятся для ее реализации, — это верный рецепт краха. Если вы припрете разработчика к стене, не дав ему времени расследовать и обдумать идею, то, скорее всего, получите от него консервативный ответ, нацеленный отчасти на то, чтобы его оставили в покое. Если же ваши инженеры-программисты вместе с другими членами команды тестировали идеи на потребителях (с применением прототипов) и своими глазами видели их проблемы и то, как они отнеслись к этим идеям, значит, у них, по всей вероятности, уже было некоторое время на их обдумывание. Короче говоря, если вы считаете идею стоящей, дайте специалистам возможность изучить и проанализировать ее.
Не следует ставить вопрос так: «Ну что, сможете это сделать?» Попросите инженеров-программистов ознакомиться с идеей и ответить на вопрос: «Как, по-вашему, это лучше сделать, и сколько времени это займет?».
Иногда чуть позже они возвращаются к менеджеру со словами, что для того, чтобы ответить на один или несколько из перечисленных вопросов, им нужно создать прототип для проверки реализуемости замысла. В таком случае сначала обдумайте, заслуживает ли потенциал идеи столь существенных трат времени на этапе исследования. И если да, давайте добро на дальнейшую работу.
И последнее важное замечание об оценке осуществимости новых идей: я не раз встречал и до сих пор встречаю менеджеров продукта, которым ненавистна любая идея, если на ее обдумывание инженеры-программисты просят дать им время. Этим менеджерам такой ответ говорит о том, что идея рискованная и на ее реализацию уйдет слишком много времени (в лучшем случае). Обычно я им говорю, что мне такая ситуация, напротив, очень нравится по нескольким причинам. Во-первых, многие удачные идеи относительно продуктов основываются на таких подходах к решению, которые стало возможным применять только сейчас, что означает появление новой технологии, на изучение которой людям нужно время. Во-вторых, по моему опыту, если технарям дают хотя бы два дня на изучение и обдумывание идеи, они часто возвращаются не только с хорошими ответами на вопросы о возможностях ее реализации, но и с более перспективными способами решения проблемы. В-третьих, такой подход обычно очень мотивирует команду, поскольку обеспечивает людей возможностью учиться и проявлять свои таланты и способности.
Как известно, сегодня очень многие высокотехнологичные продукты включают в себя аппаратный элемент. Телефоны и часы, робототехника и автомобили, медицинская аппаратура и термостаты — смарт-устройства повсюду. Каким образом включение в уравнение аппаратных средств влияет на все, что мы с вами к этому моменту обсудили?
Некоторые различия в подходах очевидны, например, необходимы другие инженерно-технические навыки, потребность в промышленном дизайне. И конечно, на производство «железа» по-прежнему уходит значительно больше времени, чем на написание софта, хотя, нужно признать, тут ситуация постоянно улучшается.
По большей части все, что мы с вами обсудили, применимо и к аппаратным продуктам, хоть есть и дополнительные вызовы. Скажу больше: когда в уравнение включается аппаратное обеспечение, методики исследования продукта, о которых мы говорили в предыдущих главах, приобретают большое значение, и в первую очередь это касается прототипирования. При разработке «железа» ошибки обходятся гораздо дороже и в сроках, и в деньгах. При работе над софтом исправление ситуации стоит относительно недорого, а с аппаратными продуктами все не так просто. В частности, создание «железа» сопряжено со значительно большими рисками технической осуществимости; возникают дополнительные риски и в связи с бизнес-жизнеспособностью решения. Например, для аппаратного обеспечения требуется более сложный анализ компонентов и производственных затрат и такое же прогнозирование. Хотя, нужно признать, в последние годы процедура прототипирования аппаратных средств усовершенствовалась и упростилась благодаря появлению технологии 3D-печати.
И главное, аппаратные продукты требуют от разработчиков агрессивного подхода к работе с рисками ценности, юзабилити, реализуемости и бизнес-жизнеспособности, а еще приходится намного выше поднимать планку веры в успех продукта, прежде чем браться за его изготовление.
Глава 56. Тестирование бизнес-жизнеспособности
Никто не станет спорить с тем, что даже просто попытаться придумать продукт, который полюбят потребители, а инженеры-программисты сумеют создать и поставить на рынок, чрезвычайно трудно. Многие идеи никогда не доходят до этого момента. Но и этого недостаточно. Решение должно работать и для вашего бизнеса. Словом, я хочу вас сразу предупредить, что выполнить это требование намного сложнее, чем кажется на первый взгляд.
Многие продакт-менеджеры признаются, что это самая нелюбимая часть их работы. Я отлично их понимаю, но объясняю, что именно это умение часто отличает хорошего продакта от великого и его в первую очередь имеют в виду, когда говорят о ком-то как о СЕО по продукту.
Создание бизнеса всегда дело сложное. Вам необходимо иметь жизнеспособную бизнес-модель. Затраты на производство, маркетинг и продажу продукта должны быть существенно ниже приносимого им дохода. Вы должны действовать с соблюдением законодательства всех стран, в которых продаете свой продукт. И неуклонно соблюдать свои обязанности в рамках всех деловых и партнерских соглашений. При этом каждый ваш продукт должен органично вписываться в обещание бренда остальных предложений компании.
Вы должны защищать доход, репутацию, сотрудников и клиентов своей компании — все, над достижением чего много и упорно трудились.
В этой главе я назову основные заинтересованные стороны компаний по выпуску высокотехнологичных продуктов, покажу типичные для них тревоги и ограничения, а также объясню, как менеджер продукта тестирует его бизнес-жизнеспособность в каждом из этих аспектов. Отмечу, что это очень общий список и большинство (или все) включенных в него областей, скорее всего, относятся и к вашим продуктам, но нужно помнить, что очень часто в компаниях есть также одна или несколько специфических заинтересованных сторон, уникальных для бизнеса. И то, что они не упомянуты мной далее, не означает, что на мнение такой заинтересованной стороны можно обращать меньше внимания.
Продакт-менеджеру вряд ли хочется столкнуться с ситуацией, когда его команда, усердно трудившаяся и тратившая время на превращение идеи в подходящий для продажи продукт, в итоге узнает, что его нельзя вывести на рынок и предложить потребителю, так как в нем не учтено важное ограничение. Знайте: подобное случается всегда по вине продакт-менеджера, поскольку его обязанность — знать и понимать все важные требования и ограничения и целенаправленно работать над их неукоснительным соблюдением.
Мы уже обсуждали функции маркетинга продукта и говорили о том, что считаем маркетолога скорее членом продуктовой команды, чем заинтересованной стороной. Но в более широком смысле это функциональное подразделение заботится о стимулировании продаж, бренде, репутации и конкурентоспособности компании на рынке, четкой дифференциации продукта. Маркетологам нужно, чтобы итоговый продукт был актуальным и привлекательным для потребителя, чтобы он максимально точно соответствовал используемым компанией каналам выхода на рынок. Следовательно, все ваши мысли и идеи, сопряженные с риском для вышеперечисленного, будут вызывать у отдела маркетинга серьезное беспокойство и даже неприятие.
Если предлагаемая вами идея может как-то сказаться на канале продаж или основных маркетинговых программах либо не согласуется с обещанием бренда (не входит в диапазон ожиданий потребителей от вашей компании), непременно обсудите ее с маркетологами — а лучше покажите им прототипы, — прежде чем приступать к ее реализации. Трудитесь сообща, вместе ищите пути устранения всего, что вызывает у них сомнение и беспокойство.
Наличие в вашей компании подразделения прямых продаж или отдела рекламы сильно сказывается на деятельности разработчиков новых продуктов. Как известно, успешны обычно те продукты, которые создаются с учетом преимуществ и ограничений имеющегося у компании канала продаж. Если канал прямых продаж обходится очень дорого, значит, вам нужен продукт с высокой ценностью и высоким ценовым ориентиром. Предположим, вы создали канал продаж с определенными навыками, и если новый продукт требует совсем других умений и знаний, торговый персонал может наотрез отказаться с ним работать.
Словом, если ваша идея сопряжена с существенными отклонениями от продукта, эффективность продаж которого вашим каналом продаж уже доказана, сядьте рядом с руководителями подразделения и продемонстрируйте им свое предложение. Постарайтесь вместе найти эффективный способ продаж. И сделайте все это до того, как приступите к разработке.
В одних компаниях по выпуску высокотехнологичных продуктов реализуется модель персонализированной помощи клиентам (помощи вручную), в других предоставляется автоматизированная помощь. Менеджеру по продукту необходимо хорошо понимать, какая стратегия успеха клиентов используется в вашей компании, и обеспечить согласованность продуктов с ней.
Если вы предлагаете что-то, что потребует серьезных изменений, вам нужно обсудить варианты и альтернативы с руководством этого подразделения.
И еще, при использовании модели персонализированного сервиса его персонал просто незаменим при выработке идей продукта и их тестировании с применением прототипов.
Финансовое подразделение, как известно, часто налагает строгие ограничения и высказывает сомнения насчет денежных затрат, и не в последнюю очередь они касаются того, может ли компания позволить себе создание, продажу нового продукта и управление им. Бизнес-аналитика и отчетность тоже прерогатива финансистов, да и отношения с инвесторами и другие сложные вопросы также ставят ограничения.
При возникновении проблем с предстоящими затратами смоделируйте вместе со специалистом из финансового подразделения расходы, чтобы потом продемонстрировать руководству жизнеспособность вашего подхода для бизнеса.
Во многих высокотехнологичных компаниях, особенно в тех, которые настроены революционно и очень агрессивно, роль юридического департамента чрезвычайно важна. Вопросы безопасности и конфиденциальности, соблюдение законодательств разных стран и прав интеллектуальной собственности, проблемы конкуренции — все это правовые требования, которые касаются любой компании из сферы высоких технологий. И вы сэкономите массу времени и избавитесь от серьезных неприятностей, если как можно раньше обсудите со своими юристами идею, чтобы узнать, не возникнет ли в связи с ее реализацией правовых коллизий, а также уточните разные юридические моменты, которые вам непременно нужно в связи с этим знать.
Как известно, большинство современных компаний поддерживают деловые отношения с разными партнерами; обычно эти отношения скрепляются контрактами с определенными обязательствами сторон. Бывает, эти соглашения снижают конкурентоспособность компании. А иногда, напротив, становятся для нее неоценимым подспорьем. В любом случае вам необходимо понимать влияние этих отношений на ваши продукты и на то, чем вы предлагаете заниматься своей команде в ближайшее время.
Обычно к тем, кто занимается вопросами безопасности в компании, мы относимся не как к заинтересованной стороне, а как к неотъемлемой части инженерно-технического подразделения и, следовательно, нашей продуктовой команды. Однако эти вопросы настолько важны, что, на мой взгляд, перед тем как приступать к работе над новой идеей, всегда стоит поговорить с людьми из этой сферы деятельности. В общем, если вы предлагаете что-то, хотя бы отдаленно касающееся проблем безопасности, пусть один из технических руководителей обсудит с руководителем отдела безопасности вашу идею и то, как вы будете решать соответствующие проблемы.
В каждой компании есть СЕО или главный менеджер, отвечающий за эту бизнес-единицу. Скорее всего, они отлично знают и понимают все описанные выше ограничения и уделяют им должное внимание. И если продакт-менеджер не разбирается в этих вопросах или не имеет плана работы с ними, руководитель компании вряд ли будет доверять ему и его продуктовой команде. Заметьте, СЕО не понадобится много времени, чтобы выяснить, сделал ли менеджер продукта «домашнюю работу» — понимает ли разные аспекты бизнеса.
Тестирование бизнес-жизнеспособности новой идеи или продукта призвано подтвердить, что в предлагаемом командой решении учтены все описанные ограничения. Всем заинтересованным лицам, которых тем или иным образом оно затронет, важно иметь возможность проанализировать новое решение и убедиться, что вы продумали все и нашли способ развеять их сомнения.
В этой книге я много говорил о показе прототипа. По правде говоря, эта задача может выполняться с помощью трех разных методов, и нужно очень внимательно выбрать правильный в той или иной ситуации.
Пользовательский тест — это тестирование идеи на реальных пользователях и клиентах. Это качественная методика тестирования юзабилити и ценности; пользователю позволяется делать все собственноручно. Цель — протестировать юзабилити и ценность прототипа или продукта.
Демонстрация продукта — это продажа продукта потенциальным пользователям и клиентам либо проведение мероприятий в духе евангелизма и продвижение продукта в собственной компании. Это инструмент продаж или убеждения. Нужно сказать, что демоверсию с тщательно продуманным сценарием разрабатывают маркетологи, но провести ее иногда просят продакт-менеджера — особенно для важного клиента или высшего руководства компании. В этом случае все действия совершает менеджер продукта, а его цель — продемонстрировать ценность прототипа или продукта.
Сквозной просмотр, или разбор программы, — это показ прототипа заинтересованной стороне, чтобы убедиться, что она обратила внимание на все, что может вызвать у нее беспокойство. В данном случае наша цель — предоставить заинтересованной стороне возможность обнаружить проблему. Все действия обычно выполняет менеджер продукта, но если заинтересованной стороне хочется «поиграть» с прототипом, то ей это с радостью позволяют. Вы не стараетесь что-либо продать, не пытаетесь протестировать продукт и определенно не собираетесь что-либо скрыть и утаить.
Я много раз видел, как неопытные продакт-менеджеры проводят сквозной просмотр с потенциальным клиентом, хотя им следовало бы подготовить демонстрацию продукта. Другая весьма распространенная ошибка новичков — провести демонстрацию в рамках пользовательского теста, а затем попросить пользователя высказать свое мнение.
Всегда четко определяйте, что вы делаете — проводите пользовательский тест, демонстрацию продукта или сквозной просмотр. И непременно убедитесь, что хорошо владеете всеми тремя методиками.
Глава 57. Знакомьтесь: Кейт Арнольд из Netflix
Netflix — один из моих любимых продуктов, и одна из моих любимейших компаний. Но мало кто помнит, что в 1999 году совсем еще юная Netflix (тогда она располагалась в Лос-Гатосе, и в ней работало менее двух десятков сотрудников) оказалась на грани разорения. У компании было несколько опытных основателей, в том числе легендарный Рид Хастингс, однако она забуксовала на 300 тысячах клиентов.
В сущности, Netflix предлагала общепринятый подход «плата за прокат», как и Blockbuster, только в онлайн-версии. И у нее, как и у многих, имелась группа ранних последователей, причем некоторые из них жили в местах, где не было ни одного видеомагазина. Согласитесь, мало кто будет брать напрокат DVD через Почтовую службу США, если по дороге домой можно заскочить в местный Blockbuster. Как правило, люди брали видео в Netflix раз или два, после чего быстро забывали об этом сервисе. Похоже, им не слишком хотелось что-нибудь менять. Команда Netflix понимала, что недостаточно опережает конкурентов, чтобы переманить людей на свою сторону.
А тут еще продажи DVD начали неуклонно снижаться, да и противодействие Голливуда усугубляло плохое положение вещей. Не следует забывать и о серьезных трудностях с логистикой, сложностях поддержания высокого качества DVD и попытках понять, как сделать все так, чтобы покрывать расходы и получать прибыль наличными.
Кейт Арнольд была в то время менеджером по продукту этой небольшой команды, и команда точно знала, что нужно что-то менять.
Среди множества предпринятых ими попыток был переход на абонентское обслуживание. По замыслу, нужно было убедить людей подписаться на месяц и предложить абонентам неограниченное количество фильмов. Но вот вопрос: воспримут ли люди это как улучшение и изменят ли свое поведение в сфере медиапотребления?
Хорошей новостью оказалось то, что новый подход понравился потребителям. Фиксированная ежемесячная плата за неограниченный доступ к видео очень заинтересовали их. Но была и плохая новость: таким шагом команда создавала себе реальные трудности. Разумеется, клиенты Netflix хотели смотреть в основном последние художественные фильмы, а такой контент обходился компании дороже всего. Чтобы иметь в наличии необходимое количество копий, требовалось много денег, а их у Netflix не было.
Итак, компании предстояло решить задачу: как, не обанкротившись, сделать так, чтобы клиенты могли смотреть те фильмы, которые хотят?
Команда, перед которой она была поставлена, знала, что нужно каким-то образом убедить клиентов захотеть смотреть микс из дорогостоящих и менее дорогостоящих фильмов. Острая нужда, как известно, мать всех изобретений и нововведений; на этой почве выросли списки ожидания, рейтинговая система и рекомендательный сервис Netflix. Благодаря этим технологическим инновациям появилась новая, более эффективная бизнес-модель.
Команда взялась за дело. За три месяца она изменила дизайн сайта, дополнив абонентское обслуживание Netflix перечисленными выше элементами. А еще она переписала автоматизированную систему расчета с абонентами для работы по модели ежемесячной подписки. (Любопытный факт: начинала компания без этой системы, потому что сперва предлагала тридцатидневный бесплатный пробный период, что обеспечило ее необходимым дополнительным временем.)
Учитывая огромный объем одновременно внедряемых изменений и взаимосвязанных усилий, в процесс были вовлечены почти все сотрудники компании.
Можно представить, какую нагрузку ежедневно несла на своих плечах Кейт: это и работа с соучредителями над выработкой стратегии, и тестирование новой концепции на реальных пользователях, и анализ данных, и разработка фич и функциональности новой системы в составе своей продуктовой команды. Помимо того, вместе с финансистами она трудилась над созданием новой бизнес-модели, с маркетологами — над вопросами закупок, с руководством складов — над реальными проблемами логистики. И все же команда сумела запустить сервис и использовала его для поддержания и развития бизнеса еще семь лет, до тех пор, пока опять не перевернула все с ног на голову, начав решительный и агрессивный переход на модель потоковой передачи.
Кейт, я уверен, приписала бы все заслуги своей потрясающей команде, в том числе некоторым превосходным инженерам-программистам, а также смелому видению и мужеству основателей компании. Но я считаю, что без самой Кейт и ее страсти к высокотехнологичным решениям, которая смогла привести в движение всю компанию, очень даже вероятно, что Netflix в том виде, в каком мы ее сегодня знаем, не состоялась бы.
Еще пара интересных фактов о юной Netflix: на раннем этапе компания столкнулась с серьезной проблемой наличных средств, и тогда она предложила купить себя Blockbuster за 50 миллионов долларов, но та отказалась. Сегодня на Blockbuster никто не поставит и копейки, а Netflix стоит больше 40 миллиардов долларов.
Кейт сегодня работает лидером продукта в Нью-Йорке.