Возможно, это самая важная идея во всей книге: все зависит от продуктовой команды.

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

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

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

Продуктовая команда — это группа людей с разными профессиональными навыками и обязанностями; эти специалисты чувствуют себя владельцами создаваемого продукта или как минимум его значимой части.

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

Продуктовые команды создают для компании множество преимуществ, но главную их цель лучше всего выражают слова Джона Дорра, известного венчурного инвестора из Кремниевой долины: «Нам нужны команды „миссионеров“, а не „наемников“».

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

Типичная продуктовая команда состоит из продакт-менеджера, продуктового дизайнера и от двух до 10–12 инженеров-программистов.

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

Команды могут включать и других членов, таких как продуктовый маркетолог, один или несколько инженеров по автоматизации тестирования, исследователя, аналитика данных, а в более крупных продуктовых организациях еще и операционного менеджера с техническими навыками (delivery manager)[6].

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

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

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

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

Определен и «потолок» размеров продуктовой команды: обычно это от восьми до двенадцати человек. Вам, наверное, приходилось слышать о правиле двух пицц[7], которое призвано помочь командам удерживаться в этих рамках.

Однако намного важнее размера команды баланс профессиональных навыков, необходимых для того, чтобы ее члены создавали превосходные продукты правильным способом.

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

Люди в команде, как правило, подотчетны менеджеру своего функционального подразделения: программисты отчитываются перед руководителем технического отдела; дизайнер — перед руководителем дизайнерского отдела; менеджер продукта — перед главой подразделения менеджмента продуктов. Так что субординация не в чести в продуктовых командах.

Для полной ясности добавлю, что члены продуктовой команды не подчиняются менеджеру продукта.

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

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

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

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

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

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

О том, как мы поступаем, когда людей невозможно посадить в одном месте, подробно поговорим позже.

Итак, мы перечислили основные характеристики продуктовой команды, после чего встает следующий важный вопрос: каковы ее задачи и компетенции? За что именно несет ответственность та или иная продуктовая команда?

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

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

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

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

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

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

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

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

Добавлю, что продуктовые команды создаются не только ради реализации проектов. Практически невозможно создать команду «миссионеров», если люди собираются на несколько месяцев, а потом группа расформировывается.

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

Кроме того, нужно стараться минимизировать зависимость команд друг от друга. Обратите внимание: я говорю «минимизировать», а не «ликвидировать». Полностью устранить их взаимозависимость невозможно, но неуклонно и упорно работать над ее ослаблением мы можем и обязаны.

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

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

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

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

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

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

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

Эта книга о том, как стать отличным продакт-менеджером, а в данной главе я вам расскажу, что же это означает на самом деле. Но для начала немного суровой правды ради вашей же пользы.

Менеджер продукта может выбрать один из трех подходов к работе, но, по моему глубокому убеждению, только один из них ведет к успеху:

1. Он может переводить любую проблему и решение на уровень высшего руководства компании. В этом случае менеджер продукта, в сущности, просто администратор бэклога. По словам многих СЕО, в такой модели они со временем и оказываются, и это не имеет никакого отношения к масштабированию. И если вы думаете, что должностные обязанности менеджера продукта изложены в сертификацированном тренинге для работы по Scrum «Владелец продукта», то почти гарантированно попадаете в эту категорию.

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

3. Он может сам выполнять свою работу.

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

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

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

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

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

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

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

• Как потребители узнают о продукте?

• Как мы будем знакомить нового пользователя с продуктом и (возможно, постепенно) раскрывать ему его новые функциональные характеристики?

• Как пользователи могут взаимодействовать с нами и продуктом в разное время суток?

• Что еще конкурирует за внимание пользователя?

• Чем отличается потребитель, который с нами всего месяц, от того, кто пользуется нашим продуктом уже год?

• Как мы будем мотивировать пользователя еще активнее использовать наш продукт?

• Как мы будем радовать пользователя?

• Как пользователь будет делиться своим опытом с другими людьми?

• Как потребители будут получать офлайн-услуги?

• Как продукт реагирует на действия пользователя?

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

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

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

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

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

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

Если вы создаете такие продукты, как, например, бытовая электроника, существует еще один важный аспект дизайна — промышленный дизайн, — который занимается материалами и дизайном промышленных изделий.

Далее описаны три распространенные ситуации, которые чреваты весьма серьезными проблемами.

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

2. Как продакт-менеджер вы не пытаетесь разработать некое подобие дизайна самостоятельно, а рассказываете инженерам-программистам обобщенные пользовательские истории. И чтобы приступить к написанию кода, им ничего не остается, кроме как разработать дизайн самим.

3. Как продакт-менеджер вы предоставляете дизайн взаимодействия, опять же, чаще всего вайрфреймы, а затем привлекаете к разработке графического дизайнера.

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

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

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

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

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

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

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

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

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

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

Продуктовые маркетологи несколько отличаются от других членов продуктовой команды — но не тем, что их роль менее важна, а тем, что обычно они не работают с продуктовой командой весь рабочий день.

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

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

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

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

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

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

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

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

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

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

Как вы увидите при обсуждении этапа исследования продукта, технологическая компания постоянно занята двумя видами исследований: качественным и количественным.

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

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

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

Если в вашей компании нет таких сотрудников, их обязанности обычно берет на себя дизайнер продукта.

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

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

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

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

Инженеры по автоматизации тестирования, или, проще говоря, тестировщики, пишут автоматизированные тесты для вашего продукта. Во многих случаях они заменили старых QA-специалистов (quality assurance), которые занимались ручным тестированием.

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

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

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

Я уверен, что вы слышали о Google AdWords[8], а, возможно, и о том, что этот продукт считают главным «топливом» империи Google. Точнее говоря, на момент написания этих строк AdWords исполнилось шестнадцать лет, и только за последний год продукт принес компании более 60 миллиардов долларов дохода. Да-да, миллиардов!

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

На дворе стоял 2000 год, и самой сложной частью проекта AdWords стало просто получение согласия на работу над продуктом. Базовая идея пользовалась поддержкой Ларри Пейджа, но довольно скоро возникло мощное сопротивление как со стороны рекламистов и продавцов, так и со стороны инженеров Google.

Джейн Мэннинг была в те времена молодым руководителем инженерной группы; ее попросили взять на себя и функции менеджера продукта и попытаться сдвинуть проект с мертвой точки.

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

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

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

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

Потом Джейн сделала некоторый перерыв, чтобы создать семью, а затем вернулась в Google и помогает команде YouTube.

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

Что меняется в ролях руководителей? Как сохранять комплексный, всеобъемлющий подход к продукту, когда в компании работает много команд? Как добиваться того, чтобы команды чувствовали свою самостоятельность и ответственность в условиях, когда они владеют лишь небольшой частью целого? Как мы поощряем ответственность, когда единственный, кто владеет в компании всеми продуктами, — это СЕО? Как мы справляемся с резким расширением структуры взаимозависимости?

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

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

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

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

Далее описаны три элемента руководства, которые крайне важны для всеобъемлющего видения продукта.

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

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

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

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

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

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

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

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

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

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

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

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

Эта глава предназначена для представителей трех аудиторий. Непременно прочитайте ее, если вы:

• СЕО или глава отдела персонала и сейчас заняты поиском директора по продукту; вы лучше разберетесь в том, какого именно человека нужно искать;

• в настоящее время возглавляете продуктовое подразделение — это ваш ключ к успеху;

• мечтаете в один прекрасный день возглавить продуктовую компанию; в этой главе четко и откровенно обсуждаются навыки, которые вам понадобится для этого развить.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если ваша компания доросла до значительного масштаба, я уверен, что вы отлично знаете, о чем идет речь.

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

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

Cтартапам или небольшим компаниям для успешной работы часто достаточно одной сильной продуктовой команды с ярким, ориентированным на продукт СЕО или менеджером продукта. Но крупным компаниям обычно нужно больше. Им требуется сильное лидерство продукта в самом лучшем смысле этого слова, что, конечно же, предполагает обеспечение убедительного видения продукта и четкой стратегии работы с ним.

Одна из самых сложных задач в нашей индустрии — инициировать серьезные изменения в крупной и финансово успешной компании. Во многих отношениях сделать это значительно проще, когда у организации серьезные проблемы и она испытывает сильный дискомфорт, который можно использовать как очень мощный мотивирующий фактор. Однако поистине великие компании всегда готовы нарушить свой статус-кво сами, прежде чем это сделает кто-то другой. Разница между преуспевающими Amazon, Netflix, Google, Facebook и легионами других крупных, но медленно умирающих компаний, заключается именно в сильном продуктовом лидерстве.

В 2011 году Леа Хикман возглавила подразделение Adobe Creative Suite. К этому времени она проработала в Adobe уже несколько лет, помогая строить очень большое и успешное направление бизнеса, которое ежегодно приносило компании примерно 2 миллиарда долларов на продаже лицензий. Речь идет о программном пакете Creative Suite для настольных компьютеров.

Леа понимала, что рынок меняется и ее компании необходимо перейти со старой модели, ориентированной на настольный компьютер и требующей ежегодного обновления лицензии, к модели, основанной на подписке и поддерживающей планшеты и смартфоны со всеми их бесконечными моделями, которые дизайнеры все активнее использовали. Если смотреть шире, Леа знала, что устаревшая модель стимулировала компанию на изменения Creative Suite в направлениях, которые не были полезны ни для потребителей Adobe, ни для долгосрочного успеха самой компании. Но внедрить изменения такого огромного масштаба — а на доходы от Creative Suite приходилась примерно половина совокупного годового дохода Adobe, составлявшего 4 миллиарда долларов, — было чрезвычайно трудной задачей.

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

Назовем типичные поводы для беспокойства.

Финансовый персонал был крайне обеспокоен тем, как переход с лицензионной модели на модель подписки скажется на доходах.

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

Отдел продаж ожидал, что предлагаемый Леа переход повлечет за собой серьезные изменения способов продажи продуктов Creative Suite. Вместо крупной сети посредников Adobe перейдет к прямым отношениям с потребителями. Хотя многие в компании, в сущности, с нетерпением ждали таких перемен, в продажах понимали, что это весьма рискованно, ведь если что-нибудь пойдет не так, посредники, скорее всего, не простят компании измены.

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

Учитывая то, что у используемого тогда пакета Creative Suite уже было более миллиона пользователей, Леа отлично понимала, какой будет кривая принятия технологии и что определенный сегмент клиентской базы станет сильно сопротивляться изменению этого параметра. Она также знала, что дело не только в том, будет ли новый набор приложений Creative Cloud лучше прежнего, но и в том, что он будет отличаться от прежнего, и во многих смыслах весьма существенно. И одним людям, чтобы «переварить» эти изменения, понадобится больше времени, чем другим.

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

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

Сначала Леа в сотрудничестве с техническим директором Adobe Кевином Линчем объединила несколько многообещающих прототипов, чтобы наглядно продемонстрировать мощь нового фундамента, и использовала результат для того, чтобы ободрить и сплотить руководство и продуктовые команды вокруг новой идеи. Затем она инициировала длительную и даже изнурительную кампанию, в рамках которой постоянно общалась с лидерами и заинтересованными сторонами из разных подразделений компании. Для Леа не существовало такого понятия, как слишком много общения. А непрерывный поток прототипов отлично помогал подогревать искренний интерес людей к тому, что именно принесет им предлагаемое ею новое будущее.

Набор межплатформенных приложений Creative Cloud стал настолько успешным (на момент написания этой главы Adobe заработала более миллиарда долларов в форме повторного дохода быстрее, чем любая другая компания в мире), что компания перестала выпускать релизы Creative Suite для ПК и сосредоточила инновации на этом новом фундаменте. Сегодня более 9 миллионов профессионалов-креативщиков подписаны на этот замечательный продукт Adobe и активно используют его в своей работе. А сама Adobe во многом благодаря этому переходу более чем утроила рыночную капитализацию по сравнению с показателем до соответствующих изменений. Сегодня она стоит около 60 миллиардов долларов.

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

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

Я очень рад тому, что сегодня Леа — партнер в Silicon Valley Product Group; она помогает другим компаниям успешно проходить через серьезную трансформацию и внедрять современные передовые методики работы с продуктами.

Итак, у нас имеется несколько сильных продуктовых команд, и теперь нам нужно ответить на основополагающий вопрос: над чем они должны работать? В большинстве компаний (особенно тех, о которых шла речь в главе 6) командам не приходится ломать над этим голову, ведь ответ обычно «спускается» сверху в форме так называемой дорожной карты продукта.

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

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

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

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

Справедливости ради нужно признать, что для использования таких карт у менеджеров есть весьма веские причины:

1. Они хотят получить гарантии, что команды работают в первую очередь над тем, что имеет наибольшую ценность.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Иногда стратегия развития продукта базируется на географии: мы занимаемся разными регионами мира в установленной очередности. А иногда продуктовая стратегия строится вокруг достижения в логическом порядке ряда ключевых вех, например: «Сначала обеспечить функциональные возможности для проведения критически важных рейтингов и отзывов для разработчиков приложений для электронной торговли; затем использовать сгенерированные этими фичами данные для создания базы данных по потребительскому климату; и наконец, использовать эти данные для разработки развернутых рекомендаций по продуктам». Иными словами, идеального, единого подхода к разработке стратегии развития продукта не существует; вы никогда не знаете, как все пошло бы, если бы вы выбрали другой алгоритм работы над продуктами. Я говорю командам, что важнейшее преимущество тут состоит в решении сосредоточить работу над продуктом на одном целевом рынке.

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

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

Все компании стремятся к тому, чтобы их торговый персонал продавал продукты на рынках, на которых они четко и наглядно продемонстрировали бы соответствие «продукт — рынок». После того как мы докажем соответствие своего продукта тому или иному новому рынку (обычно сформировав начальный набор референсных клиентов), нам нужно, чтобы отдел продаж нашел там как можно больше новых потребителей.

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

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

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

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

Далее описаны десять принципов создания эффективного видения продукта.

1. Начните с вопроса «почему?». Так, кстати, называется превосходная книга о значении видения продукта Саймона Синека[12]. Основная ее идея состоит в использовании видения для формулировки своей главной цели. Все остальное логически вытекает из этого.

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

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

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

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

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

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

8. Никогда не предавайте видение в целом, но оставайтесь гибким в деталях. Эти слова принадлежат великому Джеффу Безосу, и его совет очень ценный. К сожалению, многие команды слишком рано и легко отказываются от своего видения продукта. Они называют свои действия корректировкой видения, притом что это верный признак слабой продуктовой компании. Упорно держаться своего никогда не бывает легко, так что сразу приготовьтесь к трудностям, но внимательно следите за тем, чтобы излишне не привязываться к деталям. Вполне возможно, для достижения желаемого вам и правда придется скорректировать курс. Вот это действительно корректировка видения, и в ней нет ничего плохого.

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

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

Как мы уже говорили, хотя подходов к продуктовой стратегии много, все по-настоящему эффективные стратегии базируются на следующих пяти принципах:

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

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

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

4. Ставьте во главу угла потребителей, а не конкурентов. Многие компании, к сожалению, полностью забывают о своей стратегии развития продукта, едва на горизонте появится серьезный конкурент. Они тут же начинают паниковать и вскоре обнаруживают, что попросту копируют его действия, забыв о своих потребителях. Мы, конечно, не должны игнорировать рынок, но всегда обязаны помнить, что клиенты редко уходят от нас ради конкурентов; гораздо чаще они делают это потому, что мы перестаем о них заботиться.

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

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

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

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

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

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

Я уже говорил, что мне несказанно повезло начать карьерный путь инженером-программистом в Hewlett-Packard в годы ее расцвета, когда эта компания считалась самым успешным и долгосрочным примером последовательных инноваций и качества в нашей отрасли. Именно там в рамках внутренней тренинговой программы в области технического руководства — она называлась The HP Way («Путь HP») — меня познакомили с системой, известной как MBO (management by objectives — управление по целям).

Дэйв Паккард в свое время говорил о ней так: «Ни один [инструмент] не внес в успех Hewlett-Packard большего вклада, чем эта система. [MBO] антитеза управления на базе контроля».

Впоследствии за много лет использования MBO была существенно усовершенствована и улучшена рядом компаний, особенно легендарным Энди Гроувом из Intel. Сегодня основная система управления бизнес-целями, которую мы используем, известна под названием OKR (objectives and key results — управление по целям и ключевым результатам).

В свое время Джон Дорр принес OKR из Intel в тогда еще совсем молодую Google, и через двадцать лет после того, как Дэйв Паккард объяснил успех своей компании системой MBO, Ларри Пейдж столь же уверено заявил о неоценимой роли OKR в успехе Google.

Концепция OKR проста и основывается на двух принципах:

1. Первый легко подытожить знаменитыми словами генерала Джорджа Паттона: «Никогда не говори людям, как надо делать. Скажи им, что делать, и они удивят тебя своей изобретательностью».

2. Второй принцип стал лозунгом HP: «Когда производительность измеряется результатами». Иными словами, вы можете предложить любую функциональность, но, если она не решает основополагающих бизнес-проблем, считайте, что вы ничего не решили.

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

1. Цели должны быть качественными, а ключевые результаты — количественными/измеримыми.

2. Ключевые результаты используются для оценки бизнес-результатов, а не процесса (промежуточных результатов) или отдельных задач.

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

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

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

6. Очень важно, чтобы каждая продуктовая команда отслеживала свой прогресс по этим целям (обычно это делается еженедельно).

7. Цели не должны касаться каждой детали и мелочи в работе команды — они охватывают то, чего она обязана достичь.

8. Важно, чтобы команды так или иначе чувствовали свою ответственность за достижение поставленных перед ними целей. Если они сильно отстают, возможно, стоит провести «разбор полетов» с кем-нибудь из членов команды или менеджеров.

9. В рамках всего подразделения согласуйте, как будут оцениваться ключевые результаты. Как уже говорилось, это можно делать по-разному, и выбор подхода в значительной мере отражает культуру компании. Здесь важна четкая согласованность во всей организации, все команды должны знать, в чем и когда они могут положиться друг на друга. Обычно 0 (по шкале от 0 до 1,0) означает отсутствие прогресса; 0,3 — минимальный прогресс (вы достигли того, что вам точно по плечу); 0,7 — прогресс больше минимума (вы сделали то, на что надеялись); и 1,0 — исключительный прогресс (результат превзошел ваши ожидания; вы удивили себя и других).

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

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

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

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

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

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

В крупных организациях нередко бывает 20–50 кросс-функциональных продуктовых команд, и каждая из них отвечает за свое направление и работает над достижением собственных целей.

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

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

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

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

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

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

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

Распространение целей и ключевых результатов в продуктовой компании должно идти снизу вверх — от кросс-функциональных продуктовых команд на уровень компании или бизнес-единицы.

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

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

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

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

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

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

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

Мы уже не раз говорили, что компании важно иметь команды «миссионеров», а не «наемников», и евангелизм представляет собой очень ценное направление деятельности, позволяющее достичь этой цели. И ответственность за это ложится в первую очередь на менеджера продукта.

Существует несколько методик, которые помогают донести ценность того, что вы предлагаете, до своей команды, коллег, заинтересованных сторон, руководства и инвесторов. Вот моя топ-десятка советов менеджерам продукта относительно эффективной «продажи мечты»:

1. Используйте прототип. Многим людям трудно, как говорится, увидеть за деревьями лес. Когда в вашем распоряжении нет ничего, кроме двух-трех пользовательских историй, увидеть общую картину и то, как все соединяется (и соединяется ли вообще), действительно трудно. А прототип позволяет четко увидеть и лес, и деревья.

2. Делитесь болью клиента. Покажите команде проблему потребителя, которую вы пытаетесь устранить. Именно для этого я всегда стараюсь брать инженеров-программистов с собой на встречи с клиентами. Многим людям, чтобы понять и проникнуться чьей-то болью, нужно увидеть ее своими глазами (или испытать самому).

3. Доносите свое видение. Убедитесь, что ясно понимаете видение продукта, стратегии его развития и принципов. Покажите, как ваша работа способствует его реализации и в полной мере согласуется с этими принципами.

4. Щедро делитесь знаниями. После каждого пользовательского теста или посещения клиента делитесь тем, что узнали — не только тем, что прошло хорошо, но и проблемами. Расскажите своей команде все, что может помочь ей найти верное решение.

5. Щедро делитесь успехом. Убедитесь, что ваша команда считает продукт не только вашим, но и своим. Но если что-то пошло не так, выйдите вперед и возьмите на себя ответственность за промах; покажите команде, что вы учитесь и на ошибках. Люди будут вас за это уважать.

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

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

8. Искренне любите продукт. Если вы не в восторге от своего продукта, вам, судя по всему, необходимо как-то исправить ситуацию: либо изменить то, над чем вы работаете, либо свою роль в этом деле.

9. Научитесь проявлять энтузиазм. Меня не перестает удивлять, что продакт-менеджеры часто крайне неубедительно проявляют свой энтузиазм или испытывают при этом явный дискомфорт, даже те, кто действительно любит свое дело и свой продукт. А это имеет значение — и очень большое. Будьте искренним и демонстрируйте людям свой энтузиазм, ведь он и правда заразителен.

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

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

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

Осознав и признав огромный потенциал технологии синдицированного контента с поддержкой IP-протокола, Алекс принялась искать новые полезные способы ее использования. И начала с анализа тех британцев, которых не охватывали традиционные вещательные СМИ BBC, то есть телевидение и радио в домах и автомобилях.

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

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

Редакторам казалась странной и непривычной модель, согласно которой контент должен создаваться и предлагаться в разных контекстах. Это затрагивало саму суть редакционной политики и культуры BBC. Прессланд потребовались долгие часы уговоров и убеждений, что это очень хорошо как для BBC, так и для ее аудитории. А юристов компании пугала идея перехода на дистрибуцию контента через устройства с поддержкой IP-протокола. Только представьте себе пачки лицензионных соглашений, которые им необходимо было обновить или пересмотреть.

Однако впечатляющие результаты экспериментов и первые успехи вселили в Алекс уверенность, и она предложила руководству компании новое видение продукта и стратегию его развития, которую назвала BBC Out of Home («BBC вне дома»).

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

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

Впоследствии Алекс ушла из BBC и сделала потрясающую карьеру в нескольких технологических и медиакомпаниях; сегодня она работает лидером продукта в Нью-Йорке.

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

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

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

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

Та же проблема встречается и в ином обличье. Как уже говорилось, многие команды сталкиваются с огромными трудностями из-за минимально жизнеспособного продукта (minimum viable product, MVP), потому что, с одной стороны, заинтересованы максимально быстро предложить его клиенту, чтобы получить конструктивную обратную связь и узнать то, что пока о нем неизвестно, а с другой — когда мы это делаем, людям кажется, что этот, с позволения сказать, продукт, в не слишком выгодном свете представляет наш бренд и компанию. Как же мы могли предлагать его как готовую версию?

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

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

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

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

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

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

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

Главная цель исследования продукта заключается в устранении следующих рисков:

• Купит ли (нашу идею) покупатель, решит ли он (ее) использовать? (Риск ценности.)

• Сможет ли пользователь понять, как это работает? (Риск юзабилити.)

• Можем ли мы это разработать? (Риск технической реализуемости.)

• Принесет ли это решение пользу нашему бизнесу? (Риск бизнес-жизнеспособности.)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как видите, нам нужен довольно широкий спектр методик, как количественных, так и качественных. Одни предназначены для сбора фактов (или по крайней мере статистически значимых результатов), другие — для получения доказательств. И все они призваны помогать нам быстро учиться и приобретать нужные знания.

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

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

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

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

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

Нам также обязательно следует оценить риск ценности: нужно ли потребителям решение именно этой проблемы и достаточно ли хорош предлагаемый нами продукт, чтобы они отказались от того, чем пользуются сейчас?

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

• Финансовый риск: можем ли мы позволить себе это решение?

• Риск, связанный с развитием бизнеса: выгодно ли это решение нашим партнерам?

• Маркетинговый риск: согласуется ли это решение с нашим брендом?

• Риск продаж: готовы ли наши торговые представители продавать это решение?

• Правовой риск: допустимо ли это с точки зрения соблюдения юридических и прочих норм и требований?

• Этический риск: стоит ли нам предлагать это решение?

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

1. Какой бизнес-цели вы хотите достичь, проделав эту работу? (Цель.)

2. Как вы будете определять, добились ли успеха? (Ключевые результаты.)

3. Какая проблема потребителей будет решена в итоге? (Проблема клиента.)

4. На потребителе какого типа вы сосредоточены? (Целевой рынок.)

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

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

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

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

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

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

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

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

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

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

Несколько методик исследования продукта сыграли в успехе Amazon особую роль; одна из них называется работа в обратном порядке. Это значит, что работа начинается с придуманного пресс-релиза.

Менеджер продукта заранее формулирует суть задания для команды, составляя воображаемый пресс-релиз о том, что произойдет после того, как продукт будет выпущен на рынок. Как он улучшил жизнь потребителей? Какие выгоды и преимущества они получили? Да что и говорить. Вам всем доводилось читать пресс-релиз. Этот случай отличается только тем, что он не настоящий, а воображаемый, и описывает то, что мы намерены создать.

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

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

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

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

Надеюсь, вы видите, что «Письмо клиента» напоминает придуманный пресс-релиз Amazon; обе вариации методики призваны настроить людей на одинаковый ход рассуждений. Пресс-релиз, кстати, тоже может включать в себя цитаты из комментариев довольных потребителей.

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

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

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

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

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

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

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

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

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

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

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

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

«Карта истории» (Story mapping) — одна из самых полезных методик из всех, что я знаю. По сути, это методика для формулирования задач и планирования, но она полезна и для выработки новых идей. А еще «Карта истории» используется при создании прототипов и представляет собой отличный инструмент менеджера продукта для коммуникаций со своей командой и заинтересованными сторонами. Кроме того, с помощью этой методики можно управлять собственной профессиональной деятельностью и организовывать ее. И наконец, стоит отметить, что «Карта истории» может пригодиться на протяжении всего процесса исследования продукта и его поставки на рынок. Думаю, вы согласитесь, что это огромные преимущества. Но лучшее в ней — простота.

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

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

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

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

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

Многие знакомые мне команды считают пользовательский прототип с высокой детализацией и «Карту истории» незаменимыми.

Кстати, вот еще одна книга, которую должен прочитать каждый продакт-менеджер: User Story Mapping: Discover the Whole Story, Build the Right Product[13] Джеффа Паттона.

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

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

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

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

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

Прежде всего нам нужно поговорить о почти волшебной силе полностью удовлетворенного референсного клиента.

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

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

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

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

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

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

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

Встречается четыре основных варианта этой методики.

1. Создание продуктов для бизнеса.

2. Создание платформенных продуктов, например публичных API (application programming interface — интерфейс создания приложений).

3. Создание инструментов для поддержки клиентов, используемых сотрудниками компании.

4. Создание продуктов для потребителей.

В 1993 году Word 6.0 был самой масштабной версией продукта с самым большим набором фич из выпущенных на тот момент компанией Microsoft. В дополнение ко всем новым фичам перед командой его создателей стояла очень важная и большая цель. Дело в том, что база исходного кода продукта отклонилась от нормы, и отдельный выпуск Word для каждой платформы — Windows, DOS и Mac, — обходился Microsoft очень дорого, и делалось это очень медленно. Конвергенция кода должна была сэкономить Microsoft немало времени и, как пытались убедить себя разработчики, улучшить предложение, поскольку тогда фичи Word были бы одинаковыми на всех платформах. Вся эта ситуация побуждала как можно быстрее выпустить релиз, чтобы начать пользоваться преимуществами единой кодовой базы.

В то время Word для Mac был относительно небольшим рынком — всего 60 миллионов долларов, а это копейки по сравнению с Windows, рынок которой на тот момент составлял свыше миллиарда долларов. Если вы помните, в те давние годы «железо» на Windows доминировало повсюду, а будущее Apple было еще туманно. Сообщество Mac, хоть и небольшое, но и очень громогласное — истинные фанаты своей платформы, — не отличалось горячей любовью к Microsoft.

Тогда на рынок только что вышла линейка ПК PowerMac; компьютеры были оснащены значительно более быстрыми чипами и имели большую память. Большинство членов команды разработчиков использовали именно эту технику, потому что бета-версия Word 6.0 на обычных Mac поначалу работала слишком медленно. Но, конечно, пользователи Mac имели не новые PowerMac, а обычные Mac. В те времена циклы апгрейда «железа» были намного длиннее и медленнее. И когда Microsoft выпустила свой самый «полнофункциональный текстовый процессор для Mac», на Mac рядового пользователя он не то что не летал, а ползал; на его запуск уходило целых две минуты.

Пользовательское сообщество сразу же заявило в группах новостей о попытке Microsoft «убить Mac». «Письма ненависти» текли в Microsoft рекой отовсюду, в том числе лично Биллу Гейтсу, который переправлял их команде с такими комментариями: «Это крайне негативно сказывается на цене акций MSFT. Немедленно исправляйте ситуацию». И тут на сцену вышла Мартина Лаученгко, молодой менеджер продукта, совсем недавно пришедшая со Стэнфордской скамьи.

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

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

Еще команда сфокусировалась на счетчике слов, используемом каждым журналистом не менее десяти раз в день. Он должен был работать молниеносно, так как в журналистике эта функция служит барометром эффективности. В новом продукте на Mac счетчик работал даже быстрее, чем на Windows.

Результатом всех этих усилий стала выпущенная через два месяца версия Word 6.1, которая была отправлена каждому зарегистрированному пользователю с извинениями (письмо подписала Мартина) и купоном на скидку на будущие покупки.

Новому релизу удалось устранить проблемы восприятия продукта, но, что еще важнее, он сделал версию намного удобнее для платформы Macintosh. Таким продуктом команда могла гордиться, и вот это чувство им нужно было поставить на рынок в первую очередь.

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

Впоследствии Microsoft не только решила «развести» базу исходного кода по разным платформам, но и рассадила команды в разные здания и отнесла их к разным бизнес-единицам; люди должны были в полной мере охватить все требования Mac. Стратегически это был разворот на 180 градусов.

Трудно переоценить, насколько все это было важно и для Microsoft, и для Apple. Даже сегодня, спустя столько лет, многие компании и потребители предпочитают использовать Word и остальную часть Office на своих Mac для бизнеса и в личных целях. Начало, положенное тогда, стало многомиллиардной победой для обеих компаний. На Office сегодня работает более миллиарда компьютеров Mac и ПК во всем мире.

Мартина сделала отличную карьеру как в менеджменте, так и в маркетинге продуктов. Из Microsoft она перешла в Netscape, где отвечала за маркетинг Netscape-браузера, а затем в Loudcloud. И я счастлив сообщить, что вот уже более десяти лет она мой партнер в SVPG, а также преподает маркетинг в Калифорнийском университете в Беркли.

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

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

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

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

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

К сожалению, это не всегда так. Даже если такие интервью проводятся, менеджер продукта на них часто не присутствует и, как следствие, не принимает полученную из них информацию близко к сердцу, не воспринимает ее так серьезно, как должен (см. принцип исследования продукта № 10, касающийся совместного обучения, в главе 33). А между тем такие интервью, несомненно, один из самых важных навыков для любого продакт-менеджера и очень часто источник вдохновения для многих прорывных идей. При использовании методик для качественного тестирования идей, которые мы будем обсуждать далее, вы увидите, что владение этими навыками — обязательное условие.

Формы интервью с пользователями могут быть разными, так что, строго говоря, это не совсем одна методика. Одни интервью неформальные, другие формальные. В основе одних лежит та или иная методология исследования пользовательского поведения (одна из моих любимых — контекстный запрос); другие нацелены на то, чтобы «вытащить» из человека новые сведения и узнать то, чего мы пока не знаем.

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

• Действительно ли ваши потребители те, кого вы ими считаете?

• В самом ли деле они имеют те проблемы, которые вы предполагаете?

• Как этот потребитель решает свою проблему сегодня?

• Что нужно для того, чтобы он стал использовать ваш продукт?

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

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

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

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

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

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

В прошлом эффективные продуктовые команды использовали два подхода к определению продуктово-рыночных возможностей:

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

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

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

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

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

У целевых хакатонов два преимущества: во-первых, практичность, так как методика весьма эффективно способствует включению инженеров-программистов в процесс генерирования идей. Я уже несколько раз упоминал о том, что многие лучшие идеи приходят именно от этих членов продуктовых команд, и нам необходимо воспользоваться такой возможностью. Вообще-то это должно происходить постоянно, и благодаря данной методике мы этого добиваемся. Во-вторых, культурное преимущество. Нужно сказать, это один из моих любимых способов формирования команд «миссионеров». Сегодня — если, конечно, они не сделали этого раньше, — инженеры-программисты все глубже погружаются в бизнес-контекст и играют намного более важную роль в инновациях своих компаний.

Прототипы в различных формах и видах существуют с тех пор, как люди начали использовать технологии для решения проблем. Как говорил известный ученый в области теории вычислительных систем Фредерик Брукс: «Сразу планируйте что-то выбросить — все равно придется».

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

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

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

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

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

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

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

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

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

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

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

2. Одно из преимуществ любого вида прототипа — это то, что его создание заставляет продумать проблему намного глубже, чем в случае, если бы мы просто обсуждали ее или даже формулировали свои мысли письменно. Вот почему этот акт часто выводит на поверхность важные проблемы, которые в противном случае всплывают гораздо позже.

3. Прототип служит действенным инструментом для совместной работы команды. Члены продуктовой команды и бизнес-партнеры могут вместе испытать его и выработать общий взгляд на проблему.

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

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

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

• с алгоритмом;

• производительностью;

• масштабируемостью;

• отказоустойчивостью;

• проблемами применения технологий, которые команда не использовала ранее;

• проблемами при использовании компонентов или сервисов других производителей, которые команда не использовала ранее;

• проблемами использования унаследованной системы, которую команда не использовала ранее;

• проблемами зависимости от новых или сопутствующих изменений, внесенных другими командами.

Пользовательский прототип, или симуляция — один из самых эффективных инструментов на этапе исследования продукта. Это дым и зеркала. Фасад, за которым ничего нет. Занавес, за которым пустота. Простыми словами, если речь идет о пользовательском прототипе интернет-магазина, то человек может вводить данные своей кредитной карты хоть сто раз, ничего не покупая.

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

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

На другом конце спектра находятся пользовательские прототипы высокой детализации. Несмотря на то что это тоже симуляция, она выглядит и воспринимается как нечто весьма реалистичное. Часто их даже не отличишь от настоящего продукта. Тем не менее это не так; данные, которые вы видите, не реальные, хоть и очень похожие.

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

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

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

Многие начинающие разработчики новых продуктов попадают в ловушку, создавая пользовательский прототип высокой детализации и предлагая его 10–15 человекам, которые в один голос подтверждают его великолепие. Создатель думает, что проверил свой продукт и подтвердил его соответствие предъявляемым требованиям, но, увы, ошибается. Люди часто говорят одно, а поступают совершенно иначе.

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

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

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

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

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

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

Прототип на реальных данных — это лишь малая толика работы, которая проделывается для полноценного вывода продукта на рынок (по моему опыту, на него уходит 5–10 процентов всей работы над готовым продуктом), но получаемую от него пользу переоценить невозможно. Однако следует помнить о двух существенных ограничениях:

1. Поскольку речь идет о коде, создавать такие прототипы должны инженеры-программисты, а не дизайнеры.

2. Поскольку это не окончательный продукт, готовый к выведению на рынок, бизнес на нем не сделаешь. Так что, если тесты на реальных данных проходят успешно и вы решаете выходить с продуктом на рынок, придется предоставить программистам достаточно времени для выполнения всей дальнейшей необходимой работы. Менеджер продукта не должен говорить инженерам, что все «уже и так, как надо»; это неправильно. Решение принимает не он. Однако он обязан гарантировать, что руководство компании и ключевые заинтересованные стороны в полной мере понимают ограничения прототипа данного вида.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Если у вас есть список адресов электронной почты ваших пользователей, можете отобрать участников из него. А продуктовый маркетолог поможет вам сократить выборку.

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

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

• Если вы просите пользователей прийти для участия в тестировании к вам, скорее всего, нужно будет им чем-то компенсировать это одолжение. Мы обыкновенно организуем встречи с участниками тестов там, где удобно всем, например в кафе Starbucks. Такая практика стала настолько широко распространенной, что у нее даже появилось название — starbucks-тестирование.

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

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

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

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

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

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

Еще одна превосходная среда для тестирования — офис потребителя. На реализацию такого подхода может уйти много времени, но даже полчаса, проведенные «в среде обитания» пользователя, расскажут вам о нем очень много полезного. Здесь ваши потребители хозяева, поэтому они намного разговорчивее. В офисе всегда найдется множество подсказок, как еще можно использовать тестируемый продукт. Многое можно узнать при виде офисной обстановки. Насколько большие мониторы? Как быстро работает компьютер и подключение к сети? Как люди общаются с коллегами при решении рабочих задач?

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

Итак, прототип готов, участники тестирования отобраны, задачи и вопросы сформулированы, теперь воспользуйтесь приведенными ниже советами и методиками для проведения теста.

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

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

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

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

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

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

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

Повторяйте за собеседником как попугай, так как это полезно во многих ситуациях и помогает не давать пользователю наводок. Если участник тестирования ничего не говорит, а у вас уже нет сил молчать, опишите ему, что он делает: «Я вижу, вы ищете этот список справа». Человек обязательно расскажет вам, что он пытается сделать, что хочет найти и все остальное. Если же он задаст прямой вопрос, вместо ответа-подсказки можно просто повторить его слова. Например, пользователь спрашивает: «А если кликнуть тут, будет новая запись?» — а вы отвечаете: «Вам интересно, нужно ли кликнуть здесь, чтобы получить новую запись?» Как правило, пользователи «покупаются» на такой прием, потому что люди обычно хотят ответить на заданный им вопрос: «Ну да, думаю, так и будет». А еще попугайничанье помогает избегать наводящих оценочных суждений. Если у вас возникло непреодолимое желание похвалить участника тестирования, лучше скажите: «Ну вот, вы создали новую запись». И наконец, по-попугайски повторяя ключевые моменты, вы помогаете коллеге, который ведет записи, оставляя ему на это больше времени.

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

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

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

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

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

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

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

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

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

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

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

Самый распространенный тип качественного тестирования ценности сосредоточен на отзывах. Нравится ли идея клиентам? Готовы ли они за нее платить? Решат ли ее использовать? И главное, почему нет?

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

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

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

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

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

Такой метод тестирования спроса называют тестом с поддельными дверями (Fake-door demand test). Мы помещаем кнопку или пункт меню в том месте пользовательского интерфейса, где, по нашему мнению, они должны быть. Но когда пользователь на нем кликает, то он, вместо того чтобы привести к новой опции, переводит его на специальную страницу, где человеку объясняют, что вы исследуете возможность добавления новой опции и очень хотели бы с ним это обсудить. На этой странице пользователю также предлагают стать волонтером в тестировании спроса — например, указав свой адрес электронной почты или номер телефона.

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

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

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

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

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

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

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

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

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

Обычно пользовательский тест начинается с короткого интервью с пользователем, во время которого нам нужно постараться выяснить, действительно ли у него есть проблемы, которые мы предполагаем; узнать, как он решает их сейчас и что необходимо ему предложить, чтобы он согласился пользоваться нашим продуктом (см. главу 41).

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

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

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

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

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

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

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

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

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

У стартапов трафик обычно невелик, да и времени маловато, зато они смело идут на риск — ведь им еще нечего терять. В устоявшейся компании трафика более чем достаточно, и она располагает временем. Причиной для беспокойства обычно бывает то, что у менеджмента может лопнуть терпение. И, как правило, такие компании не склонны рисковать.

Золотым стандартом этого типа тестирования считается A/B-тест. Мы очень любим эти тесты, потому что пользователь не знает, какую версию продукта он видит, и мы получаем данные, весьма надежные с точки зрения точности прогнозирования, к чему мы, собственно, и стремимся.

Имейте в виду: речь идет о немного ином типе A/B-тестов, чем A/B-тесты с целью оптимизации. Во втором случае мы экспериментируем с разными призывами к действию, цветовыми решениями кнопок и тому подобными вещами. Концептуально эти типы тестирования одинаковы, но на практике между ними есть важные различия. В частности, A/B-тесты с целью оптимизации обычно предполагают поверхностные изменения с низким уровнем риска; часто это тесты в рамках сплит-теста (50:50).

В ходе A/B-тестирования на этапе исследования мы демонстрируем продукт 99 процентам пользователей, а прототип на реальных данных — только одному проценту, а то и меньше. И гораздо внимательнее отслеживаем результаты.

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

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

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

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

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

• Знаем ли мы, как это создать?

• Обладает ли наша команда необходимыми для этого навыками?

• Достаточно ли у нас времени для создания продукта?

• Потребуются ли какие-либо изменения архитектуры?

• В наличии ли все необходимые компоненты?

• Понимаем ли мы, какие взаимосвязи и зависимости предполагает реализация идеи?

• Будет ли приемлемой производительность полученного результата?

• Будет ли полученный результат масштабироваться до необходимого уровня?

• Имеется ли у нас инфраструктура для его тестирования и запуска?

• Можем ли мы позволить себе все связанные с этим расходы?

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

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

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

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

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

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

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

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

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

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

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

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

И еще, при использовании модели персонализированного сервиса его персонал просто незаменим при выработке идей продукта и их тестировании с применением прототипов.

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

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

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

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

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

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

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

Netflix — один из моих любимых продуктов, и одна из моих любимейших компаний. Но мало кто помнит, что в 1999 году совсем еще юная Netflix (тогда она располагалась в Лос-Гатосе, и в ней работало менее двух десятков сотрудников) оказалась на грани разорения. У компании было несколько опытных основателей, в том числе легендарный Рид Хастингс, однако она забуксовала на 300 тысячах клиентов.

В сущности, Netflix предлагала общепринятый подход «плата за прокат», как и Blockbuster, только в онлайн-версии. И у нее, как и у многих, имелась группа ранних последователей, причем некоторые из них жили в местах, где не было ни одного видеомагазина. Согласитесь, мало кто будет брать напрокат DVD через Почтовую службу США, если по дороге домой можно заскочить в местный Blockbuster. Как правило, люди брали видео в Netflix раз или два, после чего быстро забывали об этом сервисе. Похоже, им не слишком хотелось что-нибудь менять. Команда Netflix понимала, что недостаточно опережает конкурентов, чтобы переманить людей на свою сторону.

А тут еще продажи DVD начали неуклонно снижаться, да и противодействие Голливуда усугубляло плохое положение вещей. Не следует забывать и о серьезных трудностях с логистикой, сложностях поддержания высокого качества DVD и попытках понять, как сделать все так, чтобы покрывать расходы и получать прибыль наличными.

Кейт Арнольд была в то время менеджером по продукту этой небольшой команды, и команда точно знала, что нужно что-то менять.

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

Хорошей новостью оказалось то, что новый подход понравился потребителям. Фиксированная ежемесячная плата за неограниченный доступ к видео очень заинтересовали их. Но была и плохая новость: таким шагом команда создавала себе реальные трудности. Разумеется, клиенты Netflix хотели смотреть в основном последние художественные фильмы, а такой контент обходился компании дороже всего. Чтобы иметь в наличии необходимое количество копий, требовалось много денег, а их у Netflix не было.

Итак, компании предстояло решить задачу: как, не обанкротившись, сделать так, чтобы клиенты могли смотреть те фильмы, которые хотят?

Команда, перед которой она была поставлена, знала, что нужно каким-то образом убедить клиентов захотеть смотреть микс из дорогостоящих и менее дорогостоящих фильмов. Острая нужда, как известно, мать всех изобретений и нововведений; на этой почве выросли списки ожидания, рейтинговая система и рекомендательный сервис Netflix. Благодаря этим технологическим инновациям появилась новая, более эффективная бизнес-модель.

Команда взялась за дело. За три месяца она изменила дизайн сайта, дополнив абонентское обслуживание Netflix перечисленными выше элементами. А еще она переписала автоматизированную систему расчета с абонентами для работы по модели ежемесячной подписки. (Любопытный факт: начинала компания без этой системы, потому что сперва предлагала тридцатидневный бесплатный пробный период, что обеспечило ее необходимым дополнительным временем.)

Учитывая огромный объем одновременно внедряемых изменений и взаимосвязанных усилий, в процесс были вовлечены почти все сотрудники компании.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Они хотят ясно видеть, над чем вы работаете, и быть уверенными в том, что вы работаете над самыми важными задачами.

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

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

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

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

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

Подозреваю, что многие менеджеры продукта считают управление ключевыми лицами, или заинтересованными сторонами[16], нелюбимой частью работы. И я не намерен утверждать, что она простая, однако можно существенно облегчить этот вид деятельности и сделать его более приятным.

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

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

Один в высшей мере практичный тест позволяет быстро определить, стоит ли считать человека заинтересованной стороной. Для этого понадобится ответить на вопрос, обладает ли этот человек правом вето и может ли он каким-либо образом помешать вам запустить в производство новый продукт или фичу.

К заинтересованным сторонам обычно относят:

• высшее руководство компании — СЕО и глав отдела продаж и маркетинга, инженерно-технического подразделения;

• деловых партнеров, которые гарантируют согласованность продукта и бизнеса;

• финансистов, которые помогают убедиться, что продукт соответствует финансовым особенностям и модели компании;

• юристов, которые проверят, что у вашего предложения есть перспективы с точки зрения правовой защиты;

• специалистов в области соответствия нормативным требованиям, которые подтвердят, что ваша идея соответствует всем установленным в отрасли стандартам или политикам;

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

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

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

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

Обмен новейшей полезной информацией призван решить сразу несколько задач, как тактических, так и культурных.

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

• С помощью этого простого и полезного способа разные продуктовые команды компании узнают, чему научились другие, а также доводят эти полезные уроки до ведома руководства.

• Метод стимулирует продуктовые команды сохранять фокус на больших и важных уроках, а не на экспериментах, которые не оказывают заметного влияния ни на потребителя, ни на компанию.

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

• С точки зрения культуры также важно, чтобы разработчики продукта максимально честно и щедро делились новыми знаниями, рассказывая остальным, как они работают. Это помогает другим подразделениям понять, что продуктовые команды существуют не для «обслуживания бизнеса», а для решения проблем потребителей таким способом, чтобы это приносило пользу бизнесу.

Я невероятно рад познакомить вас с еще одним очень эффективным менеджером по продукту, Камиллой Херст.

Камилла была менеджером по продукту в команде Apple, работавшей над iTunes. Как вы можете себе представить, учитывая революционность этого продукта, она многое пережила и многому научилась за годы, проведенные в компании, в период своего становления как профессионала в деле разработки новых продуктов. Особенно если принять во внимание, что в годы работы Камиллы в Apple осуществлялся переход iTunes с первоначальной системы предложения музыки на основе DRM (Digital Rights Management — управление правами на электронные продукты) на музыку, не защищенную такими правами, что, как покажет будущее, сыграло решающую роль в превращении рынка iTunes в массовый рынок.

Переход от ранних последователей к массовому рынку требовал серьезных усилий в разных направлениях: в продуктовой сфере, маркетинговой и их комбинации. Наглядным примером такой комбинации можно считать отношения, которые команда iTunes наладила с популярной телевизионной программой American Idol[17].

Для команды iTunes этот период в ее истории стал одним из самых важных и заметных — и очень-очень непростым.

В 2008 году телевизионное шоу American Idol считалось легендой, даже иконой стиля; передачу дважды в неделю смотрели более 25 миллионов человек — непревзойденный показатель уровня повторного обращения.

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

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

Приведу только один пример. Как известно, важнейший элемент шоу American Idol — это голосование, и Apple быстро поняла, что продажа музыки конкурсантов, скорее всего, будет сильно зависеть от его результатов. Так что, хоть приложение iTunes создавалось для того, чтобы представлять миру трендовую музыку и привлекать внимание к популярным названиям и именам, теперь нужно было действовать осторожно, чтобы не влиять на результаты голосования. Безусловно, это было чрезвычайно важно для продюсеров American Idol, ведь любые действия могли снизить и даже уничтожить те предвкушение и напряжение, с какими люди желали узнать, кто из участников продолжит борьбу на следующей неделе.

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

Размышляя над решением этих и многих других сложнейших задач, Камилла и ее команда придумали технологические решения, удачно дополнявшие опыт просмотра шоу American Idol и при этом сделали iTunes ключевым элементом жизни фанатов этой шоу-программы. В итоге возникло новое направление бизнеса, которое в 2014 году, еще до перехода на потоковую передачу, оценивалось примерно в 20 миллиардов долларов!

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

Впоследствии Камилла присоединилась к команде YouTube, а затем возглавила лондонское подразделение компании — разработчика приложения для такси Hailo. А сегодня она СЕО одного нью-йоркского стартапа.