Методов и подходов к генерированию идей и замыслов продуктов множество. И, признаться, я не встречал ни одного, который бы мне не нравился. При этом для меня в первую очередь актуально получить ответ на вопрос «Как вырабатывать идеи, способные помочь решить сложные бизнес-проблемы, на которых лидеры попросили нас сосредоточиться в настоящий момент?»
Примечательно, что в большинстве компаний — из тех, что не слишком преуспевают в разработке продуктов, — продуктовые команды сами генерируют идеи нечасто. Идеи «спускаются» им в виде расставленных в порядке приоритетности функций и опций — дорожных карт продукта, и большинство пунктов в этих картах взяты либо из запросов крупных (или потенциальных) клиентов, либо поступают от заинтересованных сторон или руководства компании. К сожалению, качество таких идей чаще всего оставляет желать лучшего. Между тем, если продуктовой команде предлагают не решения, над которыми нужно работать, а актуальные бизнес-проблемы, и она выполняет свою работу, напрямую и часто взаимодействуя с реальными пользователями и клиентами, то получить достаточно идей отличного качества не так уж и сложно.
Несколько отличных методик позволяют стабильно снабжать команду весьма перспективными и очень актуальными идеями продукта, над которым стоит работать. Но есть одна важная оговорка: начав использовать их, вы будете удивлены количеством полученных в результате идей. Однако это не значит, что вы должны просто брать быка за рога и реализовывать все. Сначала их необходимо протестировать, чтобы убедиться в их ценности и полезности для потребителей и в том, что они технически выполнимы и выгодны для вашего бизнеса.
Глава 41. Интервью с пользователем
Среди всех методик, о которых рассказывается в книге, интервью с пользователем — основная. Я очень хотел бы, чтобы мне не нужно было включать ее в обсуждение, потому что, на мой взгляд, нам стоило бы исходить из того, что каждый менеджер продукта знает, как проводить ее правильно, и часто использует в своей работе.
К сожалению, это не всегда так. Даже если такие интервью проводятся, менеджер продукта на них часто не присутствует и, как следствие, не принимает полученную из них информацию близко к сердцу, не воспринимает ее так серьезно, как должен (см. принцип исследования продукта № 10, касающийся совместного обучения, в главе 33). А между тем такие интервью, несомненно, один из самых важных навыков для любого продакт-менеджера и очень часто источник вдохновения для многих прорывных идей. При использовании методик для качественного тестирования идей, которые мы будем обсуждать далее, вы увидите, что владение этими навыками — обязательное условие.
Формы интервью с пользователями могут быть разными, так что, строго говоря, это не совсем одна методика. Одни интервью неформальные, другие формальные. В основе одних лежит та или иная методология исследования пользовательского поведения (одна из моих любимых — контекстный запрос); другие нацелены на то, чтобы «вытащить» из человека новые сведения и узнать то, чего мы пока не знаем.
Как бы там ни было, мы можем извлечь те или иные ценные сведения буквально из каждого взаимодействия с пользователем или клиентом. Вот что я всегда пытаюсь узнать в ходе такого общения:
• Действительно ли ваши потребители те, кого вы ими считаете?
• В самом ли деле они имеют те проблемы, которые вы предполагаете?
• Как этот потребитель решает свою проблему сегодня?
• Что нужно для того, чтобы он стал использовать ваш продукт?
Способов получить ответы на эти вопросы много, и если у вас есть доступ к хорошему исследователю пользовательского поведения, то обычно вы идете по его «наводкам». Несколько советов позволят вам извлечь максимум пользы из этих возможностей обучения и приобретения нужных знаний.
• Частота. Проводите интервью с пользователями с регулярной частотой. Бесполезно делать это лишь время от времени. Минимальная частота — два-три часа каждую неделю.
• Главная цель. Во время интервью вы не пытаетесь что-либо доказать потребителю, а лишь хотите лучше понять его запросы и чаяния и быстро узнать что-то новое, что может быть вам полезно. Такой настрой чрезвычайно важен, и он должен быть искренним.
• Привлечение пользователей и клиентов. Детальнее мы поговорим об этом, когда будем обсуждать методику тестирования юзабилити, а пока скажу, что нужно всегда стараться общаться в первую очередь с людьми с целевого рынка, на котором вы намерены работать, а для этого вам придется отнять у них около часа.
• Место проведения интервью. Всегда полезно и поучительно встречаться с клиентами в их «родной среде обитания». Как много всего можно узнать, просто наблюдая за окружением человека! Но можно встретиться и в другом удобном месте или пригласить пользователя к себе в офис. Делать это по видеосвязи не так хорошо, но все же лучше, чем вообще не общаться с потребителем.
• Подготовка. Заранее четко определите, в чем, по-вашему, заключается проблема пользователя. Обдумайте, как вы будете подтверждать или опровергать это предположение.
• Кто должен присутствовать. Мой любимый вариант — привлечь к интервью трех человек: продакт-менеджера, дизайнера продукта и одного из инженеров-программистов продуктовой команды (мы обычно по очереди посылаем тех, кто изъявляет желание присутствовать на встрече). Обычно дизайнер ведет беседу (потому что этих специалистов обучают этому), менеджер продукта ведет записи, а разработчик наблюдает.
• Собственно интервью. Старайтесь сделать общение естественным и неформальным; задавайте вопросы, требующие развернутого ответа, и пытайтесь как можно детальнее выяснить, как люди борются с интересующей вас проблемой сегодня, а не как им хотелось бы это делать, хотя это тоже интересно.
• Последующие действия. После беседы расспросите коллег, чтобы убедиться, что вы все услышали одно и то же и теперь располагаете одинаковыми знаниями. Если во время встречи вы что-нибудь пообещали потребителю, непременно сдержите слово.
Я утверждаю, что час, проведенный в общении с пользователем, всегда отлично окупается. Чрезвычайно важно знать ответы на перечисленные выше ключевые вопросы. А еще я большой поклонник использования больших возможностей интервью с клиентами с целью тестирования некоторых идей относительно продукта. Мы делаем это после того, как узнаем ответы на ключевые вопросы, но это действительно прекрасная возможность, которой мне очень нравится пользоваться.
При обсуждении тестирования юзабилити и ценности продукта мы поговорим и о других методиках. Сейчас же просто запомните, что после интервью с клиентом можно провести пользовательский тест вашей новейшей идеи или замысла продукта.
Глава 42. Консьерж-тест
Консьерж-тест — одна из моих любимых методик; она позволяет быстро вырабатывать превосходные идеи для продукта и лучше понимать своего потребителя, вызывает эмпатию по отношению к нему, что невероятно важно для мотивации команды и выработки отличных решений.
Консьерж-тест относительно новое название старой, но очень эффективной методики. По его замыслу, мы выполняем работу за потребителя — вручную и лично. Это все равно что попросить портье отеля найти вам, скажем, билеты в театр на популярное шоу. Вы не знаете, как он добудет вам билеты, но знаете, что непременно сделает это каким-то образом.
При использовании этой методики вы становитесь консьержем. Вы делаете за своих пользователей или клиентов то, что в противном случае им пришлось бы делать самим. Возможно, сначала вам придется попросить их провести для вас тренинг, но в итоге вы «влезаете в их шкуру» и делаете то, что делали бы они.
В некотором смысле эта методика похожа (но не то же самое) на рабочий день, проведенный вами в службе поддержки клиентов или с персоналом по управлению успехом клиентов. Такой тест очень полезен еще и тем, что нередко становится источником перспективных идей относительно продукта, но главное — это помощь пользователям, обратившимся к вам со своей проблемой.
Эта методика подразумевает обращение с просьбой к реальному пользователю или клиенту показать вам, как он работает, что позволяет узнать, как он подходит к делу, и благодаря этому выработать более удачное решение его проблемы.
Если вы создаете продукт для обслуживания клиентов, то пользователями будут сотрудники вашей компании, но действовать нужно так же: вы просите коллег научить вас делать их работу. В целях совместного обучения стоит привлекать к участию в консьерж-тесте продакт-менеджера, дизайнера продукта и одного из инженеров-программистов.
Глава 43. Сила «неправильного» поведения потребителя
В прошлом эффективные продуктовые команды использовали два подхода к определению продуктово-рыночных возможностей:
1. Оценка рыночных возможностей и выбор потенциально прибыльных зон, где существует серьезная проблема.
2. Оценка и «подгонка» актуальных возможностей технологий или данных, имеющихся в вашем распоряжении, для решения серьезной проблемы.
Вы можете думать о первом подходе как о следовании за рынком, а о втором — за технологией. Каждый из них способен подсказать вам идею отличного нового продукта. Однако сегодня некоторые преуспевающие компании выбирают третий подход, и хотя он годится не для всех, это очень действенный метод, который, к сожалению, недооценен и явно недостаточно часто используется в нашей отрасли. Речь идет о том, чтобы разрешать потребителям и даже поощрять их использовать наши продукты для устранения других проблем, а не только тех, решение которых уже возложено на нас, в отношении которых мы уже обеспечиваем официальную поддержку.
Мой давний друг Майк Фишер написал книгу Power of Customer Misbehavior («Влияние неправильного поведения потребителя»). В ней в основном рассказываются истории лавинообразного роста eBay и Facebook, но есть и несколько других очень интересных примеров.
С первых дней существования eBay на сайте был раздел Everything Else («Все остальное»). Здесь люди могли покупать и продавать вещи, которыми, по нашим ожиданиям, они не должны были бы хотеть торговать. И хотя компания ждала многого (мы предлагали и предлагаем тысячи самых разных категорий), источником некоторых самых смелых инноваций и сюрпризов для нас стал мониторинг того, что хотят делать клиенты. В eBay очень быстро поняли, что именно здесь возникают идеи лучших инноваций, и сделали все возможное, чтобы клиенты развивали торговую площадку компании, поощряя их покупать и продавать что угодно.
Хотя изначально аукцион создавался для облегчения торговли электроникой и предметами коллекционирования, вскоре люди начали торговать билетами на концерты, произведениями искусства и даже автомобилями. И хотите верьте, хотите нет, сегодня eBay считается одной из крупнейших в мире компаний по торговле подержанными авто.
Как вы понимаете, между безопасной покупкой и транспортировкой автомобиля и покупкой билета на концерт мало общего. Поэтому необходимая работа была проделана компанией только после того, как окончательно установился спрос, для чего клиентов обеспечили возможностью заключать сделки на предметы, которых команда и компания не предполагали увидеть, и делать это неожиданными способами.
Те, кто предлагает продукты на рынке, расстраиваются, когда узнают, что потребители используют их детища не так, как подразумевалось. Недовольство обычно связано с обязанностями по поддержке. Но, по-моему, этот особый случай может иметь поистине стратегическое значение и заслуживать любых инвестиций в функцию поддержки клиентов. Так что, если вы обнаружите, что клиенты используют ваш продукт не так, как планировалось, знайте: здесь кроется ценный потенциал. Покопайтесь в этом, чтобы узнать, какую проблему люди пытаются решить таким образом и почему они верят, что ваш продукт способен обеспечить их подходящим фундаментом. Проделайте эту работу, и со временем непременно выявите определенные модели, а вместе с ними, может быть, и некоторые в высшей степени перспективные возможности в плане новых продуктов.
В примере eBay речь идет о конечных пользователях (покупателях и продавцах), но то же «неправильное» поведение лежит и в основе тенденции к открытому доступу к некоторым или всем сервисам продукта через интерфейсы прикладного программирования (публичные API). Предлагая публичный API вы, по сути, говорите сообществу разработчиков: «Вот что мы умеем — но, возможно, вы сможете использовать эти сервисы для того, чтобы сделать что-то поистине удивительное, что не пришло нам в голову».
Яркий пример — платформенная стратегия Facebook. Компания открыла доступ к своим профилям в социальной сети, чтобы выявлять, что могли бы сделать разработчики, будь у них возможность использовать этот актив.
Я давний фанат публичных API как неотъемлемого компонента стратегии развития продукта и считаю разработчиков одним из самых стабильных и лучших источников поистине инновационных идей в этом плане. Их положение выгодно с точки зрения понимания того, что возможно на данный момент, и, надо признать, очень многие инновации основаны на их проницательных идеях.
Глава 44. Хакатон
Хакатоны[14] проводятся в самых разных вариациях. В этой главе я опишу одну из своих любимых методик для быстрой выработки множества перспективных идей, решающих насущную проблему потребителя или вашего бизнеса.
Существует две основные разновидности хакатона: целевой и нецелевой. В рамках второго люди исследуют любые приглянувшиеся им идеи относительно продукта, хоть немного связанные с миссией их компании.
В случае целевого хакатона у нас имеется проблема потребителя (скажем, что-то очень трудно освоить или оно занимает слишком много времени) или определенная бизнес-цель (например, «уменьшить показатель оттока клиентов» или «повысить пожизненную ценность клиента»), поэтому мы просим членов продуктовых команд взять инициативу в свои руки и работать с любыми понравившимися им идеями, потенциально способными решить проблему. И главное, эти самоорганизующиеся группы должны изучить и проанализировать выбранные ими идеи, создать прототип в той или иной форме, который можно оценить, и, если дело того стоит, протестировать его на реальных пользователях.
У целевых хакатонов два преимущества: во-первых, практичность, так как методика весьма эффективно способствует включению инженеров-программистов в процесс генерирования идей. Я уже несколько раз упоминал о том, что многие лучшие идеи приходят именно от этих членов продуктовых команд, и нам необходимо воспользоваться такой возможностью. Вообще-то это должно происходить постоянно, и благодаря данной методике мы этого добиваемся. Во-вторых, культурное преимущество. Нужно сказать, это один из моих любимых способов формирования команд «миссионеров». Сегодня — если, конечно, они не сделали этого раньше, — инженеры-программисты все глубже погружаются в бизнес-контекст и играют намного более важную роль в инновациях своих компаний.